EARS
EARS (Easy Approach to Requirements Syntax) is a notation that structures natural-language acceptance criteria just enough to eliminate ambiguity without sacrificing readability. It was developed by Alistair Mavin at Rolls-Royce and presented in 2009; several SDD tools use it because its fixed form narrows an agent's room for interpretation.
EARS is not complex: it is a set of keyword-based patterns, adopted in the aerospace sector and in systems engineering, that has returned to the spotlight now that it has been integrated into tools that generate requirements criteria.
The template and the five patterns
The basic template fits together three pieces: "While [precondition], when [event], the system shall [response]." On this basis, EARS defines five patterns that cover most requirements:
| Pattern | Keyword | Use and example |
|---|---|---|
| Ubiquitous | (no trigger) | A permanent property. "The system shall encrypt all passwords with a configurable-cost algorithm." |
| Event-driven | when… | Triggered when something happens. "When a version of a document is published, the system shall queue a notification within five seconds." |
| State-driven | while… | Active while a condition holds. "While the user has do-not-disturb mode enabled, the system shall hold notifications." |
| Unwanted behavior | if… | Handles errors and abnormal situations. "If the password is entered incorrectly three times, then the system shall lock the account for 15 minutes." |
| Optional | where… | Functionality that depends on configuration. "Where the organization has enabled two-factor authentication, the system shall request a code after the password." |
The patterns can be combined: a requirement can be both state-driven and event-driven, and the template accommodates this without losing clarity.
When to use it
Agents respond well to requirements structured with consistent patterns, because the fixed form eliminates the most common ambiguities of natural language: the implicit subject, the condition where it is unclear whether it comes before or at the same time, or the response with no time limit. EARS is especially useful for making criteria verifiable: "the notification is fast" is not; "the notification reaches the channel in under 30 seconds in 99% of cases" is.
The notation is not mandatory. It is applied where the criterion is important enough to warrant the fixed form; forcing it onto every line of the spec turns an aid into an obligation. It is a tool to be used with judgement, not a universal format.
Common mistake
Vague acceptance criteria. "Fast," "intuitive," or "secure" without a threshold cannot be verified by either a person or an agent. EARS pushes toward a measurable form. The flip side also exists: forcing EARS where it adds nothing, or confusing the pattern (using "when" for a permanent property or "while" for a one-off event), distorts the criterion.
Resources
🏦 Skill User storiesState of the art and development guide · Skill Arena
📊 SDD teaching guideResources · Scrum Manager
🏦 SDD in agile teamsSkill Arena · Scrum Manager
References
- Mavin, Alistair; Wilkinson, Philip; Harwood, Adrian; Novak, Mark. (2009). "Easy Approach to Requirements Syntax (EARS)". 17th IEEE International Requirements Engineering Conference (RE'09).
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.