http://tc.eserver.org/authors/Wiegers,_Karl_E. A bibliography of works by Wiegers, Karl E. in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Wiegers,_Karl_E. http://tc.eserver.org/34276.html http://tc.eserver.org/34276.html This article describes several characteristics of high quality software requirement statements and specifications. We will examine some less-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. You might want to evaluate your own project’s requirements against these quality criteria. http://tc.eserver.org/30581.html http://tc.eserver.org/30581.html Many software projects that suffer a lingering death should have been canceled much earlier. Although it is hard to pull the plug on a project with a weak business case, failing to do so does throw good money after bad. Karl Wiegers gives some tips on decision making that can help you avoid this outcome. Karl also shows how to use decision points to keep a good project moving along. http://tc.eserver.org/30582.html http://tc.eserver.org/30582.html Could it be that not every set of business requirements has the customer's best interest in mind? Karl Wiegers had always believed that implemented software functionality should enable users to accomplish their goals and help the business achieve its objectives. But a recent experience with a less-than-helpful parking meter system suggested to him that conflicts sometimes might exist between business and user requirements. http://tc.eserver.org/27247.html http://tc.eserver.org/27247.html Errors in requirements specifications translate into poor designs, code that does the wrong thing, and unhappy customers. Requirements documentation should be inspected early and often. Anything you can do to prevent requirements errors from propagating downstream will save you time and money. Karl Wiegers shows you how. http://tc.eserver.org/27246.html http://tc.eserver.org/27246.html Perhaps the greatest challenge facing the software developer is sharing the vision of the final product with the customer. All stakeholders in a project-developers, end users, software managers, customer managers-must achieve a common understanding of what the product will be and do, or someone will be surprised when it is delivered. Surprises in software are almost never good news. Therefore, we need ways to accurately capture, interpret, and represent the voice of the customer when specifying the requirements for a software product.