Guide · Sheet 10

How to write EARS requirements
(with worked examples)

EARS — the Easy Approach to Requirements Syntax — is five sentence templates developed at Rolls-Royce for jet engine control requirements. The templates work because they make a requirement declare, structurally, when it applies. Most requirements defects are exactly that information gone missing.

The five patterns

Ubiquitous — always true, no precondition:
The <system> shall <response>.
The flight recorder shall store the most recent 25 hours of parametric data.

Event-driven — fires once each time a trigger occurs:
When <trigger>, the <system> shall <response>.
When the operator commands shutdown, the controller shall close the fuel valve within 200 ms.

State-driven — active for as long as a state persists:
While <state>, the <system> shall <response>.
While the aircraft is on the ground, the system shall inhibit thrust reverser deployment above idle.

Optional feature — applies only in configurations that include a feature:
Where <feature is included>, the <system> shall <response>.
Where the aircraft includes a second ADC, the system shall compare altitude sources at 1 Hz.

Unwanted behaviour — the response to a failure or off-nominal condition:
If <trigger>, then the <system> shall <response>.
If the primary sensor signal is lost, then the system shall switch to the backup sensor within 50 ms and set the DEGRADED flag.

The keywords are the classifier: when means event, while means state, where means configuration, if/then means failure handling, and none of the above means always. Patterns can combine (While in cruise, when the fuel imbalance exceeds 200 kg, the system shall…) — legitimate, as long as every condition is genuinely necessary.

Worked example 1: the vague aspiration

Before: The system should be user-friendly and respond quickly to user inputs, if possible.

Four separate defects. Should creates no obligation — a reviewer can't fail a system for not doing what it merely should. User-friendly and quickly are unverifiable: no test exists whose pass/fail line they define. And if possible is an escape clause — the requirement waives itself. Ask what the writer actually feared (sluggish response), pick the measurable quantity behind the fear, and state when it applies:

After (ubiquitous): The system shall display a response to each operator input within 250 ms of input completion.

Whether 250 ms is the right number is now a conversation the team can have with data — which is the point. A vague requirement can't even be argued with.

Worked example 2: the buried failure case

Before: The system shall maintain communication with the ground station and reconnect as needed.

Two requirements welded together, and the second half (as needed) hides the actual engineering: what does the system do when the link drops? Split them, and give the failure case the if/then structure it deserves:

After (ubiquitous): The system shall maintain a command link with the ground station while in line-of-sight conditions.
After (unwanted behaviour): If the command link is lost for more than 5 seconds, then the system shall initiate the lost-link procedure defined in ICD-042 §3.2.

Notice what the rewrite forced into the open: somebody now has to define the lost-link procedure and own the 5-second threshold. The original sentence let everyone believe that work was already done.

Worked example 3: the hidden state

Before: The pump shall not run dry.

Negative requirements are verification traps — you cannot test all the ways something doesn't happen. Nearly every shall not is a state-driven or unwanted-behaviour requirement wearing a disguise. Find the condition the writer is worried about and state the response:

After (state-driven): While inlet pressure is below 0.2 bar, the controller shall inhibit pump operation.
After (unwanted behaviour): If pump operation is commanded while inlet pressure is below 0.2 bar, then the controller shall reject the command and report fault code P-07.

The habits that make it stick

One shall per sentence. Each requirement gets verified, traced, and negotiated independently; a compound sentence welds three fates together. Name the actor — the controller shall, not the fuel valve shall be closed, because passive voice hides who does the work and the hidden actor is where integration gaps live. Attach units and tolerances to every number. Within 200 ms is testable; quickly is a wish; 200 without a unit is a future argument. Kill escape clauses on sight — as appropriate, where feasible, if possible — each one is a requirement that has pre-authorized its own waiver. If flexibility is genuinely needed, state the actual condition under which the requirement applies; that's what the EARS keywords are for.

None of this requires tooling, but a mechanical first pass catches the defects that slip through tired eyes. Paste your draft statements into the requirements checker — it classifies each one against the EARS patterns and redlines weak verbs, vague terms, escape clauses, missing units, and compound statements before your reviewers do. And once the set is clean, give the statements durable identities with the requirement ID scheme generator.