Easy Approach to

Requirements Syntax
(EARS)
By: Shavez Qureshi
 Introduction
• The development of complex systems frequently involves extensive
work to elicit, document and review stakeholder requirements.
• During system development, problems in stakeholder requirements
inevitably propagate to lower levels.
• Case Study of Aircraft Engine Control System is presented.
• Aircraft engine control systems present a significant systems
engineering challenge: the systems are complex, safety-critical and
developed in ever-compressed timescales.
 Problems in Natural Language Documents
Some of the problems that can appear in NL requirement documents are:
1. Ambiguity (a word or phrase has two or more different meanings).
2. Vagueness (lack of precision, structure and/or detail).
3. Complexity (compound requirements containing complex sub-clauses and/or several
interrelated statements).
4. Omission (missing requirements, particularly requirements to handle unwanted behaviour).
5. Duplication (repetition of requirements that are defining the same need).
6. Wordiness (use of an unnecessary number of words).
7. Inappropriate implementation (statements of how the system should be built, rather than
what it should do).
8. Untestability (requirements that cannot be proven true or false when the system is
implemented).
 Ambiguity
There are three common forms of ambiguity: lexical, referential and
syntactical.
• Lexical ambiguity occurs where a word or phrase, which has two or
more meanings, is used in a manner that permits a sentence or
phrase to be interpreted in more than one way.
• Referential ambiguity occurs when a word or phrase is used that can
be referring to two or more things.
• Syntactical ambiguity arises when the order of words allows two or
more interpretations.
 Generic Requirements Syntax
• The generic requirement syntax adopted during this study is as follows:
<optional preconditions> <optional trigger> the <system name> shall <system
response>
• The order of the clauses in this syntax is also significant, since it follows temporal
logic:
Any preconditions must be satisfied otherwise the requirement cannot ever be
activated.
The trigger must be true for the requirement to be “fired”, but only if the
preconditions were already satisfied.
The system is required to achieve the stated system response if and only if the
preconditions and trigger are true.
 Generic Requirements Syntax
The generic requirement syntax is specialized into five types of
requirements:
• Ubiquitous
• Event-driven
• Unwanted behaviors
• State-driven
• Optional features
 Ubiquitous Requirement
• A ubiquitous requirement has no preconditions or trigger.
• It is not invoked by an event detected at the system boundary or in
response to a defined system state, but is always active. The general
form of a ubiquitous requirement is:
The <system name> shall <system response>
• For example: “The control system shall prevent engine over speed”.
• This is a system behavior that must be active at all times; hence this is
a ubiquitous requirement.
 Event-driven requirements
• An event-driven requirement is initiated only when a triggering event
is detected at the system boundary.
• The keyword When is used for event-driven requirements.
• The general form of an event-driven requirement is:
WHEN <optional preconditions> <trigger> the <system name> shall
<system response>
• For example: “When continuous ignition is commanded by the
aircraft, the control system shall switch on continuous ignition”.
 Unwanted behaviors
• Requirements to handle unwanted behavior are defined using a syntax
derived from event-driven requirements.
• “Unwanted behavior” is a general term used to cover all situations that are
undesirable.
• This includes failures, disturbances, deviations from desired user behavior
and any unexpected behavior of interacting systems.
• Requirements for unwanted behavior are designated using the keywords If
and Then.
• The general form of a requirement for unwanted behavior is:
IF <optional preconditions> <trigger>, THEN the <system name> shall
<system response>
• For example “If the computed airspeed fault flag is set, then the control
system shall use modelled airspeed”.
 State-driven requirements
• A state-driven requirement is active while the system is in a defined
state.
• The keyword While is used to denote state-driven requirements.
• The general form of a state driven requirement is:
WHILE <in a specific state> the <system name> shall <system
response>
• For example: “While the aircraft is in-flight, the control system shall
maintain engine fuel flow above XXlbs/sec”.
 Optional features

• An optional feature requirement is applicable only in systems that

include a particular feature.
• An optional feature requirement is designated with the keyword
Where.
• The general form of an optional feature requirement is:
WHERE <feature is included> the <system name> shall <system
response>
• For example, “Where the control system includes an overspeed
protection function, the control system shall test the availability of the
overspeed protection function prior to aircraft dispatch”.
 Complex requirement syntax
• For requirements with complex conditional clauses, combinations of
the keywords When, While and Where may be required.
• The keywords can be built into more complex expressions to specify
richer system behaviors.
• For instance, the same event may trigger different system behavior
depending on the state of the system when the event is detected.
• For example: “While the aircraft is on-ground, when reverse thrust is
commanded, the control system shall enable deployment of the thrust
reverser”.