Writing testable requirements: 10 rules and the EARS patterns

Most test problems start in the requirements. If a requirement can be read two ways, the developer and the tester will often read it differently. These rules come from widely used guidance such as the INCOSE Guide for Writing Requirements and ISO/IEC/IEEE 29148.

10 rules for testable requirements

1. Use "shall" for what is required. "Should" and "may" read as optional.
2. One requirement per statement. Two "shall"s usually means two requirements, each needing its own test and trace.
3. No vague words. "Fast", "user-friendly" or "as soon as possible" cannot be tested. Give a number, a limit or a condition.
4. Give units with every number. "Within 100" is not enough; "within 100 ms" is.
5. No TBD in a released requirement. Track open values separately and close them before release.
6. Avoid "and/or". Say which one you mean, or write two requirements.
7. Avoid escape clauses such as "unless", "where possible" or "if applicable". They leave the scope open.
8. Name the actor. "The BCM shall send…" is better than "The message shall be sent".
9. State behaviour, not just what must not happen. "Shall not" is harder to verify; describe the required response.
10. Keep it short. A requirement of more than about 40 words usually hides several requirements or conditions.

The EARS patterns

EARS (the Easy Approach to Requirements Syntax) offers a few simple sentence templates:

• Ubiquitous: The <system> shall <response>.
• Event-driven: When <trigger>, the <system> shall <response>.
• State-driven: While <state>, the <system> shall <response>.
• Unwanted behaviour: If <condition>, then the <system> shall <response>.
• Optional feature: Where <feature is included>, the <system> shall <response>.

Before and after

• Before: The system should respond quickly to a door opening and/or warn the driver.
• After: When a door is opened while the vehicle speed is above 5 km/h, the instrument cluster shall show the door-open warning within 200 ms.

The second version has one trigger, one state, one response, a measurable limit and a clear actor. It can be tested directly.

Try it

Paste your requirements into our free requirements quality checker. It highlights vague words, weak "should", TBDs, combined requirements and missing units, labels each requirement with its EARS pattern and exports a review sheet to Excel.