EARS Requirement Capture
The Easy to Approach Requirements Syntax - EARS is a way to capture and classify requirements suggested by Alistair Marvin in the IEEE Software magazine.
EARS is based on the usage of the English language and five templates.
Ubiquitous
A ubiquitous requirement is
- something that the system must always do,
- unconditional and
- continuously active.
For example: "The Engine Control System software shall comply with DO-178B".
Event-driven
An event-driven requirement applies when
- the system response is initiated by a triggering event detected at the system boundary,
- the trigger must be something that the system itself can detect, and
- the requirement is denoted by the keyword "when".
For example: "When commanded by the aircraft, the Engine Control System shall dry crank the engine".
State-driven
A state-driven requirement is
- active while a particular state or states remain true,
- continuous as long as the state holds, and
- denoted by the keyword "while".
For example: "While the aircraft is in flight and the engine is running, the Engine Control System shall maintain engine fuel flow above x lbs./sec.".
Option
An option requirement
- applies when a system response is needed only in applications that include a particular feature,
- is used as a simple way to handle product or system variation, and
- is denoted by the keyword "where".
For example: "Where electronic components are used in the Engine Control System, they shall comply with DO-254".
Unwanted Behaviour
An unwanted behaviour requirement is
- the required system response to unwanted events (such as failures, disturbances and any unexpected behaviour of interacting systems or users),
- a variation of the event-driven requirement and
- denoted by the keywords “if” and “then.”
For example: "If the engine fails to start during a third ground start attempt, then the Engine Control System shall terminate the autostart sequence".
