EARS: The Five Requirement Patterns That Make Specs Unambiguous
EARS — the Easy Approach to Requirements Syntax — is a set of five sentence patterns that make requirements unambiguous and testable. It was created by Alistair Mavin and colleagues at Rolls-Royce and presented at the Requirements Engineering conference in 2009, born from writing requirements for safety-critical aircraft engine control systems. It has found a second life in Spec-Driven Development, because the same constraint that helped human reviewers is exactly what makes a requirement machine-followable.
The Five Patterns
EARS classifies requirements by when they apply, and gives each a keyword and a fixed template:
- Ubiquitous (always active): "The system shall hash all passwords with bcrypt."
- Event-driven (keyword WHEN): "When a user submits valid credentials, the system shall create a session."
- State-driven (keyword WHILE): "While offline, the app shall queue pending operations."
- Unwanted behaviour (keyword IF/THEN): "If the payment gateway times out, then the system shall retry twice."
- Optional feature (keyword WHERE): "Where dark mode is enabled, the UI shall use the dark tokens."
The clause order never changes: optional precondition, then trigger, then system, then response. That consistency is the whole trick — it reads like normal English while eliminating the ambiguity normal English permits.
Why It Matters More With Agents
Each pattern maps naturally onto implementation and test structure: ubiquitous requirements become invariants, event-driven ones become handlers with integration tests, state-driven ones become state machines, unwanted-behaviour ones become error paths. The class of the requirement tells the implementer what kind of code and test it demands. Constrained syntax is context an agent cannot misread.
The Compound-Requirement Smell
If a requirement joins two behaviours with "and," it is two requirements sharing a number — and an agent may implement one and skip the other while the line still reads as done. Split it. One requirement, one behaviour, one verdict. Rewriting a spec's requirements into EARS takes minutes and is diagnostic in itself: a requirement that resists every pattern is usually not one requirement, or not yet understood.