Conference PaperPDF Available

Easy approach to requirements syntax (EARS)

  • Independent Requirements Specialist


The development of complex systems frequently in-valves extensive work to elicit, document and review stakeholder requirements. Stakeholder requirements are usually written in unconstrained natural language, which is inherently imprecise. During system development, problems in stakeholder requirements inevitably propagate to lower levels. This creates unnecessary volatility and risk, which impact programme schedule and cost. Some experts advocate the use of other notations to in-crease precision and minimise problems such as ambiguity. However, use of non-textual notations requires translation of the source requirements, which can introduce further errors. There is also a training overhead associated with the introduction of new notations. A small set of structural rules was developed to address eight common requirement problems including ambiguity, complexity and vagueness. The ruleset allows all natural language requirements to be expressed in one of five simple templates. The ruleset was applied whilst extracting aero engine control system requirements from an airworthiness regulation document. The results of this case study show qualitative and quantitative improvements compared with a conventional textual requirements specification.
Accepted for RE09, IEEE, August 2009
EARS (Easy Approach to Requirements Syntax)
Alistair Mavin
Philip Wilkinson
Adrian Harwood
Mark Novak
Rolls-Royce PLC
PO Box 31
Derby DE24 8BJ, UK
The development of complex systems frequently in-
volves extensive work to elicit, document and review
stakeholder requirements. Stakeholder requirements are
usually written in unconstrained natural language, which
is inherently imprecise. During system development,
problems in stakeholder requirements inevitably propa-
gate to lower levels. This creates unnecessary volatility
and risk, which impact programme schedule and cost.
Some experts advocate the use of other notations to in-
crease precision and minimise problems such as ambigui-
ty. However, use of non-textual notations requires trans-
lation of the source requirements, which can introduce
further errors. There is also a training overhead associat-
ed with the introduction of new notations. A small set of
structural rules was developed to address eight common
requirement problems including ambiguity, complexity
and vagueness. The ruleset allows all natural language
requirements to be expressed in one of five simple tem-
plates. The ruleset was applied whilst extracting aero
engine control system requirements from an airworthiness
regulation document. The results of this case study show
qualitative and quantitative improvements compared with
a conventional textual requirements specification.
1. Company background
Aircraft engine control systems present a significant
systems engineering challenge: the systems are complex,
safety-critical and developed in ever-compressed time-
scales. To satisfy aircraft manufacturers’ requirements
and maintain market position, control systems must pro-
vide increased functionality and maintain the highest lev-
els of dependability.
Rolls-Royce Control Systems develops Full Authority
Digital Engine Controllers (FADECs) for civil gas turbine
engines. The development and operation of FADECs pre-
sent numerous challenges [1] including: operation in ar-
duous environments, increased system complexity, ever-
greater reliability, improved fault tolerance and the need
to certify against European and US regulations. A typical
modern control system has a dual channel design, con-
tains thousands of components, over 100,000 lines of
code and is developed with up to twenty suppliers.
2. Background to the problem
Stakeholder requirements are often written by individ-
uals who are not experts in requirements definition. Most
commonly, stakeholder requirements are written in un-
structured natural language (NL). The flexibility of NL
makes it an ideal medium for creative expression, such as
drama, poetry and humour. However, unconstrained use
of NL is inherently unsuitable for requirements definition
for a number of reasons. Some of the problems that can
appear in NL requirement documents are:
(a word or phrase has two or more dif-
ferent meanings).
Vagueness (lack of precision, structure and/or de-
Complexity (compound requirements containing
complex sub-clauses and/or several interrelated
Omission (missing requirements, particularly re-
quirements to handle unwanted behaviour).
Duplication (repetition of requirements that are
defining the same need).
Wordiness (use of an unnecessary number of
Inappropriate implementation (statements of how
the system should be built, rather than what it
should do).
Untestability (requirements that cannot be proven
true or false when the system is implemented).
There are other problems that this study does not con-
sider, including conflicting requirements and missing
traceability links. There are two main reasons for their
exclusion: firstly these problems are not unique to NL
requirements documents, and secondly there are no occur-
rences of these problems in the case study.
There are three common forms of ambiguity: lexical, refer-
ential and syntactical [2]. 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.
To overcome problems associated with NL, some ex-
perts advocate the use of other notations for the specifica-
tion of requirements. These include formal notations such
a Z [3] and Petri Nets [4] and graphical notations such as
Unified Modeling Language (UML) [5, 6] and Systems
Modeling Language (SysML) [7]. There are also numer-
ous scenario-based approaches [summarised in 8], tabular
approaches such as Table-Driven Requirements [9] and
ConCERT [10, 11] and pseudocode.
Advocates of some notations claim that they work for
requirements at all system levels, whilst others do not
claim universal applicability. UML and SysML are graph-
ical notations used to describe systems, within which dif-
ferent views can be generated depending on user needs.
Meanwhile, claims have been made for the effective use
of scenarios in many different ways and at different sys-
tem levels [8] though not necessarily within an integrated
However, use of any of these non-textual notations of-
ten requires complex translation of the source require-
ments, which can introduce further errors. Such transla-
tion of requirements can serve to create a “language barri-
er” between developers and stakeholders due to uncon-
scious communication of assumed context. There is also a
training overhead associated with the introduction of
many notations. Requirements authors are unlikely to
seek excessive formality and complex training, and rarely
do they require a software tool to help them write.
There are many hundreds of general books on re-
quirements engineering. There are also numerous exam-
ples of published works specifically about how to write
better requirements. These include two well-known pa-
pers titled “Writing Good Requirements” [12, 13] that
focus on the characteristics of well-formed requirements
and the attributes that should be included. There are also
templates available, such as VOLERE [14] and SL-07
[15]. Despite this large body of published material, there
seems to be little simple, practical advice for the practi-
It was hypothesised that introducing a small set of
simple requirement structures would be an efficient and
practical way to enhance the writing of high-level stake-
holder requirements. Previous work in the area of con-
strained natural language includes Simplified Technical
English [16], Attempto Controlled English (ACE) [17]
and Event-Condition-Action (ECA) [18]. In ECA, the
event specifies the signal that triggers the rule and the
condition is a logical test that (if satisfied) causes the
specified system action.
The work reported here is principally concerned with
requirements syntax. Although measures were taken to
improve the semantics of the requirements, they are not
described in this paper. There is no claim made that this
approach is universally applicable to all levels of system
decomposition. The technique is most suitable to the defi-
nition of high-level stakeholder requirements.
The remainder of this paper is divided into five sec-
tions. Section 3 describes the Case Study. Section 4 de-
fines the Method used and how it was developed. Section
5 summarises the Results. Section 6 is a Discussion of the
findings and section 7 describes Future Work.
3. Case study
Certification Specification for Engines (CS-E) [19] de-
fines what must be achieved in order for an aero engine to
achieve certification. For this study, the section of CS-E
most applicable to engine control systems (CS-E 50) was
analysed. CS-E 50 contains a relatively small number of
requirements, which was a manageable quantity for a case
When analysing the structure and content of CS-E, it is
prudent to consider the history of the document. CS-E has
evolved from incremental updates to its predecessor Joint
Airworthiness Requirements for Engines (JAR-E) [20]
over many years. Repeated updates have resulted in the
addition of statements to form long paragraphs of prose.
Many of these paragraphs contain a rich mixture of both
complex and simple requirements, along with design and
verification statements and supporting information. Most
requirements are explicit, but there are also some implicit
requirements that can be difficult to discover.
Due to the evolutionary nature of the text, care must be
taken when interpreting the intent of statements within
CS-E. Much of the document is written at an abstract lev-
el, relying on lists and explanatory notes to add meaning.
Engineers use the requirements in CS-E during the design
of an engine, but most are unlikely to be trained and expe-
rienced in requirements definition. Engineers are likely to
be most comfortable when presented with a set of unam-
biguous, simple statements in order to validate their own
work. This will reduce the likelihood of lengthy negotia-
tions or expensive alterations later in an engine pro-
gramme. In addition, if requirements are written well,
they can be reused on future programmes, with obvious
cost savings.
4. Method
The process and ruleset used during this investigation
was developed as the work progressed. The participants
started with a set of loose rules derived from their own
experiences in systems, safety and requirements engineer-
ing and built on the concepts of ECA. These included
basic syntactic rules of thumb such as the use of “when”
for event-driven behaviour, “while” for state-driven be-
haviour and “if-then” statements to handle “failures”.
The collaborative nature of the work led to incremental
changes to the ruleset that were tested empirically during
the ongoing study. Additionally, occasional serendipity
helped the evolution of the syntactic rules.
A group of cross-discipline engineers, including the
company’s CS-E certification expert, analysed the source
text of CS-E 50 in two phases. In the first phase, each
clause of the document was broken into its constituent
parts. Some sentences were explicit requirements; others
needed interpretation, but did imply requirements on the
engine control system. Other statements were determined
to be design guidance or were clearly informative text. All
requirements were placed in a spreadsheet to aid manipu-
In the second phase, each requirement was rewritten in
a consistent manner using the syntactic ruleset described
below. Subsequent iterations were necessary as the ruleset
evolved. This led to further rewording of requirements
and to the reclassification of some statements.
4.1 Generic requirements syntax
The generic requirement syntax adopted during this
study is as follows:
<optional preconditions> <optional trigger> the
<system name> shall <system response>
This simple structure forces the requirement author to
separate the conditions in which the requirement can be
invoked (preconditions), the event that initiates the re-
quirement (trigger) and the necessary system behaviour
(system response). Both preconditions and trigger are
optional, depending on the requirement type, as described
later in this section.
The order of the clauses in this syntax is also signifi-
cant, 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
The system is required to achieve the stated sys-
tem response if and only if the preconditions and
trigger are true.
The generic requirement syntax is specialised into five
types of requirement (Ubiquitous, Event-driven, Unwant-
ed behaviours, State-driven and Optional features), which
are described in more detail below.
4.2 Ubiquitous requirements
A ubiquitous requirement has no preconditions or trig-
ger. 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 require-
ment is:
The <system name> shall <system response>
For example: The control system shall prevent engine
overspeed”. This is a system behaviour that must be ac-
tive at all times; hence this is a ubiquitous requirement.
4.3 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 command-
ed by the aircraft, the control system shall switch on con-
tinuous ignition”. This system response is required when
and only when the stated event is detected at the boundary
of the system.
4.4 Unwanted behaviours
Requirements to handle unwanted behaviour
are de-
fined using a syntax derived from event-driven require-
ments. “Unwanted behaviour” is a general term used to
cover all situations that are undesirable. This includes
failures, disturbances, deviations from desired user behav-
iour and any unexpected behaviour of interacting systems.
The authors experiences suggest that unwanted behav-
iour is a major source of omissions in early requirements,
necessitating costly rework. Consequently, these require-
ments were given their own syntax, so that they could be
easily identified throughout the lifecycle.
Requirements for unwanted behaviour are designated
using the keywords If and Then. The general form of a
requirement for unwanted behaviour 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”.
In this example, the unwanted event (computed air speed
fault flag is set) triggers the system response, which al-
lows continued safe operation of the system.
Using the If-Then structure explicitly differentiates the
requirements that handle unwanted behaviour. In such
requirements the system response mitigates the impact of
the unwanted event, or prevents the system from entering
an unwanted state.
The distinction between wanted and unwanted behaviour is
not always clear. For example, due to the safety-critical nature
of aero engine control systems, many subsystems employ multi-
ple redundant components. This allows the system to accommo-
date unwanted events whilst continuing to satisfy operational
requirements. In such cases, the system is behaving “normally”,
but the requirements would be considered as describing “un-
wanted behaviours” using the classification described here.
Hence the distinction between wanted and unwanted behaviour
is a matter of viewpoint, or even a matter of “style”. Another
perspective on the distinction between wanted and unwanted
behaviours is provided by the concept of Misuse Cases [21].
Misuse Cases describe users with hostile intent who are likely to
have wants that are in direct opposition to the wants of other
system stakeholders.
4.5 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 con-
trol system shall maintain engine fuel flow above
XXlbs/sec”. The system response is required at all times
whilst the system is in the defined state.
To make requirements easier to read, the keyword
During can be used instead of While for state-driven re-
quirements. For example: “During thrust reverser door
translation, the control system shall limit thrust to mini-
mum idle”. In this context, the meaning of During is iden-
tical to While, and this alternative keyword is used purely
to aid readability.
4.6 Optional features
An optional feature requirement is applicable only in
systems that include a particular feature. An optional fea-
ture 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”. This functionality only makes
sense (and therefore is only required) for a system that
includes the specified feature.
4.7 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 behaviours.
For instance, the same event may trigger different system
behaviour 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”. The triggering
event (reverse thrust command) triggers the system re-
sponse only when the system is in a particular state (air-
craft on-ground).
The keywords When, While and Where can also be
used within If-Then statements to handle unwanted behav-
iour with more complex conditional clauses. For example
the requirement to handle thrust reverser commands dur-
ing the in-flight state (an unwanted and potentially cata-
strophic event) is handled as follows: “While the aircraft
is in-flight, if reverse thrust is commanded, then the con-
trol system shall inhibit thrust reverser deployment”. In
this situation the trigger (reverse thrust command) is un-
wanted whilst in-flight and the required system response
prevents the system from entering an unwanted state.
Similarly, in the requirement “When selecting idle set-
ting, if aircraft data is unavailable, then the control sys-
tem shall select Approach Idle”, the unwanted behaviour
(aircraft data is unavailable) should result in the stated
system response only when the triggering event (selecting
idle) is satisfied.
4.8 Testing the hypothesis
The hypothesis was tested against a number of criteria,
based on the eight problems associated with NL require-
ments identified in section 2. For each problem, instances
were counted in the both the raw requirements from the
CS-E document and the interpretations. The count for
each set of requirements was compared to assess the ef-
fectiveness of the EARS ruleset.
5. Results
The majority of the requirements could be written in
one of the EARS templates with little difficulty. Those
that could not were either manipulated to fit the ruleset or
the ruleset was evolved to incorporate the additional re-
quirement types.
The Engine Control
System shall not cause
unacceptable thrust or
power oscillations.
When the Engine
Control System
changes operational
mode, the Engine
Control System shall
maintain the engine
within approved op-
erational limits.
If a single Failure
leads to deficient
Data, then the Engine
Control System shall
not cause a Hazardous
Engine Effect.
ed Be-
While in a Full-Up
Configuration, the
Engine Control Sys-
tem shall be Essential-
ly Single Fault Toler-
ant with respect to
LOTC/LOPC event.
Raw extract of CS-E
When over-speed protection
is provided through hydro-
mechanical means, it must be
demonstrated by test or other
acceptable means that the
over-speed function remains
available between inspection
and maintenance periods.
Where over-speed
protection is provided
through hydro-
mechanical means, the
frequency of Engine
Control System in-
spection and mainte-
nance periods shall be
consistent with the
required availability of
the feature.
Table 1. Examples of raw extracts from CS-E with
interpreted control system requirements
Several patterns emerged as the rules were applied to
the raw extracts from CS-E. Common examples of these
patterns were:
Logical restructuring to increase clarity and un-
Reduced wordiness to create simpler statements.
The separation of complex triggers resulting in
two or more atomic requirements.
Reusable statements and reusable formats.
EARS Applied (Scaled) Raw Text (Scaled)
Graph 1. Quantitative results for case study
Consultation with a team of specialists, including Safe-
ty Engineers and Airworthiness Engineers, uncovered the
contextual intent of CS-E, allowing an accurate set of
requirements to be defined. Table 1 shows some examples
of raw extracts from CS-E and the resulting interpreta-
tions. As part of the interpretation process, it was occa-
sionally necessary to examine associated advisory materi-
al [22]. This material contains information, verification
and design statements in addition to requirements.
Following translation of the requirements, the raw re-
quirements and interpretations were compared against the
criteria described in section 2. Graph 1 shows the differ-
ences for the eight criteria on a log scale
. Overall, the
interpretations scored significantly better than the raw
requirements. Against five of the criteria, the interpreta-
tions contain none of the problems present in the raw re-
quirements. For the other three criteria ambiguity,
vagueness and wordiness a substantial reduction in
problems was observed. The number of requirements and
the average words per requirement for the raw require-
ments and the interpretations is shown in Table 2. The
total number of requirements has increased, while the
average number of words per requirements has reduced.
Raw extract
No. individual requirements
Av. words per requirement
Table 2. Word count of raw requirement extracts and
6. Discussion
The results show that the modified notation has a
number of advantages over the use of unconstrained NL.
All of the text from the regulation, once formatted as re-
quirements, was successfully translated into one of the
EARS templates. Where problems of translation were
initially experienced, these were addressed by further evo-
lutionary development of the ruleset.
The review against the criteria of section 2 demon-
strated a significant reduction in all eight problem types.
For the case study, the notation appears to have eliminat-
ed the problems of complexity, omission, duplication,
implementation and untestability. However, the claim that
omissions have been eliminated needs to be treated with
caution. Whilst the trial may have effectively identified
some unwanted behaviour, there is no evidence that other
missing requirements have been captured.
The problems of ambiguity, vagueness and wordiness
were reduced, but not eliminated. The remaining prob-
lems are thought to be due to:
Lexical ambiguity, where a precondition was un-
derstood by inference, but not explicitly recorded.
The data contained a combination of large and small data
values. It was therefore necessary to scale the numbers using a
log function (on values greater than 1) for clarity on the chart.
General vagueness, which is an innate feature of
high-level requirements and difficult to remove
until accompanying design decisions are made.
Wordiness occurred where a particularly long re-
quirement, containing numerous conditional
clauses, employed clumsy word constructions.
The increase in the number of requirements was ex-
pected. This was because some clauses of CS-E contain
numerous compound requirements, which were separated
out during the interpretation process. A reduction in the
average word-count of the interpretations was also antici-
pated, and is mainly due to reduced complexity, duplica-
tion and wordiness.
Although the results of this case study are very posi-
tive, a number of limitations could have influenced the
outcomes of the study:
The sample size was small, consisting of only 36
original requirements.
The study was restricted to high-level safety-
related requirements. It is possible that other types
of high-level requirements and lower-level re-
quirements may exist that cannot be adequately
represented in the notation.
Although efforts were made to reduce subjective
influences, the classification of vagueness is inevi-
tably a matter of personal opinion and therefore
open to inconsistency.
Despite these limitations, the study seems to provide
ample evidence to support the hypothesis: that a small set
of simple requirement structures would be an efficient and
practical way to enhance the writing of high-level stake-
holder requirements.
7. Future work
The authors intend to continue with their assessment
of the remainder of CS-E. This would involve the transla-
tion of all requirements pertaining to the engine control
system. Further studies are also planned to assess the no-
tation against an entire suite of high-level engine control
system requirements and lower-level elements of the con-
trol system design. It is hoped that these studies will es-
tablish the effectiveness of the notation by addressing the
limitations identified in section 6.
As stated in section 2, a number of known require-
ments problems were consciously excluded from this
study. One of the reasons for this was that the document
used in the case study did not include such problems.
However, it is expected that use of the EARS templates
will address at least some of these issues when applied to
other stakeholder requirement documents. For example,
applying the syntactic rules will clarify the precise pre-
conditions and triggers, which should highlight conflict-
ing requirements. The intention is to apply the EARS sys-
tem to a wider range of system documents which contain
such problems.
Further thought is necessary to investigate how the If
and When preconditions can be applied to unwanted
states. Although the case study identified no such scenari-
os, unwanted states may require an additional template to
define how the system should behave while in an unwant-
ed state.
1. Holt J.E., “The Challenges of Civil Aircraft Engine Control Sys-
tem Development at Rolls-Royce”, Proceedings of IEEE United
Kingdom Automatic Control Council (UKACC) International Con-
trol Conference, Glasgow, August, 2006.
2. Warburton, N., “Thinking from A to Z”, 2
edition, Routledge,
3. Woodcock, J. and Davies, J., “Using Z-Specification, Refinement
and Proof”, Prentice Hall, 1996.
4. Peterson, J. “Petri Nets”, ACM Computing Surveys 9 (1977), 223-
5. Object Management Group, UML Resource Page,
6. Holt, J., “UML for Systems Engineering: Watching The Wheels”
edition), IEE, 2004.
7. Object Management Group, Official OMG SysML Site,
8. Alexander, I.F. & Maiden, N.A.M. (eds), “Scenarios, Stories, Use
Cases: Through the Systems Development Life-Cycle” Wiley,
9. Alexander, I.F. & Beus-Dukic, L., “Discovering Requirements”,
John Wiley, 2009.
10. Vickers, A., Tongue, P.J. and Smith, J.E., “Complexity and its
Management in Requirements Engineering”, INCOSE UK Annual
Symposium Getting to Grips with Complexity, Coventry, UK,
11. Vickers, A., Smith, J.E., Tongue, P.J. and Lam, W., “The Con-
CERT Approach to Requirements Specification (version 2.0)”,
YUTC/TR/96/01, University of York, November 1996 (enquiries
about this report should be addressed to: High-Integrity Systems
Engineering Research Group, Department Computer Science, Uni-
versity of York, Heslington, YORK, YO10 5DD, UK).
12. Hooks, I., “Writing Good Requirements”, Proceedings of Third
International Symposium of INCOSE Volume 2, INCOSE, 1993.
13. Wiegers, K., Writing Good Requirements”, Software Develop-
ment Magazine, May 1999.
14. “VOLERE Requirements Specification Template”, Atlantic Sys-
tems Guild,
15. Lauesen, S., Guide to Requirements SL-07. Template with Exam-
ples”, Lauesen Publishing, 2007.
16. “ASD Simplified Technical English: Specification ASD-STE100.
International specification for the preparation of maintenance doc-
umentation in a controlled language”, Simplified Technical Eng-
lish Maintenance Group (STEMG), 2005.
17. Fuchs, N. E., Kaljurand, K. and Schneider, G., "Attempto Con-
trolled English Meets the Challenges of Knowledge Representa-
tion, Reasoning, Interoperability and User Interfaces", FLAIRS,
18. Dittrich, K. R., Gatziu, S. and Geppert, A., “The Active Database
Management System Manifesto: A Rulebase of ADBMS Fea-
tures.”, Lecture Notes in Computer Science 985, Springer, 1995,
pages 3-20.
19. “Certification Specification for Engines” (CS-E) Amendment 1,
18-20, European Aviation Safety Agency (EASA), 10
20. “Joint Airworthiness Requirements for Engines” (JAR-E), JAA,
21. Sindre, G. and Opdahl, A., “Capturing Security Requirements
through Misuse Cases”, TOOLS 37 (2000), pp. 120-131.
22. AMC20 Effective 26/12/2007”, European Aviation Safety Agen-
cy (EASA),
... So far, we have seen the combination of ontology and boilerplates for the specification of requirements. Regarding the creation or the use of boilerplates, the variants of Hull (Pasquariello et al., (2022); Daramola et al., (2011);Daramola, O., Sindre, G., & Moser, T. (2012)), EARS (Mavin et al. 2009;Arora et al. 2015) and Rupp and Pohl (Arora et al. 2015) boilerplates have been mainly used by the literature. We also notice in the above works (where there is a combination of boilerplate and ontology) that the completion of the attributes of boilerplate is done via an ontology. ...
... We were inspired by the most popular boilerplates-templates such as the ones of Pohl and Rupp (2011), EARS (Mavin et al. 2009) and Hull et al., (2010). The common ground in the aforementioned boilerplates is the following syntax: subject-verb-object. ...
... That is why the introduction of entities, i.e. the completion of the attributes of boilerplates, was limited and is done according to those entities that are semantically related to the appropriate verbs (object properties). Some pre-existing boilerplates, such as EARS (Mavin et al. 2009) or Pohl and Rupp (Pohl and Rupp 2011), may match the syntax or semantics of the ATM requirements. Of course, in cases where the pre-existing boilerplates do not match the requirements, they must be adapted in order to capture complex relationships between entities that are important to formulate independent of the ATM domain. ...
Full-text available
The most popular technique for specification requirements is natural language. The disadvantage of natural language is ambiguity. Boilerplates are syntactic patterns which limit the ambiguity problem associated with using natural language to specify system/software requirements. Also, using boilerplates is considered a useful tool for inexperienced engineers to define requirements. Using linguistic boilerplates, constrains the natural language syntactically. Furthermore, a domain-specific ontology is used to constrain requirements semantically, as well. In requirements specification, using ontologies helps to restrict the vocabulary to entities, properties, and property relationships which are semantically related. The above results in avoiding or making fewer mistakes. This work makes use of the combination of boilerplate and ontology. Usually, the attributes of boilerplates are completed with the help of the ontology. The contribution of this paper is that the whole boilerplates is stored in the ontology and attributes and fixed elements are part of the ontology. This combination helps to correct semantically and syntactically requirement construction. This paper proposes a tool based on a domain-specific ontology and a set of predefined generic linguistic boilerplates for requirements engineering. We create a domain-specific ontology and a minimal set of boilerplates for an ATM (Automated Teller Machine). We carried out an experiment in order to obtain evidence for the effectiveness and efficiency of our method. The experiment took the form of a case study for the ATM domain and our proposed method was evaluated by users. The contribution and novelty of our methodology is that we created a tool for defining requirements that integrates boilerplate templates and an ontology. We exploit the boilerplate language syntax, mapping them to Resource Description Framework triples which have also a linguistic nature.
... The first step to increase the formalism of requirements is to structure the statements' sentences into predefined patterns. EARS (Easy Approach to Requirement Syntax), in constraining the way requirements are written using some simple patterns (Mavin et al., 2009), is one example. ...
Full-text available
Systems engineering activities in the concept and development phases have evolved continuously for decades. The deployment of digital thread, digital engineering, MBSE approaches, and modeling and simulation techniques have driven part of this evolution. Despite this trend, requirements are still largely textual and expressed in natural language, and requirements engineering activities are still often document‐based. However, model‐based requirements‐engineering approaches have emerged in recent years and have demonstrated significant benefits, including improved requirements quality, less ambiguity, and early and efficient verification and validation. The goal of this paper is to present the current outcomes and perspectives of setting up an Integrated Digital Requirements Engineering approach as developed within our company. This approach seeks to optimize usability and maximize benefits to support end‐to‐end V&V activities while fully integrating into MBSE workflows.
Developing critical components, such as mission controllers or embedded systems, is a challenging task. Reactive synthesis is a technique to automatically produce correct controllers. Given a high-level specification written in LTL, reactive synthesis consists of computing a system that satisfies the specification as long as the environment respects the assumptions. Unfortunately, LTL synthesis suffers from high computational complexity which precludes its use for many large cases. A promising approach to improve synthesis scalability consists of decomposing a safety specification into a smaller specifications, that can be processed independently and composed into a solution for the original specification. Previous decomposition methods focus on identifying independent parts of the specification whose systems are combined via simultaneous execution. In this work, we propose a novel decomposition algorithm based on modes, which consists on decomposing a complex safety specification into smaller problems whose solution is then composed sequentially (instead of simultaneously). The input to our algorithm is the original specification and the description of the modes. We show how to generate sub-specifications automatically and we prove that if all sub-problems are realizable then the full specification is realizable. Moreover, we show how to construct a system for the original specification from sub-systems for the decomposed specifications. We finally illustrate the feasibility of our approach with multiple cases studies using off-the-self synthesis tools to process the obtained sub-problems.
Full-text available
In the field of Requirements Engineering, natural language is the most widely used form of documenting systems requirements, mainly for its expressiveness power, freedom of words, and easiness of use. On the other hand, written requirements are frequently ambiguous, incomplete, and incorrect, among other defects, impacting into the system lifecycle. To mitigate this issue, researchers have, since 1998, developed dozens of sets of boilerplates, aiding to guide natural language requirements composition. In this integrative literature review, authors searched for these sets in traditional academic databases, grey literature, and professional media, leading to a list of 54 relevant documents. Analysis of these primary works revealed that, even when boilerplate creators wish their artifacts to be used on all kinds of systems, they are generally cataloged under the Computer Science umbrella. It turned out to be evident that ambiguity is the main issue of quality of requirements addressed by boilerplates, followed by completeness and consistency. Authors mapped the requirements boilerplates definition modes, concluding that plain sentences are the foremost choice to describe these creations. It is claimed that systematization on the construction and evaluation of requirements boilerplates is still a problem to render these activities repeatable and reproducible, as the largest part of documents does not report it. Finally, the reported evaluation methods were hierarchically clustered, leading to three typical approaches for this activity.
Full-text available
This booklet contains a software requirements specification for a complex system - and a guide to why it is written in this way. The specification itself can be used as inspiration and template for other systems. Until now it has been used successfully in 100+ projects ranging from public acquisitions to product development and agile in-house projects.
Full-text available
Use cases have become popular for eliciting, communicating and documenting requirements. They support functional requirements well, but provide less support for working with extra-functional requirements, such as security requirements. With the advent of e -and m -commerce applications, such requirements are growing in importance. This paper discusses a conceptual extension of use cases, namely 'misuse cases', describing actions that should not be possible in a system. In particular, we discuss templates for their textual description.
Conference Paper
Full-text available
We present Attempto Controlled English — a user- friendly first-order logic language with a rich English syntax — and its associated tools, and demonstrate how they meet the challenges of knowledge representation, reasoning, interoperability and user interfaces created by large software projects like the semantic web.
The primary reason that people write poor requirements is that they have had no training or experience in writing good requirements. This paper will address what makes a good requirement. It will cover some of the most common problems that are encountered in writing requirements and then describe how to avoid them. It also includes examples of problem requirements and how to correct them.
Conference Paper
Active database systems have been a hot research topic for quite some years now. However, while "active functionality" has been claimed for many systems, and notions such as "active objects" or "events" are used in many research areas (even be- yond database technology), it is not yet clear which functionality a database manage- ment system must support in order to be legitimately considered as an active system. In this paper, we attempt to clarify the notion of "active database management system" as well as the functionality it has to support. We thereby distinguish mandatory features that are needed to qualify as an active database system, and desired features which are nice to have. Finally, we perform a classification of applications of active database sys- tems and identify the requirements for an active database management system in order to be applicable in these application areas.
The basic concepts and uses of Petri nets are surveyed. The structure of Petri nets, their markings and execution, several examples of Petri net models of computer hardware and software, and research into the analysis of Petri nets are presented, as are the use of the reachability tree and the decidability and complexity of some Petri net problems. Petri net languages, models of computation related to Petri nets, and some extensions and subclasses of the Petri net model are also briefly discussed.