Difference between revisions of "EARS Requirement Capture"
From EUDP
(Initial edit) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
The '''E'''asy to '''A'''pproach '''R'''equirements '''S'''yntax - EARS is a way to capture and classify requirements suggested by Alistair Marvin in the [http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6155138&contentType=Journals+%26+Magazines&refinements%3D4291944246%26ranges%3D2012_2012_p_Publication_Year%26queryText%3DEARS IEEE Software] magazine. | The '''E'''asy to '''A'''pproach '''R'''equirements '''S'''yntax - EARS is a way to capture and classify requirements suggested by Alistair Marvin in the [http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6155138&contentType=Journals+%26+Magazines&refinements%3D4291944246%26ranges%3D2012_2012_p_Publication_Year%26queryText%3DEARS IEEE Software] magazine. | ||
| − | EARS is based on usage of the English language and | + | EARS is based on the usage of the English language and five templates. |
'''Ubiquitous''' | '''Ubiquitous''' | ||
| Line 7: | Line 7: | ||
A ubiquitous requirement is | A ubiquitous requirement is | ||
* something that the system must always do, | * something that the system must always do, | ||
| − | * unconditional | + | * unconditional and |
* continuously active. | * continuously active. | ||
| − | For example | + | For example: ''"The Engine Control System software shall comply with DO-178B".'' |
'''Event-driven''' | '''Event-driven''' | ||
| Line 17: | Line 17: | ||
* the system response is initiated by a triggering event detected at the system boundary, | * 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 trigger must be something that the system itself can detect, and | ||
| − | * the requirement is denoted by the keyword | + | * the requirement is denoted by the keyword "when". |
| − | For example | + | For example: ''"When commanded by the aircraft, the Engine Control System shall dry crank the engine".'' |
'''State-driven''' | '''State-driven''' | ||
| Line 26: | Line 26: | ||
* active while a particular state or states remain true, | * active while a particular state or states remain true, | ||
* continuous as long as the state holds, and | * continuous as long as the state holds, and | ||
| − | * denoted by the keyword | + | * denoted by the keyword "while". |
| − | For example '' | + | 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''' | '''Option''' | ||
| − | An option requirement applies when a system response is needed only in applications that include a particular feature, | + | 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 used as a simple way to handle product or system variation, and | ||
| − | * is denoted by the keyword | + | * is denoted by the keyword "where". |
| − | For example | + | For example: ''"Where electronic components are used in the Engine Control System, they shall comply with DO-254".'' |
'''Unwanted Behaviour''' | '''Unwanted Behaviour''' | ||
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".
