How to write good requirements

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.