1、Copyright 2000 by Karl E. Wiegers Karl Wiegers Describes 10 Requirements Traps to Avoid1 Karl E. Wiegers Process Impact The path to quality software begins with excellent requirements. Slighting the processes of requirements development and management is a common cause of software project frustratio
2、n and failure. This article describes ten common traps that software projects can encounter if team members and customers dont take requirements seriously. I describe several symptoms that might indicate when youre falling victim to each trap, and I offer several solutions to control the problem. Be
3、 aware, though, that none of these solutions will work if youre dealing with unreasonable people who are convinced that writing requirements is time-wasting bureaucratic overhead. To persuade such skeptics, present data such as that from the Standish Groups CHAOS report ( )a study of 8,380 IT projec
4、ts which found that more than half were “challenged,” with reduced functionality being delivered over- budget and beyond the estimated schedule. The top three contributing factors on challenged projects were lack of user input (12.8% of projects), incomplete requirements and specifications (12.3%),
5、and changing requirements and specifications (11.8%). Trap #1: Confusion Over “Requirements” Symptoms: Even the simple word “requirements” means different things to different people. An executives notion of “requirements” might be a high-level product concept or business vision, while a developers “
6、requirements” might look suspiciously like detailed user interface designs. Customer-provided requirements often are really solution ideas. One symptom of potential problems is that project stakeholders refer to “the requirements” with no qualifying adjectives. The project participants therefore wil
7、l likely have different expectations of how much detail to expect in the requirements. Another symptom is that the users provide “the requirements,” but developers still arent sure what theyre supposed to build. If requirements discussions focus exclusively on functionality, the participants might n
8、ot understand the various kinds of information that fall under the broad rubric of “requirements.” As a consequence, important stakeholder expectations might go unstated and unfulfilled. Solutions: The first step is to recognize that there are several types of requirements, all legitimate and all ne
9、cessary. A second step is to educate all project participants about key requirements engineering concepts, terminology, and practices. I think in terms of three levels of requirements, all of which must be addressed during requirements development (Figure 1). At the top are the business requirements
10、, representing the high-level objectives of the organization or customer requesting the system or product. They 1 This paper was originally published in Software Testing for commercial product development it might be easier to convene focus groups of representative users. Focus group participants ca
11、n provide a broad range of input on desired product features and characteristics. The individuals you select as user representatives can also evaluate any prototypes you create, and review the SRS for completeness and accuracy. Strive to build a collaborative relationship between your customer repre
12、sentatives and the development team. Trap #3: Vague and Ambiguous Requirements Symptoms: Ambiguity is the great bugaboo of software requirements. Youve encountered ambiguity if a requirement statement can have several different meanings and youre not sure which is correct. A more insidious form of a
13、mbiguity results when multiple readers interpret a requirement in different ways. Each reader concludes that his or her interpretation is correct, and the ambiguity remains undetected until laterwhen its more expensive to resolve. Another hint that your requirements are vague or incomplete is that t
14、he SRS is missing information the developers need. If you cant think of test cases to verify whether each requirement was properly implemented, your requirements are not sufficiently well defined. Developers might assume that whatever theyve been given in the form of requirements is a definitive and
15、 complete product description, but this is a risky assumption. The ultimate symptom of vague requirements is that developers have to ask the analyst or customers many questions, or they have to guess about what is really intended. The extent of this guessing game might not be recognized until the pr
16、oject is far along and implementation has diverged from what is really required. At this point, expensive rework may be needed to bring things back into alignment. Solutions: Avoid using intrinsically subjective and ambiguous words when you write requirements. Terms like minimize, maximize, optimize
17、, rapid, user-friendly, easy, simple, often, normal, usual, large, intuitive, robust, state-of-the-art, improved, efficient, and flexible are particularly dangerous. Avoid “and/or” and “etc.” like the plague. Requirements that include the 10 Requirements Traps to AvoidPage 4 Copyright 2000 by Karl E
18、. Wiegers word “support” are not verifiable; define just what the software must do to “support” something. Its fine to include “TBD” (to be determined) markers in your SRS to indicate current uncertainties, but make sure you resolve them before proceeding with design and construction. To ferret out
19、ambiguity, have a team that represents diverse perspectives formally inspect the requirements documents. Suitable inspectors include: the analyst who wrote the requirements the customer or marketing representative who supplied them (particularly for use case reviews) a developer who must implement t
20、hem a tester who must verify them Another powerful technique is to begin writing test cases early in requirements development. Writing conceptual test cases against the use cases and functional requirements crystallizes your vision of how the software should behave under certain conditions. This pra
21、ctice helps reveal ambiguities and missing information, and it also leads to a requirements document that supports comprehensive test case generation. Consider developing prototypes; they make the requirements more tangible than does a lifeless textual SRS. Create a partial, preliminary, or possible
22、 implementation of a poorly understood portion of the requirements to clarify gaps in your knowledge. Analysis models such as data flow diagrams, entity-relationship diagrams, class and collaboration diagrams, state- transition diagrams, and dialog maps provide alternative and complementary views of
23、 requirements that also reveal knowledge gaps. Trap #4: Unprioritized Requirements Symptoms: “We dont need to prioritize requirements,” said the user representative. “Theyre all important, or I wouldnt have given them to you.” Declaring all requirements to be equally critical deprives the project ma
24、nager of a way to respond to new requirements and to changes in project realities (staff, schedule, quality goals). If its not clear which features you could defer during the all-too-common “rapid descoping phase” late in a project, youre at risk from unprioritized requirements. Another symptom of t
25、his trap is that more than 90% of your requirements are classified as high priority. Various stakeholders might interpret “high” priority differently, leading to mismatched expectations about what functionality will be included in the next release. Sometimes developers balk at prioritizing requireme
26、nts because they dont want to admit they cant do it all in the time available. Often users are also reluctant to prioritize because they fear the developers will automatically restrict the project to the highest priority items and the others will never be implemented. They might be right about that,
27、 but the alternatives can include software that is never delivered and having ill-informed people make the priority trade-off decisions. Solutions: The relative implementation priority is an important attribute of each use case, feature, or individual functional requirement. Align use cases with bus
28、iness requirements, so you know which functionality most strongly supports your key business objectives. Your high-priority use cases might be based on: The anticipated frequency or volume of usage Satisfying your most favored user classes Implementing core business processes 10 Requirements Traps t
29、o AvoidPage 5 Copyright 2000 by Karl E. Wiegers Functionality demanded for regulatory compliance If you derived functional requirements from the use case descriptions, this alignment helps you implement the truly essential functionality first. Allocate each requirement or feature to a specific build
30、 or release. Many organizations use a three-level prioritization scale. If you do, define the priority categories clearly to promote consistent classification and common expectations. A more robust solution is to analytically prioritize discretionary requirements, based on their projected customer v
31、alue and the estimated cost and technical risk associated with construction. (A spreadsheet to assist with this approach is available online; see this articles Web Infolink for more information.) Trap #5: Building Functionality No One Uses Symptoms: Ive experienced the frustration of implementing fe
32、atures that users swore they needed, then not seeing anyone use them. I could have spent that development time much more constructively. Beware of customers who dont distinguish glitzy user interface “chrome” from the essential “steel” that must be present for the software to be useful. Also beware
33、of developer gold plating, which adds unnecessary functionality that “the users are just going to love.” In short, watch out for proposed functionality that isnt clearly related to known user tasks or to achieving your business goals. Solutions: Make sure you can trace every functional requirement b
34、ack to its origin, such as a specific use case, higher-level system requirement, business rule, industry standard, or government regulation. If you dont know where a requirement came from, question whether you really need it. Identify the user classes that will benefit from each feature or use case.
35、 Deriving the functional requirements from use cases is an excellent way to avoid orphan functionality that just seems like a cool idea. Analytically prioritizing the requirements, use cases, or features also helps you avoid this trap. Have customers rate the value of each proposed feature, based on
36、 the relative customer benefit provided if it is presentand the relative penalty if it is not. Then have developers estimate the relative cost and risk for each feature. Use the spreadsheet mentioned under Trap #4 to calculate a range of priorities, and avoid those requirements that incur a high cos
37、t but provide relatively low value. Trap #6: Analysis Paralysis Symptoms: If requirements development seems to go on forever, you might be a victim of analysis paralysis. Though less common than skimping on the requirements process, analysis paralysis results when the viewpoint prevails that constru
38、ction cannot begin until the SRS is complete and perfect. New versions of the SRS are released so frequently that version numbers resemble IP addresses, and a requirements baseline is never established. All requirements are modeled six ways from Sunday, the entire system is prototyped, and developme
39、nt is held up until all requirement changes cease. Solutions: Your goal is not to create a perfect SRS, but to develop a set of clearly expressed requirements that permit development to proceed at acceptable risk. If some requirements are uncertain, select an appropriate development lifecycle that w
40、ill let you implement portions of the requirements as they become well understood. (Some lifecycle choices include the spiral model, staged release, evolutionary prototyping, and time-boxing.) Flag any knowledge gaps in your SRS 10 Requirements Traps to AvoidPage 6 Copyright 2000 by Karl E. Wiegers
41、with “TBD” markers, to indicate that proceeding with construction of those parts of the system is a high-risk activity. Identify your key decision-makers early in the project, so you know who can resolve issues to let you break out of the paralysis and move ahead with development. Those who must use
42、 the requirements for subsequent work (design, coding, testing, writing user documentation) should review them to judge when its appropriate to proceed with implementation. Model and prototype just the complex or poorly understood parts of the system, not the whole thing. Dont make prototypes more e
43、laborate than necessary to resolve the uncertainties and clarify user needs. Trap #7: Scope Creep Symptoms: Most projects face the threat of scope creep, in which new requirements are continually added during development. The Marketing department demands new features that your competitors just relea
44、sed in their products. Users keep thinking of more functions to include, additional business processes to support, and critical information they overlooked initially. Typically, project deadlines dont change, no more resources are provided, and nothing is deleted to accommodate the new functionality
45、. Scope creep is most likely when the product scope was never clearly defined in the first place. If new requirements are proposed, rejected, and resurface laterwith ongoing debates about whether they belong in the systemyour scope definition is probably inadequate. Requirement changes that sneak in
46、 through the back door, rather than through an established and enforced change control process, lead to the schedule overruns characteristic of scope creep. If Managements sign-off on the requirements documents is just a game or a meaningless ritual, you can expect a continuous wave of changes to ba
47、tter your project. Solutions: All projects should expect some requirements growth, and your plans should include buffers to accommodate such natural evolution. The first question you should ask when a new feature, use case, or functional requirement is proposed is: “Is this in scope?” To help you an
48、swer this question, document the products vision and scope and use it as the reference for deciding which proposed functionality to include. Apparent scope creep often indicates that requirements were missed during elicitation, or that some user classes were overlooked. Using effective requirements
49、gathering methods early on will help you control scope creep. Also, establish a meaningful process for baselining your requirements specifications. All participants must agree on what they are saying when they approve the requirements, and they must understand the costs of making changes in the future. Follow your change control process for all changes, recognizing that you might have to renegotiate commitments when you accept new requirements. Trap #8: Inadequate Change Process Symptoms: The most glari
