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 usage of the English language and on 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.”
