Chapter Summary

Chapter 2:

Requirements from the Customer’s Perspective

© Karl E. Wiegers

2.1 Who is the Customer?

� Whoever benefits from the product

� Whoever requests and pays for the product

� Whoever uses the product

� Whoever receives the product’s output

� A very important stakeholder

2

2.2 Customer-Developer Partnership

� Excellent software comes from: ◦ Well-executed design

◦ Excellent requirements

� Excellent requirements come from collaboration between customer and developer

� Both parties must realize what is necessary for success.

3

2.3 Customer’s Bill of Rights

1. Expect analysts to speak your language

2. Expect analysts to learn your business and your objectives for the product.

3. Expect analysts to translate your information into a written/graphic specification

4. Expect analysts to explain all of the work products of the requirements process

4

5. Expect analysts to be respectful, collaborative, and professional

6. Expect analysts to offer alternatives for your requirements and the product’s implementation

7. Describe “easy, enjoyable to use” product characteristics

5

8. Expect opportunities to adjust requirements to allow component reuse

9. Receive credible cost and schedule impacts for changes, with tradeoffs

10. Receive a system that meets your needs (the communicated and agreed-to ones)

6

2.4 Customer’s Bill of Responsibilities

1. Educate developers about your business and its jargon

2. Spend all necessary time to provide and clarify requirements, iteratively

3. Be specific and precise

4. Make timely decisions about requirements

7

5. Respect the developer’s cost estimates and feasibility assessments

6. Set priorities for requirements, features, use cases

7. Review documents and evaluate prototypes

8. Communicate changes immediately

8

9. Follow the developer’s change process

10. Respect the analyst’s engineering process

9

2.5 Requirements Signoffs

� Problems:

◦ Customer doesn’t read the requirements specification he’s agreeing to

◦ Developer treats specification as “cast in stone,” never to be changed.

� The reality

◦ Can’t possibly know all requirements that early—they will always change

10

2.6 Establishing the Baseline

� Snapshots in time

� Conversion of fluid work-in-progress into stable, controlled, agreed-to specification

� Customer must realize that changes may cause renegotiation of cost, schedule, and scope

� Developer must realize that the baseline defines a “promise to perform”

11

Stakeholder Confidence

� Customer manager is assured that scope won’t grow wildly

� Users are assured that developers will work to build the right system for them

� Developer manager is assured that customer will stay focused on objectives, will balance cost, schedule, functionality

� Analysts are assured that changes won’t create chaos

12