Difference between revisions of "EARS Requirement Capture"
| Line 32: | Line 32: | ||
'''Option''' | '''Option''' | ||
| − | An option requirement | + | An option requirement |
| − | * a system response is needed only in applications that include a particular feature | + | * 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 used as a simple way to handle product or system variation, and |
* is denoted by the keyword "where". | * is denoted by the keyword "where". | ||
| Line 42: | Line 42: | ||
An unwanted behaviour requirement is | An unwanted behaviour requirement is | ||
| − | * the required system response to unwanted events (such as failures, disturbances | + | * 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 | + | * a variation of the event-driven requirement and |
* denoted by the keywords “if” and “then.” | * denoted by the keywords “if” and “then.” | ||
| − | For example | + | For example: ''"If the engine fails to start during a third ground start attempt, then the Engine Control System shall terminate the autostart sequence".'' |
Latest revision as of 09:35, 13 August 2012
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".
