=Paper=
{{Paper
|id=Vol-2308/aviose2019paper03
|storemode=property
|title=Towards Computer-Aided Software Requirements Process
|pdfUrl=https://ceur-ws.org/Vol-2308/aviose2019paper03.pdf
|volume=Vol-2308
|authors=Marina Reich,Tatiana Chuprina,Vivek Nigam
|dblpUrl=https://dblp.org/rec/conf/se/ReichCN19
}}
==Towards Computer-Aided Software Requirements Process==
https://ceur-ws.org/Vol-2308/aviose2019paper03.pdf
Towards Computer-Aided
Software Requirements Process
Marina Reich Tatiana Chuprina Vivek Nigam
Technische Universität Chemnitz fortiss GmbH fortiss GmbH
Airbus Defence and Space GmbH München, Germany München, Germany
Manching, Germany chuprina@fortiss.org nigam@fortiss.org
marina.reich@airbus.com
Abstract—It is a consensus that projects that start from good This guidance presents the activities to be performed during
requirements have greater chances of success. Clearly specified SRP with which the objectives shall be fulfilled. Today, the
requirements lead to better feature development, validation and activities for SRP are not broken down into precise tasks
verification. Unfortunately, many avionics product defects can
be traced back to flaws in the Software Requirement Process for job roles (SRE, SRR) in the industrial context. Also, the
(SRP), such as errors in requirements and in the communication activities are not interlinked precisely with the objectives and
between requirement engineers (SRE) and reviewers (SRR). This the quality of requirements.
short-paper reports on our first steps towards a Computer- Unfortunately, as described above, requirements many times
Aided SRP (CSRP). CSRP relies on three key ideas, leading do not meet the demanded quality. We believe that there are
to better quality requirements: Domain Specific Requirements
(DSRs), Automated Requirement Quality Checks, and Structured many reasons for this among which are the following:
Feedback. We illustrate CSRP with a use case on the development • Tight development deadlines leading to sloppy RE;
of requirements for a software in an embedded avionics system. • Requirements are normally written in natural language.
Although the language used satisfies some criteria, such
I. Introduction
as avoiding the use of words, like “should”, the nature of
The avionics industry is making efforts to meet the in- natural language leads many times to ambiguities and to
creasing needs of handling requirements for complex avionics requirements with missing information;
software [1]. It has been long known that many system and • Reviewer feedback, such as request for corrections, is not
software defects can be traced back to badly written require- standardized by existing process setup. Also, the feedback
ments [2]. This is also the case with avionics software [3], is written in natural language, which may lead to feedback
[4]. Indeed, the cause of many avionics software defects have misunderstandings.
been traced back to requirement engineering (RE) errors, such We claim that the quality of requirements and of RE
as, errors in recognizing requirements, requirements not well can be improved with a sophisticated and computer-aided
documented, and communication errors within and between process. This paper describes our initial steps towards the
development teams [4]. mitigation of the problems described above by proposing a
Therefore, a proper RE process that reduces the chances of Software Requirements Process (SPR), called Computer-Aided
flaws is important for the avionics industry. For the process SRP (CSRP), that is supported by automated mechanisms for
design we consider two important observations in industry requirements quality assurance and structured feedback. Our
(gained within the ASSET1 project): First, the role of the Re- CSRP relies on the following three key ideas:
viewer (SRR) needs stronger guidance. The Reviewer (SRR) • Domain Specific Requirements (DSR) which are require-
can be a company- internal department ensuring that his ments containing formal or semi-formal data. Different
requirements are correctly specified or further developed by types of DSRs are associated to different data. The data is
an another department or an external company within the next written by SREs using forms and graphical interfaces which
development stage. We consider the special transition from resemble the usual structure of the requirement. Instead of
System Requirements to High Level Software Requirements. using natural language, the data in a DSR have precise
Today, the SRR is involved in the development of the re- meaning, enabling a number of automated quality checks;
quirements of the next development stage and supports with • Automated Quality Checks, which rely on the (semi-)
clarification of provided requirements, but do not follow a formal data in DSRs to check automatically for errors in
structured procedure. Second, the particular software in the the quality of requirements. This not only facilitates the
domain of avionics needs to comply with the objectives of reviewing work, but also turns the process more agile, as
the DO-178C/ED-12C [5] in order to obtain certification. SREs can obtain feedback on the quality of requirements
1 The ASSET Project (Avionic System Software Embedded Technology)
before interacting with the SRRs. We illustrate the checks
was financially supported by the Aeronautical Research Program V (LuFo V) here with two types of DSRs (Mode and Signals);
of the German Federal Ministry of Economic Affairs and Energy. • Structured Reviewer Feedback from the SRRs to the
AvioSE 2019: 1st Workshop on Avionics Systems and Software Engineering @ SE19, Stuttgart, Germany 75
SREs. Instead of simply communicating the review of
Automation
Analysis:
Proceed back
Automated
requirements in natural language only, reviews in CSRP checks
to SRE
are categorized according to the quality parameter that is
not being satisfied. We argue that such feedback reduces the Software Development of High- Level
SRE
communication errors within the requirement engineering Requirements
Standard
High Level
Requirements
Requirements
processes, thus leading to better quality requirements.
NOT
We illustrate the CSRP by a simple proof of concept Review:
OK
SRR
Start System
Manual
example of an embedded system examined in the ASSET Requirements
checks
OK
project. We start by reviewing relevant literature in Section II.
We describe the general process of the CSRP in Section III and
Fig. 1. Computer-Aided Software Requirements Process for HLRs. The
discuss DSRs in Section IV. We describe a case-study of an Process for LLRs is similar and follows once HLRs have been developed.
embedded component for avionics in Section V. We conclude
this short-paper by pointing out to future work in Section VI.
Finally, we point out that we implemented part of the ma- Textual-like patterns [11]–[13] provide a general set of
chinery described in this paper in the tool AutoFOCUS3 [6]. textual patterns that can be mapped to formal specifications
expressed in LTL and its extensions. Requirements are written
II. Related Work in natural language, but still become formalized. The disad-
vantage is that the types of patterns is constrained by the
We can roughly classify Requirement Engineering (RE) underlying formal language.
literature into three different categories: Natural-Language This paper is inspired by the model-based Integrated Re-
Based Requirements (NLBR); Formalized Requirements; and quirements Analysis (MIRA) framework [14], [15]. A key
Pattern-Based Requirements. We detail this literature below. difference is that, while MIRA proposes methods for for-
The literature in NLBR uses textual requirements being malizing textual requirements, by using Message Sequence
closer to the actual industry practice. Therefore, the proposed Charts (MSC) or even logics, such as CTL, here we identify
methods implementing a type of Controlled Natural Language templates that resemble closely usual textual requirements.
based on Natural Language Processing (NLP), e.g., ensuring Thus, by using our templates, a SRE does not have significant
active voice, can be directly applied in existing practices. additional effort, such as writing MSCs or CTL formulas, in
Achour classifies in [7] methods in NLP in three categories: developing requirements, while still profiting from automated
lexical, syntactic and semantic. The general goal is to interpret quality checks. Finally, our methodology is more general than
the meaning of sentences by identifying sentence objects and MIRA, as it can be used in development processes different
constructing relations among these objects. They can check, from model-based Engineering processes.
for example, when some sentences are ambiguous or do not In comparison to NLP methods we do not analyze for
comply with RE practices. Some commercial tools are offered syntactical quality, but we structure requirements to ensure
to industry already, e.g., [8], [9]. However, given the informal their quality using automated methods based on well defined
nature of natural language, it is not possible to capture the semantics. The requirement’s structure and its associated se-
exact intended semantics of textual requirements. mantics is domain specific. This allows us for a finer analysis
The literature on formalized requirements assumes that of requirements, e.g., consistency and completeness.
requirements are specified in some formal language, such as
Linear Temporal Logic [10] formulas. The advantage of this III. Computer-Aided Software Requirements Process
approach is that a large number of properties can be for- As pointed out in the Introduction, key sources of problems
mally verified using techniques, such as model-checking. The involving requirements are errors in communication and errors
disadvantage is these methods are two-fold: Firstly, writing in requirements. We strongly believe that many of these errors
such requirements is very cumbersome and therefore, have can be mitigated by adding automated support to the SRP.
not been widely adopted in practice. Secondly, the types of Figure 1 depicts the workflow of our CSRP. It complies
requirements that can be written is also constrained by the with the DO-178C/ED-12C objectives. In particular, System
formal language used. For example, non-functional require- Requirements and Software Requirements Standards are given
ments cannot be specified in LTL. as input to the SRP. High-Level Requirements (HLRs) and
The third type of approach, in which this paper is also Low Level Requirements (LLRs) are the output of the process.
included, is the Pattern-Based Requirements. Instead of writ- Moreover, the HLRs and LLRs shall satisfy some quality
ing requirements as formal specifications, SREs use pre- criteria, e.g., unambiguity, verifiability.
established requirement patterns. Patterns may be textual- SREs and SRRs carry out the process, where SREs develop
like specifications using a Controlled Natural Language [11]– requirements, while SRRs review requirements in order to
[13], e.g., the sentence written with a particular structure; assure their quality. These roles are reflected in Figure 1.
Patterns may also be graphical representations, using diagram Our process contains a third role of automation. Automation
notations, such as UML and Sys-ML, and inspired by model- includes simple checks, such as (those proposed in [15])
based approaches [14], [15]. checks whether each requirement has an ID, an author, a
AvioSE 2019: 1st Workshop on Avionics Systems and Software Engineering @ SE19, Stuttgart, Germany 76
Fig. 2. Illustration of a Structured Reviewer Feedback template.
rationale, but also more complex ones, like automated checks
Fig. 3. DLUF Mode Automaton
for ambiguity, consistency, completeness. We illustrate some
of these automated checks in Section IV.
Our hypothesis here is that specially tailored requirement
From the given system requirements, SREs write HLRs.
templates for specific domains, called Domain Specific Re-
These HLRs can be textual requirements or DSRs which
quirements (DSRs), can support a large number of automated
resemble the textual requirements, but enable more automated
quality assurance checks and at the same time be used in
checks. HLRs are not manually reviewed by SRRs until all
practice. This is because, while data is structured or even
suitable automated checks have been satisfied. Whenever an
formalized, the template used in DSRs resembles closely the
automated check is not satisfied, an error message is returned
textual requirements written for the particular domain.
proving further details for the error. In this way, the SREs
can immediately have a feedback on the quality of the written Different DSRs will have different templates. The challenge
HLRs without the need of the SRRs assessment. This saves is, therefore, to develop requirement templates that resemble
time in the SRP as it reduces the number of reviewing cycles textual requirements, but at the same time allow for greater
in the SRP and also ensures the quality of requirements. number of automated checks. We illustrate DSRs next with
two examples, including their supported automated checks.
Once all checks have been satisfied, the SREs can forward
the developed HLRs to the SRRs for reviewing. The SRRs
carries out reviewing that is not captured by the automated A. Two Examples of DSRs
checks. For example, the consistency of names or the lan- Our first example of DSR is for the specification of the
guage used in the textual requirements. In order to guide the modes of an embedded system and the second example for
reviewer and improve the process, we also developed pre- the specification of the signals of an embedded system.
defined feedback templates. A partial template is depicted in
a) Mode DSR: Mode requirements normally contain
Figure 2. Instead of writing reviews as a document, SRRs fill
a diagram resembling a state transition system. Modes are
the feedback template containing more structure. This helps to
represented in the diagram as states and arrows from states are
ensure, that SRRs have taken into account all relevant quality
drawn representing the allowed mode transitions. Moreover,
parameters and also helps SREs better understand the feedback
the conditions when the transitions can occur are specified
provided, thus mitigating errors in communication.
(normally, in LLRs, though) in text. In embedded systems,
LLRs are developed once the HLRs are approved, follow-
conditions are based on the values of the signals of the
ing same strategy, namely, SREs develop requirements with
embedded system. Figure 3 depicts such a diagram.
automated support and reviewer feedback. However, the types
Unfortunately, the diagram with the state transition system
of automated checks may be different as LLRs shall satisfy
does not allow any automated checks to be carried out as the
other quality parameters, e.g., contain enough information for
diagram cannot be parsed by a machine. We propose instead
development and verification.
to directly write the diagram as a state-automaton using the
machinery provided by AutoFOCUS3. The effort required by
IV. Domain Specific Requirements and Automated Checks
an SRE to write the state-automaton is similar to the effort
The greater the number of automated checks, the greater is of drawing the diagram. However, the state-automaton can be
the chance of obtaining higher quality requirements. However, parsed by AutoFOCUS3 and automated checks can be carried
the number of automated checks depends on the level of out, which were not possible with the diagram alone.
formalization of the requirements. On the one hand, informal, b) Signals DSR: Signals are normally specified textually
textual requirements only allow for simple checks, such as by sentences of the following form: “The system shall contain
the presence of rational, id numbers, while more complicated an input signal called s of type int and ranging from [0, 255].”
checks such as consistency, completeness has to be carried This textual requirement contains the name of the signal, the
out manually. On the other hand, formal requirements written type of data transmitted in the signal and its range. A signal
in a formal languages, such as LTL specifications [10], allow requirement that does not contain, for example, the type of the
for more complicated checks to be carried out automatically signal, would be ambiguous, as it would allow for both integers
using automated tools. However, formal requirements are not and floats to be transmitted. Unfortunately, it is not possible to
widely used in practice, as they are far more laborious to write, perform this check automatically as a machine cannot parse,
requiring many times expertise knowledge. in general, this information from the textual requirement.
AvioSE 2019: 1st Workshop on Avionics Systems and Software Engineering @ SE19, Stuttgart, Germany 77
The signals DSR contains a table of the form: SRP: The CSRP significantly reduced the personal meet-
ings. The review took 36% of the total development time. 8%
Name I/O Type Lower Range Higher Range
of the time were spend with the improvements according to
s input int 0 255
SRRs feedback.
Notice that the effort required by the SRE to fill in this table DSR: To all requirements at least one DSR was as-
is similar to the effort required to write the sentence above. signed. Several System Requirements contained information
that needed to be split into two or more different DSRs.
B. Automated Checks
VI. Conclusions and Future Work
Some checks can be performed taking into account each
DSR individually, while others take into account both DSRs. This paper discusses our initial results towards the devel-
In both cases, some quality criteria, such as Comprehensibility, opment of a CSRP. In particular, this process is supported
Modifiability, Good Structuring are inherited by the formal by Domain Specific Requirements, Automated Checks and
nature of state automaton in Mode DSRs and of signals table Structured Reviewer Feedback. One key motivation which
in Signal DSRs. differentiates us to other proposals is the use of requirement
We describe some automated checks for Mode DSR and templates that closely resemble textual requirements written
elide the checks for Signal DSRs due to space limitations. The in practice, but allow for automated checks. We describe our
checks use standard machinery from automata theory [16]. first experiences with this approach in an avionics case-study.
• Ambiguity: It shall not be possible to transit from a
As future work, we are identifying a suit of DSRs expanding
mode to more than one mode with the same conditions. on the ones we described here. In particular, we are aiming
This property is reduced to checking that the mode state for DSRs used for non-functional requirements, such as perfor-
automaton is deterministic [16]. mance requirements. We are also currently further developing
• Verifiability: It is possible to verify each transition of the
our AutoFOCUS3 implementations to support new DSRs and
state automaton without to modify it. In particular, for each new automated checks. Finally, we are also envisioning a
transition, it is possible to state the starting mode, the values refinement of the process described here with information on
of the signals and the expected final mode. the dependency of DSRs. For example, the checking of the
• Consistency: This quality criteria can also be checked by
completeness of the mode DSR is only possible once the
using machinery available for state-automaton. For exam- signals DSR is available. Including these dependencies into
ple, we check whether all modes can be reached using state the process will also help guide SREs and SRRs in order to
reachability algorithms available in automata theory [16]. profit the most from automated checks available.
For Signal DSRs, we can also check for these quality References
requirements using the information available in the signals [1] F. A. A. U.S. Department of Transportation, “Requirements engineering
table. For example, it is not consistent if the lower bound management handbook, final report,” 2009.
[2] S. P. Miller, A. C. Tribble, M. W. Whalen, and M. P. Heimdahl,
is greater than the upper bound. Or it is ambiguous if some “Proving the shalls,” Int. J. Softw. Tools Technol. Transf., vol. 8, no.
fields in the table are missing. 4-5, pp. 303–319, Aug. 2006.
Finally, for automated checking of the Completeness of the [3] T. Nakajo and H. Kume, “A case history analysis of software error
cause-effect relationships,” IEEE Trans. on Soft. Eng., 1991.
Mode DSR we need to use the data available in the Signals [4] R. R. Lutz, “Analyzing software requirements errors in safety-critical,
DSR. For example, if a signal s can have values 0,1,2 and a embedded systems,” 2001.
mode has transitions considering only s == 1 and s == 0, but [5] “RTCA DO-178C / EUROCAE ED-12C: Software Considerations in
Airborne Systems and Equipment Certification,” Standard, 2011.
no transition with s == 2, then it is not complete. [6] V. Aravantinos, S. Voss, S. Teufl, F. Hölzl, and B. Schätz,
“AutoFOCUS 3: Tooling concepts for seamless, model-based
V. Case Study DLUF development of embedded systems,” in ACES-MB ’15, 2015.
During the ASSET project, one team was engaged with the [7] C. B. Achour, “Linguistic instruments for the integration of scenarios
in requirement engineering 1 ( position paper ),” 1997.
development of the Data Link Upload Feed (DLUF) and took [8] Ravenflow, “Ravenflow,” 2018. http://www.ravenflow.com/
the role of SRE. The customer of the developed software was [9] the REUSE company, “Requirements quality suite,” website, called
the SRR. 2018. hhttps://www.reusecompany.com/requirements-quality-suite
[10] A. Pnueli, “The temporal logic of programs,” in FCS, 1977.
DLUF description: In the context of avionic systems, the [11] M. B. Dwyer, G. S. Avrunin, and J. C. Corbett, “Patterns in property
Data Link may be used by several so-called Data Link user to specifications for finite-state verification,” in ICSE ’99. 1999.
[12] M. Autili, L. Grunske, M. Lumpe, P. Pelliccione, and A. Tang, “Aligning
transmit data packets. One or several Data Links users, or more qualitative, real-time, and probabilistic property specification patterns
exactly the data they send, may have a higher priority than using a structured English grammar,” IEEE Transactions on Software
others. Due to the data rate budget, determined by properties Engineering, vol. 41, no. 7, pp. 620–638, July 2015.
[13] A. Mavin, P. Wilkinson, A. Harwood, and M. Novak, “Easy approach
of the Data Link in its selected operation mode (which may to requirements syntax (EARS),” in RE 2009.
also dynamically change), packets from lower priority could [14] A. Vogelsang, “Model-based requirements engineering for multifunc-
prevent packets of higher priority to be transmitted if the tional systems,” Ph.D. dissertation, TUM, 2015.
[15] S. M. Teufl, “Seamless model-based requirements engineering: Models,
budget is exceeded. guidelines, tools,” Ph.D. dissertation, TUM, 2017.
We summarize the results of the two main aspects of our [16] J. E. Hopcroft, R. Motwani, and J. D. Ullman, Introduction to Automata
investigations, the CSRP and the DSR usage: Theory, Languages, and Computation (3rd Edition). 2006.
AvioSE 2019: 1st Workshop on Avionics Systems and Software Engineering @ SE19, Stuttgart, Germany 78