How to Write a Requirement That Cannot Be Misread

September 2, 2026· 11 min read

A requirement has exactly one job: to remove the gap between what is wanted and what gets built. Most bad requirements fail this job not because the writer was careless, but because no template existed. This post gives you that template — the quality bar from IEEE 29148, the sentence patterns of EARS, and the keyword discipline that keeps every sentence testable.

The quality bar: eight tests

ISO/IEC/IEEE 29148 defines the characteristics of a well-formed requirement. Think of them as eight tests every requirement must pass before it is allowed into the document.

Necessary — removing it would change the system, so it earns its place.
Unambiguous — exactly one interpretation.
Complete — no TBDs, no placeholders left for later.
Singular — one requirement per statement, never "A and B".
Feasible — buildable within the known constraints.
Verifiable — a test exists that can prove it true or false.
Correct — it states what the stakeholders actually agreed to.
Traceable — it points back to a source and forward to a test.

EARS: five sentence patterns

EARS (Easy Approach to Requirements Syntax, from Alistair Mavin and colleagues at Rolls-Royce) reduces almost every requirement to one of five templates. Once you know them, ambiguity largely disappears because the structure is fixed.

Ubiquitous — "The <system> shall <response>." Example: "The system shall log every authentication attempt."
Event-driven — "When <trigger>, the <system> shall <response>." Example: "When the user submits the form, the system shall validate every field."
Unwanted behaviour — "If <condition>, then the <system> shall <response>." Example: "If the connection is lost, then the system shall retry with exponential backoff."
State-driven — "While <state>, the <system> shall <response>." Example: "While the system is in maintenance mode, it shall reject all write requests."
Optional feature — "Where <feature>, the <system> shall <response>." Example: "Where the analytics module is enabled, the system shall emit a daily usage report."

The keyword discipline: shall, should, may

The words you use are a contract, not decoration. Requirements documents follow a strict three-level vocabulary.

Shall — a mandatory, testable requirement. The only word that belongs in a "must-happen" sentence.
Should — a goal or preference. It is not tested and does not block release; treat every "should" as a consciously deferred "shall".
May — an option or permission. The system is allowed to do it, not required to.
Avoid "must", "can", "might", and "will" for requirements — they carry legal or factual meanings that blur the line between what you require and what you merely state.

If a sentence matters, it is a "shall". If it is only nice to have, call it a "should" — and admit to yourself that it will not be tested.

Five smells and their fixes

"Fast" → "renders the list in under 500 ms for 500 items".
"User-friendly" → "a new user completes the core task in under 3 minutes without documentation".
"As needed" → name the trigger: "when the queue exceeds 1,000 messages".
A "should" that is really a "shall" → upgrade it and write the test.
TBD or TBA → resolve it now, or mark it explicitly incomplete with an owner and a date.

Worked examples

Before: "The device shall operate reliably at high temperatures."

After: "The device shall operate continuously at ambient temperatures from −20 °C to +60 °C without throttling."

Before: "The software should be secure."

After: "The software shall require multi-factor authentication for every administrative login."

Before: "The system may support multiple languages."

After: "Where multi-language support is enabled, the system shall display all user-facing strings in the selected locale."

If you cannot write the test that would fail it, you have not finished writing the requirement.