TECHNICAL NOTES · REQUIREMENTS
Writing verifiable requirements with EARS
A requirement that cannot be verified cannot be closed. Most untestable requirements fail for the same few reasons — a missing trigger, a vague adjective, two requirements in one sentence — and a small set of sentence patterns prevents nearly all of them.
The EARS patterns
EARS — the Easy Approach to Requirements Syntax, developed at Rolls-Royce and published by Alistair Mavin and colleagues in 2009 — constrains natural-language requirements to a few templates. Each template forces you to state the condition under which the requirement applies.
| PATTERN | TEMPLATE |
|---|---|
| Ubiquitous | The <system> shall <response>. |
| Event-driven | When <trigger>, the <system> shall <response>. |
| State-driven | While <state>, the <system> shall <response>. |
| Unwanted behaviour | If <condition>, then the <system> shall <response>. |
| Optional feature | Where <feature is included>, the <system> shall <response>. |
Patterns combine — "While in flight, when the gear lever is selected up, the …" — but if a sentence needs more than one trigger and one state, it usually wants splitting.
The verification-method test
Before accepting a requirement, name how it will be verified: test, analysis, inspection or demonstration, and what pass looks like. If you can't write the pass criterion, the requirement isn't finished. This single question catches most of the problems below.
Words that make a requirement untestable
- Vague qualities — quickly, adequate, sufficient, user-friendly, robust, minimise, maximise. Replace with a number and a unit.
- Open lists — etc., including but not limited to, and so on. A verifier can't test an open set.
- Hidden alternatives — and/or, as appropriate, if possible. Each hides a decision that belongs in the requirement.
- Two requirements in one — a sentence with two "shall"s, or one "shall" and an "and" joining two responses, can only be partly passed. Split it.
Before and after
Before: "The landing gear shall retract quickly and reliably after take-off."
It has no trigger, "quickly" and "reliably" have no pass criteria, and it bundles a performance requirement with a reliability one. Rewritten with EARS (the values are illustrative; yours come from the aircraft-level requirements and the safety assessment):
Event-driven: When the gear lever is selected UP and weight-on-wheels indicates airborne, the landing gear system shall retract all gear to the up-and-locked position within 10 s.
Unwanted behaviour: If any gear is not up-and-locked within 15 s of an UP selection, then the landing gear system shall annunciate a gear-disagree caution to the flight crew.
Each now has one trigger, one response, a measurable criterion and an obvious verification method — test on a rig, then in flight test. "Reliably" becomes its own requirement, verified by analysis against the failure rates the safety assessment allocates.
Trace in both directions
A requirement is only useful in context: traced up to the parent it satisfies and down to the design, code and tests that implement and verify it. Gaps show up in both directions — a parent with no children is unimplemented; a test or a function with no parent is unintended functionality. TELOS drafts requirements in these patterns, flags the words above, converts each requirement into test cases and keeps the trace, citing live eCFR and NASA sources where a regulation drives the requirement.
Related notes
- Requirements traceability that survives a certification audit
- AI-generated flight code under DO-178C
- How to check an AI's engineering calculation
- EASA's AI concept paper Issue 03: what it means for LLMs in aerospace
Published · 17 August 2026 · All technical notes