A requirement is a need written down so that someone can check it: the owner before the scope is signed, and a test once the work is built. Here are the techniques for capturing them, and where each one fits.
Communication
Everything else rests on this. Listen more than you talk, ask about what has happened rather than what might, and keep the conversation going for the length of the job.
The owner, the users and the webmasters
On a Sean Dinwiddie’s Webmastery job, requirements come from the owner who signs the written scope, the people who use the result, such as the counter staff, and the webmasters on the job. Each sees what the others miss, so each is asked.
Empathy and user-centric thinking
Write each requirement from the side of the person it serves, in their words rather than the software’s. “A customer can see what has sold out today” is a requirement; “add a stock field to the menu” is already a design, and it may not be the one that serves them.
Elicitation techniques
Four of them, each with its place:
- Interviews: One-on-one or group conversations with the owner, the people who use the result and the staff who serve them.
- Surveys: A few questions about the last visit, sent to regulars or left at the counter, for the customers an interview doesn’t reach.
- Observation: Watching the work where it happens, at the counter or on the phone, to see what people do rather than what they remember doing.
- Walk-throughs: Following one real case from start to finish with the person who handled it, such as last Friday’s catering order, to find each step the software has to take on.
Writing requirements down
Requirements are written down where everyone on the job reads them. On the Sean Dinwiddie’s Webmastery team, that means user stories, named in the written scope, in the familiar template: “As a [type of user], I want [an action] so that [benefit/value].” Its first words name the person it serves, so each story starts from the user’s side. A rule every story has to meet is written once beside them, as a constraint, as the end of this lesson shows.
Prioritization
Some requirements can wait. Prioritization sorts what was gathered into required and optional work, and the written scope lists the two apart, so the owner sees what each adds, and what it costs, before choosing.
Validation and feedback
Read each requirement back to the people it came from before the scope is signed, and correct it in their words.
After the build, the owner checks the work against its acceptance criteria. A trial run with the people who use it, such as the counter staff on a quiet afternoon, shows whether each requirement was the right one, and one that wasn’t becomes a new story, scoped as a change.
Iteration
Requirements change as the business does: a new service, a second location, a new rule from the county. Each change is captured the same way, in the words of the person it serves and read back to them, and becomes a story of its own, scoped before it is built. When a requirement changes, the code follows it; the lecture Functional Programming Maintenance Strategy keeps that change small, one pure function at a time.
Requirements captured this way, in the user’s words and checked with them, are what the rest of the job is built on. User stories, defined earlier in this module, carry these requirements into the written scope.
The next lesson, on translating user needs into user stories, writes them as stories with acceptance criteria.