Needs first, then requirements
A need is what someone wants to be true. A requirement is what the system must do to make it true — and be provable.
- You can translate a vague ask into statements a tester could pass or fail.
- You can spot the three requirement diseases: vagueness, compounding, and a solution smuggled into the "what".
"We need a chatbot." That sentence has already made four decisions — the interface, the medium, the architecture, and the assumption that conversation is the right answer — and none of them are on the table. This is the most expensive sentence in software, and it is not a requirement. It is a solution wearing a requirement's coat.
Systems engineering separates the two spaces deliberately. In the problem space you describe outcomes and constraints in the stakeholders' own language. Only when that is stable do you cross into the solution space and commit to behavior the system must exhibit.
2.1The five tests of a requirement
| Test | Ask | Fails when… |
|---|---|---|
| Specific | Could two competent people read this differently? | "fast", "easy", "robust", "user-friendly" |
| Verifiable | Which method proves it — inspection, analysis, demonstration, test? | No threshold, no observable, no condition |
| Singular | Does it contain "and"? | Three requirements in one line, tested as one |
| Necessary | Which need does it trace to? | Features nobody asked for; gold plating |
| Feasible | Can it be met within cost, time and physics? | Aspirational targets with no path |
Use "shall" for mandatory requirements. "Should" is a preference, "may" is optional, "will" is usually a statement of fact. This sounds pedantic until a contract dispute turns on it.
2.2The requirement clinic
Three real-shaped requirements. Diagnose before you rewrite — the habit matters more than the wording.
"The system shall be user-friendly and respond quickly."
- Vague: "user-friendly" and "quickly" are unmeasurable.
- Compound: two requirements in one sentence, so a pass on one hides a fail on the other.
- No condition: quick for whom, on what device, at what load?
# rewrite: one behavior per line, with numbers and a condition
REQ-011 The dashboard shall render in < 2.0 s at p95 on a 4G connection.
REQ-012 A first-time user shall complete onboarding in < 3 min without support.
REQ-013 The system shall achieve a SUS usability score > 80 in the acceptance study."The system shall use Redis for caching."
- Solution smuggled in: this is a design decision wearing a requirement. It removes your ability to trade off later.
- No outcome: nothing here says what improves for the user.
- Unless Redis is a real constraint — a license, an existing platform standard, a compliance rule. Then say so explicitly as a constraint.
# rewrite: state the outcome, keep the choice open
REQ-021 Repeated identical queries shall be served in < 10 ms.
REQ-022 The system shall serve a 10× traffic spike without p95 degradation > 20%.
CON-003 Constraint: the cache shall run on the existing managed Redis instance."The system shall not crash."
- Negative-only: says nothing about what it should do instead, so you can't design for it.
- Unfalsifiable: every system crashes eventually; the requirement gives no boundary.
- No recovery expectation: does failing over count? Degrading? Queueing?
# rewrite: state availability, degradation, and recovery as observable behavior
REQ-031 The service shall be available 99.9% of the time per calendar month.
REQ-032 If the primary model is unavailable, the system shall fail over to the
secondary within 5 s and continue serving.
REQ-033 On restart, in-flight tasks shall resume from the last checkpoint,
losing no more than 1 minute of work.2.3What "done" means, in writing
Every requirement needs an acceptance criterion — the observation that settles whether it passed. For quantitative requirements, name the method: test (controlled measurement), analysis (model or calculation), demonstration (operate it and watch), inspection (read it and compare).
| Type | Shape of the statement | Acceptance method |
|---|---|---|
| Functional | The system shall do X when Y | Demonstration or test |
| Performance | …in < N ms at p95, under M concurrent users | Load test |
| Interface | …expose / consume contract C with fields F | Inspection + integration test |
| Constraint | …shall not do prohibited thing | Inspection, audit |
| Reliability | …99.9% monthly availability, 5 s failover | Analysis + failure injection |
| Usability | …onboarding < 3 min, SUS > 80 | User study |
Pick one thing you are building. Write its business need in one sentence, then write four system requirements — one functional, one performance, one interface, one constraint. For each, write the method that would prove it. If a line has no method, you have found the part of the project that will be argued about later.
A requirements document that nobody tests against is worse than none: it creates the appearance of rigour while decisions are still made by whoever is loudest. Trace every requirement to a test, a review or an eval — or delete it.
Which statement is a usable requirement?
60-second recap
- Needs describe outcomes; requirements describe testable behavior. Don't let a solution cross the line early.
- Five tests: specific, verifiable, singular, necessary, feasible.
- "Shall" means mandatory. Every requirement gets an acceptance method.
- Untested requirements are fiction. Trace to a test, a review or an eval.