Professional Documents
Culture Documents
Page 1
version 3
Page 2
Functionality is requested and built, but never used. The specification is satisfied, but the customer is not.
Page 3
Symptoms
Stakeholders discuss requirements with q
no adjectives in front.
Page 4
System Requirements
Solutions
Adopt templates for three sets of requirements. p p q
business requirements (Vision & Scope Document) user requirements (Use Case Document) software requirements (Software Requirements
Specification)
Classify customer input into the different categories. Distinguish solution ideas from requirements.
Software Requirements: 10 Traps to Avoid 10 Copyright 2010 Karl E. Wiegers
Page 5
Symptoms
Some user classes are overlooked. Some user classes dont have a voice. User surrogates attempt to speak for users.
user managers marketing developers
Developers have to make many requirements decisions. Customers reject the product when they first see it.
Software Requirements: 10 Traps to Avoid 11 Copyright 2010 Karl E. Wiegers
Solutions
Identify your various user classes. yy Identify product champions as user representatives. Convene focus groups. Identify decision-makers. Have users evaluate prototypes. Have user representatives review the SRS.
12
Page 6
Symptoms
Readers interpret a requirement in several
different ways.
Requirements are not verifiable. Developers have to ask many questions. Developers have to guess a lot.
13
Solutions
Formally inspect requirement documents. Write conceptual test cases against requirements. Model requirements to find knowledge gaps. Use prototypes to make requirements more tangible. Define terms in a glossary. g y Avoid ambiguous words:
minimize, maximize, optimize, rapid, user-friendly, simple,
intuitive, robust, state-of-the-art, improved, efficient, ideally, flexible, several, and/or, etc., include, support, adequate
Software Requirements: 10 Traps to Avoid 14 Copyright 2010 Karl E. Wiegers
Page 7
Symptoms
All requirements are critical! i t iti l! Different stakeholders interpret high
priority differently.
L M H
Developers don t want to admit they can t do it all. dont cant Its not clear which requirements to defer during the
rapid descoping phase.
15
Solutions
Align functional requirements with business requirements. g q q Align functional requirements with high-priority use cases.
frequency of use favored user classes core business processes demanded for regulatory compliance
Define priority categories unambiguously. Allocate requirements or features to releases. Analytically prioritize discretionary requirements.
Software Requirements: 10 Traps to Avoid 16 Copyright 2010 Karl E. Wiegers
Page 8
Symptoms
Users demand certain features, then no one uses them. , Proposed functionality isnt related to business tasks. Developers add functions because the users will love
this.
17
Solutions
Derive functional requirements from use cases. q Trace every functional requirement back to its origin. Identify user classes who will benefit from each feature. Analytically prioritize requirements, use cases, or
features. have customers rate value (benefit and penalty) have developers estimate cost and risk avoid requirements with high cost and low value
18
Page 9
Symptoms
Requirements development seems to g on forever. q p go New versions of the SRS are continually released. Requirements are never baselined. All requirements are modeled six ways from Sunday. Design and coding cant start until the SRS is perfect. can t
19
Solutions
Remember: the product is software, not an SRS. p , Select an appropriate development life cycle.
staged release, evolutionary prototyping, time-boxing
Model just the complex or uncertain parts of the system. Dont include final user interface designs in SRS.
Software Requirements: 10 Traps to Avoid 20 Copyright 2010 Karl E. Wiegers
Page 10
Symptoms
New requirements are continually added.
schedule doesnt change no more resources provided
Product scope is never clearly defined. Proposed requirements come, and go, and come back. Requirement changes sneak in through the back door door. Scope issues are debated during SRS reviews. Sign-off is just a game.
Software Requirements: 10 Traps to Avoid 21 Copyright 2010 Karl E. Wiegers
Solutions
Determine root causes of the scope creep. p p Document the products vision and scope. Define system boundaries and interfaces. Follow the change control process for all changes. Improve requirements elicitation methods. Follow a meaningful baselining process. Renegotiate commitments when requirements change.
Software Requirements: 10 Traps to Avoid 22 Copyright 2010 Karl E. Wiegers
Page 11
Symptoms
No change process is defined. Some people bypass the change process.
talk to buddies on the inside implement rejected changes work is done on proposed changes before theyre approved
New functionality becomes evident during testing. Unclear change request status. Changes arent communicated to all those affected. Its not clear who makes change decisions.
Software Requirements: 10 Traps to Avoid 23 Copyright 2010 Karl E. Wiegers
Solutions
Define a practical change control p p g process. Set up a Change Control Board.
diverse group makes binding change decisions
Establish and enforce change control policies. Compare priorities against remaining requirements.
Software Requirements: 10 Traps to Avoid 24 Copyright 2010 Karl E. Wiegers
Page 12
Symptoms
People agree to make changes hastily. p g g y Change is more complex than anticipated. Change takes longer than promised. Change isnt technically feasible. Change causes project to slip. Developers keep finding more system
components affected by the change.
25
Solutions
Systematically analyze the impact of each p p y y y p proposed
change. identify all possible tasks consider other implications of accepting the change estimate effort and schedule impact
26
Page 13
Symptoms
Accepted changes arent incorporated into SRS. p g p You cant distinguish different SRS versions.
different versions have the same ID identical documents have different IDs
27
Solutions
Merge changes into the SRS. g g Adopt a versioning scheme for documents. Place requirements documents under version control.
restrict read/write access make current versions available read-only to all
C Communicate revisions t all who are affected. i t i i to ll h ff t d Use a requirements management tool.
record complete history of every requirement change SRS is a report from the database
Software Requirements: 10 Traps to Avoid 28 Copyright 2010 Karl E. Wiegers
Page 14
NO SURPRISES!
Software Requirements: 10 Traps to Avoid 30 Copyright 2010 Karl E. Wiegers
Page 15
Requirements References
Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs. Boston: Addison-Wesley, 2002. IEEE Std. 830-1998, "Recommended Practice for Software Requirements Specifications. Specifications " Los Alamitos, Ca : IEEE Computer Society Press 1998 Alamitos Ca.: Press, 1998. Lauesen, Soren. Software Requirements: Styles and Techniques. London: AddisonWesley, 2002. Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Use Case Approach, 2nd Ed. Reading, Mass.: Addison Wesley, 2003. Robertson, Suzanne, and James Robertson. Mastering the Requirements Process , 2nd Ed. Harlow, England: Addison-Wesley, 2006. Sommerville, Ian, Sommerville Ian and Pete Sawyer Requirements Engineering: A Good Practice Guide Sawyer. Guide. New York: John Wiley & Sons, 1997. Wiegers, Karl E. Software Requirements, 2nd Ed. Redmond, Wash.: Microsoft Press, 2003. Wiegers, Karl E. More About Software Requirements: Thorny Issues and Practical Advice. Redmond, Wash.: Microsoft Press, 2006.
Software Requirements: 10 Traps to Avoid 31 Copyright 2010 Karl E. Wiegers
32
Page 16