Working out what to build before you build it: finding needs, writing clear requirements, and managing change. Press play on any sketch to watch it happen.
1 Finding out what people need
Elicitation is the work of discovering requirements. Users rarely know exactly what they want, and different groups want different things, so you gather from several sources and resolve the conflicts.
Stakeholders: anyone affected: users, managers, support staff, regulators.
Interviews and workshops: ask about their work and pain, not about features.
Observation: watch people work, because they often describe it inaccurately.
Prototypes: a rough sketch draws out better feedback than a document does.
Process diagram
1/4 Users ask for fewer steps when placing an order.
Rule of thumb: Ask "why?" until you reach the real need. Requests are often solutions in disguise.
2 Writing good requirements
A requirement should be clear enough to test. Functional requirements say what the system does, and non-functional requirements say how well it must do it. "Fast" means nothing until it has a number.
Functional: behaviour: the system shall email a receipt.
User story: As a [role], I want [goal], so that [reason].
Acceptance criteria: the conditions that prove a story is done.
MoSCoW: sort into Must, Should, Could and Won't have.
As a shopper, I want to reset my password,
so that I can get back into my account.
Given I requested a reset link
When I open it within 30 minutes
Then I can choose a new password
Before and after
1/3 This sounds fine, but nobody can test it. Fast to whom?
Rule of thumb: If you cannot write a test for it, it is not yet a requirement.
3 Traceability and change
Requirements will change. Traceability links each requirement to its design, code and tests, so you can see what a change touches and prove that everything needed got built and tested.
Traceability matrix: a table mapping requirements to the work that meets them.
Impact analysis: work out what a change affects before agreeing to it.
Change control: an agreed way to request, assess and approve changes.
Scope creep: small unplanned additions that quietly sink a schedule.
Traceability diagram
1/4 Each requirement is linked to the design, code and test that deliver it.
Rule of thumb: Say "yes, and here is what it costs", not simply yes. Every change has a price.
