How to write clear requirements with the EARS notation

Most requirements problems trace back to one root cause: ambiguous language. “The system should handle errors gracefully” can’t be tested, can’t be verified, and means something different to every reader. EARS — the Easy Approach to Requirements Syntax — is a lightweight set of patterns that fixes this without forcing you into a heavy formal method.

Developed by Alistair Mavin and colleagues at Rolls-Royce, EARS gives requirements a consistent, readable structure that makes them clearer to write, easier to review, and — crucially — straightforward to verify. This guide walks through the five patterns with examples.

Why structure matters

A good requirement is unambiguous, testable, and traceable. Free-form prose works against all three: it hides assumptions, buries conditions, and makes it hard to tell where one requirement ends and another begins. EARS adds just enough structure to remove the ambiguity while staying plain English — anyone can read an EARS requirement without training.

The patterns are built around a simple spine: the <system> shall <response>, with an optional precondition or trigger in front of it.

The five EARS patterns

1. Ubiquitous — an always-active requirement with no trigger.

The control system shall maintain pressure below 5 bar.

2. Event-driven — triggered by an event, using When.

When the start button is pressed, the control system shall begin the heating cycle.

3. State-driven — active while a condition holds, using While.

While the device is in maintenance mode, the control system shall disable all actuators.

4. Optional-feature — applies only when a feature is present, using Where.

Where the device includes a wireless module, the control system shall encrypt all transmitted data.

5. Unwanted-behavior — handles errors and undesired conditions, using If/Then.

If a sensor reading is out of range, then the control system shall enter a safe state and log the fault.

A sixth, complex, simply combines these (for example, a While state with a When trigger) for requirements that genuinely need more than one condition — used sparingly, because complexity is where ambiguity creeps back in.

How EARS improves verification and traceability

Structured requirements pay off well beyond authoring:

• Testability. Each pattern makes the trigger, condition, and expected response explicit — which is exactly what a test case needs. An event-driven requirement practically writes its own test.
• Reviewability. Reviewers can spot a missing condition or an untestable response at a glance, instead of parsing prose.
• Traceability. Clean, atomic requirements link cleanly to design and tests. Vague, compound requirements are the ones that end up with partial or missing coverage in your requirements traceability matrix.

EARS pairs naturally with the standards that demand requirements-based testing — DO-178C, IEC 62304, and ISO 26262 all become easier to satisfy when each requirement has a clear, verifiable form.

Putting it into practice

EARS is a convention, not a tool — you can start using it today in whatever you author requirements in. It works best, though, when the system you write in helps: surfacing weak or ambiguous requirements, checking testability, and keeping each requirement linked to the tests and risks it touches.

That’s part of what TraceUnified does: requirements are governed records on one traceability graph, and its AI can analyze a requirement for ambiguity, missing criteria, and weak verifiability and propose a clearer rewrite — advisory only, on a model you bring. You decide what to accept; the structure and the thread stay intact.