EARS — the Easy Approach to Requirements Syntax — is a lightweight grammar for writing natural-language requirements that stay unambiguous, testable, and complete. It was developed by Alistair Mavin, Philip Wilkinson, Adrian Harwood, and Mark Novak at Rolls-Royce PLC, and published at IEEE RE ‘09 (pp. 317–322). Specy adopts EARS as the single syntax for every system requirement, functional and non-functional alike.

Origin

EARS was designed inside a jet-engine division at Rolls-Royce, where the cost of an ambiguous requirement is measured in recertifications and grounded fleets. The authors — Mavin, Wilkinson, Harwood, and Novak — studied how engineers wrote requirements in practice, identified recurring failure modes, and synthesized a small grammar that constrained authoring without demanding a formal notation. The paper “Easy Approach to Requirements Syntax (EARS)” appeared in the Proceedings of the 17th IEEE International Requirements Engineering Conference (RE ‘09), pages 317–322.

Eight Deficiencies of Natural Language

EARS is a remedy for eight recurring deficiencies of unconstrained requirements prose. The grammar is engineered so that an author who follows it cannot easily fall into any of them.

  • Ambiguity — the same sentence admits two plausible readings. EARS removes it by forcing preconditions and triggers into explicit clauses.
  • Vagueness — words like fast, user-friendly, reasonable appear without a measurable anchor. EARS requires the system response to be observable.
  • Complexity — one sentence describes three behaviors. EARS caps each requirement at one response statement per sentence.
  • Omission — error handling, edge cases, or the triggering event are missing. The If-Then pattern makes unwanted behaviors impossible to skip silently.
  • Duplication — the same obligation is restated in two requirements with different words. Stable IDs and single-sentence statements make duplicates visible.
  • Wordiness — the statement is padded with purpose, context, and motivation. EARS moves rationale out of the statement into a dedicated :: clause.
  • Inappropriate implementation — the requirement prescribes how instead of what. EARS forces an obligation on the system name, not on a technology.
  • Untestability — there is no procedure that could decide whether the requirement is met. EARS responses are verifiable because they are event-bound and system-bound.

Example: Before: “The ordering module should be fast and reliable when customers place orders.” This is vague, ambiguous, and untestable. After: "When a customer submits an order, the system shall respond within 500 ms at p95." The trigger is explicit, the system is named, the response is measurable.

The EARS Ruleset

Every EARS requirement conforms to a single structural template:

[While <precondition(s)>,] [When|If|Where <trigger or condition>,]
the <system name> shall <system response(s)>.

The constraints are enumerated below, in the order they appear in the sentence. The order is temporal, not cosmetic — the sentence reads as the behavior unfolds in time.

  • Preconditions — zero or many, introduced by While. Recommended limit: three. Beyond three, decompose into separate requirements or use a decision table.
  • Trigger — zero or one, introduced by When, If, or Where. Exactly one keyword may appear in this slot.
  • System name — exactly one. The entity, aggregate, service, or bounded context being specified.
  • System response — one or many. The required behavior, stated with shall.
  • Temporal order — clauses always appear in the same order: preconditions → trigger → system name → response.

Example: "While the customer has an active credit account, when an order is placed, if the order total exceeds the remaining credit limit, then the system shall hold the order for manual approval." (This is REQ-ORD-005 from the Order Processing running example.) The preconditions, trigger, system name, and response appear in strict temporal order.

The Four Keywords

EARS introduces only four keywords. Each has one role, and the role is non-overlapping with the others.

  • While — opens a precondition. The requirement is active only while the stated state or condition holds. Multiple While clauses may appear.
  • When — opens a trigger event. The requirement fires on the occurrence of the stated event or action.
  • If — opens an unwanted condition. The requirement prescribes how the system responds to an undesired situation, error, or failure. Paired with then.
  • Where — opens an optional capability guard. The requirement applies only to variants that enable the named capability (a deployment-time flag, product-line tier, or regional variant — not a PRD Feature).

Example: Each keyword maps to one of the six EARS patterns described in EARS Patterns. A requirement with no keyword is ubiquitous — an always-active obligation.

The Single-Sentence Rule

An EARS requirement is a single sentence. This is not a stylistic preference — it is a structural constraint that keeps the grammar provably unambiguous. Two sentences hide coordination; one sentence surfaces it. If a requirement resists single-sentence form, that resistance is information: the obligation is probably two requirements in disguise, and it must be decomposed before it can be verified.

Example: "When payment is verified, the system shall confirm the order." (REQ-ORD-007.) One sentence. One trigger. One system. One response. A second obligation — say, emitting an invoice — would become a separate requirement with its own ID.

Why EARS Fits Specy

Specy’s three verification loops — Build, Check, Observe — all exploit EARS structure. The Build loop reads requirements as input and produces a domain model whose elements declare satisfies references back to requirement IDs. The Check loop traverses those satisfies lists and flags any requirement with no satisfier. The Observe loop is only possible because When and If requirements are directly observable at runtime: the observer traces event flows and verifies that the declared behaviors actually occur. Take the keywords away and the loops lose their handle on intent.

Example: A requirement written as “The order flow should work smoothly” is invisible to all three loops — nothing to build against, nothing to check, nothing to observe. The same obligation written as "When a customer submits an order, the system shall create the order in draft status and emit an OrderPlaced event." is actionable by every loop: the builder wires the command, the checker confirms the OrderPlaced event satisfies the requirement, and the observer confirms the event actually fires in production.