The Customer's Rights and Responsibilities
In short Wiegers and Beatty set out ten rights customers can expect from analysts and developers, and ten matching responsibilities customers take on in return. Discussed at the start of a project, together with explicit decision rules and a sensible meaning of sign-off, they prevent much of the friction around requirements.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 2.
On this page
Key ideas#
The expectation gap#
The expectation gap is the distance between what customers actually need, which shifts over time, and what developers build from their understanding at the start. Without contact, the gap keeps growing. Each touchpoint (an interview, a requirements review, a prototype demo, feedback on a working increment) closes part of it before it starts growing again. Frequent touchpoints keep the final gap much smaller.
Stakeholders vs. customers#
A stakeholder is any person, group or organization involved in a project, affected by it, or able to influence it. Customers are a subset: those who request, pay for, select, specify, use or receive the output of the product. Lawyers, auditors, suppliers, contractors and investors are stakeholders but not customers.
The book groups possible stakeholders into three circles: the project team, the wider developing organization (marketing, support, training, management), and people outside it (direct and indirect users, buyers, procurement, regulators, certification bodies, subject-matter experts, beta testers, the public). It also tells of a tax department nobody knew about until a late process review, which delayed the project by months. Start with a wide list and narrow it down.
Rights and responsibilities, paired#
The book gives the rights and responsibilities as two separate lists of ten. Pairing them, as below, makes them easier to use in conversation: “you have this right, and this is the matching responsibility.”
| The customer has the right to… | …and the responsibility to… |
|---|---|
| Work with analysts who speak their language and take time to learn their business and objectives | Educate analysts about the business, and spend the time needed to clarify requirements |
| Have requirements recorded in a suitable form, and have the requirements work products explained | Be specific and precise; use TBD (“to be determined”) to mark genuine open questions, not to dodge hard ones |
| Hear about options and alternatives, including reuse that could speed up delivery | Respect developers’ estimates of cost and feasibility (“within 50 milliseconds” is feasible where “instantly” is not) and set realistic priorities together with them |
| Describe concretely the characteristics that will make the product easy to use | Review requirements, evaluate prototypes and define acceptance criteria |
| Change their requirements, knowing that change has a cost | Communicate changes promptly and respect the requirements process |
| Mutual respect | Make timely decisions when asked |
| Receive a system that meets their functional and quality expectations | Do all of the above; this right depends on the responsibilities being met |
Decide how decisions are made#
A project faces many requirements decisions. Agree early who makes them and by what rule. Wiegers and Beatty cite six decision rules from Ellen Gottesdiener: the leader decides alone, with or without discussion; majority vote; unanimous vote; consensus, where everyone commits to support the result; delegation to a named person; or group decision where one member holds a veto. No rule is always right. What matters is choosing one before the first significant decision.
What sign-off should mean#
A requirements baseline is a snapshot of the requirements agreed at a point in time. Wiegers and Beatty warn against two misreadings of sign-off. Customers may treat it as a formality and sign without reading. Development managers may use it as a weapon: “You signed, so no changes.” A better meaning: this is our best shared understanding today; future changes will go through the agreed change process; and changes may require new estimates of cost, resources and schedule.
If you cannot get agreement, often because people fear they cannot change anything after approval, record that as a risk, continue with the current requirements as the baseline, and tell the dissenting parties clearly.
In agile projects#
There is usually no formal sign-off. The product owner and the team agree on an iteration’s stories at planning, based on priority and velocity (the team’s measured pace); that set is fixed for the iteration, and new changes go to later ones. The real sign-off is accepting tested, working software at the end. In a case the book describes, a client insisted on formal sign-off even on an agile project. The team redefined it to mean “no known missing requirements or serious issues at this point”, not a permanent freeze.
How to apply it#
- At kickoff, walk through the paired table with the key customers and adjust it.
- Write down who decides on requirements, and by which rule.
- Plan touchpoints across the whole project.
- Use the sign-off wording below for every baseline.
- When friction appears, go back to the table.
Template#
Requirements baseline sign-off — <project>, version <x.y>, <date>
I confirm that this set of requirements represents our best shared
understanding of the project's needs as of this date. I understand
that future changes will follow the agreed change process, and that
changes may require new estimates of cost, resources and schedule.
Name / role / signature
Example#
At kickoff for The Workshop, a fictional bike-repair chain, the analyst walks the owner and two workshop managers through the paired table. They agree three decision rules: the owner decides scope after discussion; the workshop managers decide process details by consensus; disputes about screen layout are delegated to the front-desk champion. Touchpoints are set as a fortnightly demo. At the first baseline, one manager hesitates to sign for fear of being “locked in”; the analyst shows the sign-off wording and the change process, and the manager signs.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 2.