From Request to Testable Requirement — Diagram
How a stated request becomes something a team can build and a tester can prove — the three questions that do the work, and where the requirement nobody mentioned usually hides.
SVG. No sign-up, no email.
A stakeholder describes a solution because that is the vocabulary available to them. The analyst's job is to work back to the need, then forward to something testable.
Drawn out, the path is short. Almost all the value is in the middle lane — three questions, asked in order, that turn a description of a screen into a statement of behaviour.
The three questions, and what each is for#
"What decision does this support?" Converts a described artefact into a purpose. Someone asking for a dashboard is telling you they cannot see something; the requirement is the visibility, and a dashboard is one of several answers.
"Walk me through the last time this went wrong." A specific instance rather than the general case. Generalities produce generalities; a concrete Tuesday produces the systems involved, the detection mechanism, the manual workaround and the cost — usually in one paragraph.
"What do you keep in a spreadsheet outside the system, and why?" The highest-yield question in business analysis. Shadow systems mark exactly where the official system fails, they are maintained by the people doing the work, and they are frequently the most accurate requirements documentation in the organisation.
That third question is shaded because it is where the requirement nobody stated tends to be found — see the worked example, where it produced the single most important requirement on the project.
The first lane has no arrows#
Those are three shapes the same underlying need arrives in. They are alternatives, not a sequence, and each gets worked back the same way.
Why "state the negative case" is its own step#
The happy path is easy to describe and easy to build. Missing input, invalid input, duplicate submission, concurrent edit, downstream system unavailable — that is where the effort goes and where the defects land, and it is routinely a single sentence in a requirements document when it appears at all.
Making it a distinct step is the difference between a delivery team asking questions for six weeks and one that can start.
The test is the definition of done#
If you cannot state in one sentence how a requirement would be proved, it is not finished. That sentence is the acceptance test, and writing it while the requirement is being drafted — rather than months later — is the cheapest quality step available.
See business analysis, the elicitation checklist, and FRD for where these requirements are recorded.