How to write good requirements
A good requirement is clear, verifiable, atomic, and traceable. Here are the practical rules, the pitfalls that create rework, and before-and-after examples.
A good requirement states one testable thing in one sentence, in language that admits a single reasonable interpretation. It says what the system must do rather than how to build it, carries a unique identifier, and traces up to the need it serves and down to the verification that proves it. If you cannot imagine the test, it is not finished.
The characteristics of a good requirement
- Clear and unambiguous: one reasonable interpretation, not several.
- Verifiable: you can write a test, inspection, or analysis that proves it.
- Atomic: one requirement per statement, so it can be traced and tested on its own.
- Feasible: achievable within the constraints of the project.
- Necessary: it traces to a real user need, not a nice-to-have someone invented.
- Traceable: it carries a unique identifier and links up to a need and down to verification.
Common pitfalls
- Vague adjectives: “fast”, “robust”, “user-friendly” cannot be verified.
- Compound requirements: “and” or “or” usually means two requirements hiding in one.
- Solutioneering: stating how to build it instead of what is needed.
- Untestable intent: if you cannot describe how to prove it, rewrite it.
Before and after
Weak: The system shall respond quickly.
Better: The system shall display the search results within 2 seconds of the query being submitted, for result sets up to 1,000 rows.
The second version is measurable, so it is testable, so it is traceable to a verification.
Make good requirements stick
Writing one good requirement is easy; keeping a whole set clear, uniquely identified, and traced as the project changes is the hard part. A tool that treats requirements as structured, identified, linked data, rather than prose in a document, is what keeps quality from decaying. See requirements management software and the traceability matrix.
Related guides
This guide is educational and does not certify any product or organisation.
Common questions
What makes a good requirement?
A good requirement is clear, unambiguous, verifiable, atomic (one requirement per statement), feasible, and traceable to a need above it and a test below it. If you cannot write a test for it, it is not yet a good requirement.
What is the most common requirements mistake?
Ambiguity. Words like "fast", "user-friendly", or "as needed" cannot be verified. Replace them with measurable, testable criteria.
Should a requirement say how, or just what?
Requirements should state what is needed, not how to implement it, unless the constraint is genuinely a requirement. Mixing in design decisions makes requirements brittle and over-specified.
Keep your requirements clear and traceable
Write requirements as structured, linked data and see coverage stay current.