Easy Approach to Requirements Syntax

The Easy Approach to Requirements Syntax (EARS) is a structured method for writing natural language requirements using a small set of keywords and sentence patterns. Developed by Alistair Mavin and colleagues at Rolls-Royce plc while analysing airworthiness regulations for a jet engine control system, EARS was first published at the IEEE International Requirements Engineering Conference (RE'09) in 2009.^[1] EARS gently constrains free-form natural language by imposing a consistent clause order and a limited vocabulary of structural keywords, reducing or eliminating common problems such as ambiguity, vagueness and incompleteness.^[2]

EARS has been adopted by organisations including Airbus, Bosch, Dyson, Honeywell, Intel, NASA, Rolls-Royce and Siemens, and is taught at universities in China, France, Germany, Sweden, the United Kingdom and the United States.^[2] Since 2025, EARS notation has been integrated into AI-assisted spec-driven development tooling, most notably Amazon's Kiro IDE.^[3]

System requirements are usually written in unconstrained natural language, which is inherently imprecise. Requirements authors are often domain experts rather than trained requirements engineers, and poorly expressed requirements propagate errors to downstream design, implementation and testing phases, increasing cost and schedule risk. While formal specification languages can increase precision, they impose a significant training overhead and require translation of source requirements, which can itself introduce errors.^[4]

EARS was designed to occupy a middle ground: it retains natural language so that all stakeholders can read and review requirements without specialist training, while imposing enough syntactic structure to eliminate the most common defects. The approach arose during Mavin's analysis of the airworthiness regulations contained in the certification basis for a Rolls-Royce aero engine control system, where he observed that well-written requirements all followed a similar underlying structure.^[1]

The general structure of an EARS requirement is:

WHILE <optional precondition(s)>, WHEN <optional trigger>, the <system name> SHALL <system response>

The EARS ruleset states that a requirement must have:^[2]

• Zero or many preconditions
• Zero or one trigger
• Exactly one system name
• One or many system responses

The clauses always appear in the same temporal order, and a small number of keywords denote the different clause types. This produces requirements that fall into one of five basic patterns, plus combinations thereof.

Ubiquitous requirements are always active. They have no EARS keyword because there is no triggering condition.

THE <system name> SHALL <system response>

Example: "The mobile phone SHALL have a mass of less than 150 grams."

Event-driven requirements specify how a system must respond when a triggering event occurs. They are denoted by the keyword WHEN.

WHEN <trigger>, the <system name> SHALL <system response>

Example: "WHEN 'mute' is selected, THE laptop SHALL suppress all audio output."

State-driven requirements are active as long as a specified state remains true. They are denoted by the keyword WHILE.

WHILE <precondition(s)>, the <system name> SHALL <system response>

Example: "WHILE there is no card in the ATM, THE ATM SHALL display 'insert card to begin'."

Optional feature requirements apply only in products or system variants that include a specified feature. They are denoted by the keyword WHERE.

WHERE <feature is included>, the <system name> SHALL <system response>

Example: "WHERE the car has a sunroof, THE car SHALL have a sunroof control panel on the driver door."

Unwanted behaviour requirements specify the required system response to undesired situations such as faults, failures or errors. They are denoted by the keywords IF and THEN.

IF <trigger>, THEN the <system name> SHALL <system response>

Example: "IF an invalid credit card number is entered, THEN the website SHALL display 'please re-enter credit card details'."

The simple building blocks above can be combined to specify richer system behaviour. Complex requirements use more than one EARS keyword:^[2]

WHILE <precondition(s)>, WHEN <trigger>, the <system name> SHALL <system response>

Example: "WHILE the aircraft is on ground, WHEN reverse thrust is commanded, the engine control system SHALL enable reverse thrust."

EARS provides several documented advantages over unconstrained natural language requirements:^[1][4]

• Reduced ambiguity – The fixed clause order and keyword vocabulary force authors to make triggering conditions, preconditions and expected responses explicit.
• Low adoption barrier – The keywords closely match everyday English usage, so there is minimal training overhead and no need for specialised tooling.
• Language accessibility – EARS is particularly effective for authors who write requirements in English but whose first language is not English.
• Improved testability – The structured separation of conditions and responses makes it straightforward to derive test cases.
• Compatibility with existing tools – Requirements can be written in any text editor, word processor or requirements management tool.

EARS is not suited to every requirement type. Requirements with more than three preconditions can produce unwieldy single sentences, and some requirements are better expressed as mathematical formulae, decision tables, or state-transition diagrams.^[5] The notation is also less appropriate for non-functional requirements that cannot be captured as conditional behaviour (e.g., architectural constraints).

Spec-driven development (SDD) is a software methodology in which a formal or semi-formal specification—rather than ad-hoc prompts or informal descriptions—drives code generation, testing and documentation. In SDD workflows, requirements are first captured in a structured format, then used to produce a technical design, and finally broken down into implementation tasks. EARS notation has emerged as a favoured syntax for the requirements phase of SDD because its constrained natural language can be parsed by both humans and large language models (LLMs), bridging the gap between product intent and machine-readable specifications.^[9]

Kiro, an agentic AI integrated development environment announced by Amazon in 2025 and built on Code OSS, has adopted EARS as its native requirements notation.^[3] Kiro's spec-driven workflow operates in three phases:

1. Requirements (requirements.md): The developer enters a natural language prompt (e.g., "Add a review system for products"). Kiro expands this into user stories, each with acceptance criteria written in EARS notation. The structured format explicitly captures preconditions, triggers and expected system responses, covering edge cases that developers would otherwise discover during implementation.^[10]
2. Design (design.md): Based on the EARS requirements and the existing codebase, Kiro generates a technical design document including architecture, sequence diagrams, and technology stack decisions.
3. Tasks (tasks.md): The design is decomposed into discrete, sequenced implementation tasks with dependency tracking.

Because each acceptance criterion follows the EARS pattern WHEN <condition/event> THE SYSTEM SHALL <expected behaviour>, the requirements are directly testable and provide unambiguous success criteria for each generated task. Developers can also manually author requirements in EARS format and use Kiro's "Refine" function to validate or restructure them.^[11]

The integration of EARS into Kiro reflects a broader trend in which structured requirements templates are used to improve the predictability and quality of LLM-generated code. Compared to free-form prompts (sometimes called "vibe coding"), EARS-formatted specifications reduce the ambiguity that causes AI agents to make undesirable assumptions.^[9] Community projects have extended the approach to other AI coding assistants through plugins and Model Context Protocol (MCP) servers that expose EARS-based spec-driven workflows.^[12]

EARS and user stories are frequently used together in practice: user stories capture high-level stakeholder needs, while EARS is used to specify detailed acceptance criteria within each story—an approach formalised by Kiro's spec-driven workflow.^[10]

• Requirements engineering
• Spec-driven development
• Controlled natural language
• Requirements analysis
• Behavior-driven development
• Systems engineering
• Vibe coding

• EARS – Official page by Alistair Mavin
• EARS original paper on IEEE Xplore
• Kiro documentation – Specs concepts
• QRA – The Easy Approach to Requirements Syntax: The Definitive Guide
• Jama Software – Adopting EARS Notation for Requirements Engineering