Karl Wiegers - Software Requirements - 10 Traps To Avoid

Software Requirements: 10 Traps to Avoid
Copyright 2010 Karl E. Wiegers
Page 1

Karl E Wiegers E.
P r o c es s Impa c t
www.processimpact.com
version 3
Page 2
Have You Had Any of These Experiences?

The projects vision and scope are never clearly defined. Customers are too busy to spend time working with
analysts or developers on the requirements.
User surrogates (such as managers or marketing) claim

to speak for the users, but they really dont.
Customers claim that all requirements are critical, so

they dont prioritize them. don t
Developers encounter ambiguities and missing

information when coding, so they have to guess.
Have You Had Any of These Experiences?

Your customers sign off on the requirements and then
change them continuously.
The project scope increases as requirements

changes are accepted, but the schedule slips because more resources arent provided.
Requested requirements changes get lost and the

status of a change request is not known.
Functionality is requested and built, but never used. The specification is satisfied, but the customer is not.
Page 3
The Requirements Process -- NOT!
Trap #1: Confusion Over Requirements
Symptoms
Stakeholders discuss requirements with q
no adjectives in front.
Project sponsor presents a high-level

concept as the requirements.
User interface screens are viewed as

q the requirements.
Users provide requirements, but

developers still dont know what to build.
Requirements focus just on functionality.

Software Requirements: 10 Traps to Avoid 8 Copyright 2010 Karl E. Wiegers
Page 4
Three Levels of Software Requirements

Business Requirements
Vi i and Scope Document D t Vision d S

User Requirements Business Rules Quality Attributes
Use Case Document

Functional Requirements
External Interfaces Constraints
System Requirements
Software Requirements Specification

Trap #1: Confusion Over 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)
Distinguish functional from nonfunctional requirements.

quality attributes, constraints, external interface lit tt ib t t i t t li t f
requirements, business rules
Classify customer input into the different categories. Distinguish solution ideas from requirements.
Page 5
Trap #2: Inadequate Customer Involvement
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.
Trap #2: Inadequate Customer Involvement
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
Trap #3: Vague & Ambiguous Requirements
Symptoms
Readers interpret a requirement in several
different ways.
Requirements are missing information the

developer needs.
Requirements are not verifiable. Developers have to ask many questions. Developers have to guess a lot.
13
Trap #3: Vague & Ambiguous Requirements
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
Page 7
Trap #4: Unprioritized Requirements
Symptoms
All requirements are critical! i t iti l! Different stakeholders interpret high
priority differently.
100% 80% 60% 40% 20% 0%
After prioritization, 95% are still high.
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
Trap #4: Unprioritized Requirements
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.
Page 8
Trap #5: Building Functionality No One Uses
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.
Customers dont distinguish chrome from steel.
17
Trap #5: Building Functionality No One Uses
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
Trap #6: Analysis Paralysis
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
Trap #6: Analysis Paralysis
Solutions
Remember: the product is software, not an SRS. p , Select an appropriate development life cycle.
staged release, evolutionary prototyping, time-boxing
Decide when requirements are good enough.

acceptable risk of proceeding with construction reviewed by analyst, developers, testers, and customers analyst developers testers
Model just the complex or uncertain parts of the system. Dont include final user interface designs in SRS.
Page 10
Trap #7: Scope Creep
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.
Trap #7: Scope Creep
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.
Page 11
Trap #8: Inadequate Change Process
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.
Trap #8: Inadequate Change Process
Solutions
Define a practical change control p p g process. Set up a Change Control Board.
diverse group makes binding change decisions
Use a tool to collect, track, and communicate changes.

problem or issue tracking tools work well a tool is not a process!
Establish and enforce change control policies. Compare priorities against remaining requirements.
Page 12
Trap #9: Insufficient Change Impact Analysis
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
Trap #9: Insufficient Change Impact Analysis
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
Use requirements traceability information.

id tif all affected system components identify ll ff t d t t
Estimate costs and benefits before making commitments.
26
Page 13
Trap #10: Inadequate Version Control
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
People work from different SRS versions.

implement canceled features test against the wrong requirements
Change history and earlier document versions are lost.
27
Trap #10: Inadequate Version Control
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
Page 14
Keys to Excellent Software Requirements

Educated developers, managers, and customers A collaborative customer-developer partnership Understanding different kinds of requirements Iterative, incremental requirements development Standard requirements document templates Formal and informal requirements reviews Writing test cases against requirements Analytical requirements prioritization Practical, effective change management
Software Requirements: 10 Traps To Avoid
NO SURPRISES!
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.
32
Page 16

Karl Wiegers - Software Requirements - 10 Traps To Avoid

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Karl Wiegers - Software Requirements - 10 Traps To Avoid

Uploaded by

Copyright:

Available Formats

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Have You Had Any of These Experiences?

User surrogates (such as managers or marketing) claim

Customers claim that all requirements are critical, so

Developers encounter ambiguities and missing

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Have You Had Any of These Experiences?

The project scope increases as requirements

Requested requirements changes get lost and the

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

The Requirements Process -- NOT!

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Trap #1: Confusion Over Requirements

Project sponsor presents a high-level

User interface screens are viewed as

Users provide requirements, but

Requirements focus just on functionality.

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Three Levels of Software Requirements

Vi i and Scope Document D t Vision d S

Use Case Document

External Interfaces Constraints

Software Requirements Specification

Trap #1: Confusion Over Requirements

Distinguish functional from nonfunctional requirements.

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Trap #2: Inadequate Customer Involvement

Trap #2: Inadequate Customer Involvement

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Trap #3: Vague & Ambiguous Requirements

Requirements are missing information the

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Trap #3: Vague & Ambiguous Requirements

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers

Trap #4: Unprioritized Requirements

100% 80% 60% 40% 20% 0%

After prioritization, 95% are still high.

Software Requirements: 10 Traps to Avoid

Copyright 2010 Karl E. Wiegers