EARS: five patterns for requirements agents can't misread

Constrained syntax, zero ambiguity

EARS (Easy Approach to Requirements Syntax) came out of Rolls-Royce in 2009 for safety-critical engine control. Five patterns, fixed clause order:

Ubiquitous:  The <system> shall <response>
Event:       When <trigger>, the <system> shall <response>
State:       While <state>, the <system> shall <response>
Unwanted:    If <cond>, then the <system> shall <response>
Optional:    Where <feature>, the <system> shall <response>

Why it maps so well to code

Each class implies its implementation and test shape:

• Ubiquitous → invariants
• Event → handlers + integration tests
• State → state machines
• Unwanted → error paths

The requirement's class tells the agent what kind of code and test it demands. Constrained syntax is context an agent cannot misread.

The compound-requirement smell

A requirement with "and" joining two behaviours is two requirements sharing a number — the agent may do one and skip the other while the line reads as done. Split it: one requirement, one behaviour, one verdict.

Try it in five minutes

Rewrite one spec's requirements into EARS. A requirement that resists every pattern usually isn't one requirement — the exercise is diagnostic by itself.

Free cheat sheet: the whole method on a few pages — the loop, spec anatomy, EARS, right-sizing — SDD Cheat Sheet.

Go deeper: the full reference — every phase, the tool landscape, three walkthroughs — Spec-Driven Development: The Complete Guide.

Anyone using EARS in their specs yet? Which pattern do you reach for most? 👇