In order to answer research question RQ 1.3, we analyze the model-based quality as-surance techniques presented by van Lamsweerde [vL09]. We investigate the factors that the requirements specification must exhibit in order to enable an automation of these techniques.
Analytical quality assurance consists of several subactivities, where one or all of these subactivities can be automated: Firstly, the objects are selected from the requirements specification that should be investigated. Secondly, we need to apply the concrete quality assurance technique on these objects. Simulation, database queries and for-mal techniques are some of the main analytical techniques for quality assurance in RE that can be automated [vL09, p. 187ff]. According to a survey amongst 419 soft-ware projects [FGZ15], the majority of these projects used manual inspections and
4.5 Automated Analytical Quality Assurance
Figure 4.5:Summary of the impacts (++,+) of pre-defining RE concepts on QA activities;
in brackets behind the impacts are the sections where the impacts are discussed
reviews, 8% of the projects applied simulation and 7% automated checking on a for-mal specification of the system. This survey did not include database queries into the list of answers to select. Finally, the results are documented; this is necessary, if the technique is automated or the resolution of the detected issues should be decoupled from the resolution. The resolution of detected quality issues is out of scope of this work. The quality assurance techniques and the subactivities to perform them are depicted in Figure4.6.
Automated techniques require a specific structure and representation of the informa-tion contained in the requirements specificainforma-tion. For example, a requirement has to be represented using a formal modeling language to apply formal techniques.
This structure and representation directly positively impacts the quality assurance activities as it enables automated analysis, validation and verification techniques.
Therefore, the structure and representation of a requirements specification are the QA quality factors under investigation.
4.5.1 Automated Queries on a Requirements Database
Automated queries on a requirements database require that the requirements specifi-cation isstructured by an underlying data modeland that the requirements specification is stored in a database according to that data model. A machine-readable definition of
Figure 4.6:Applying automated quality assurance techniques
the requirements specification facilitates queries (with corresponding tool support).
Queries on the database can then automate inspection tasks that otherwise would have to be conducted manually. This machine-readable definition of the structure of the requirements specification can be achieved by several means. A means to enable queries is to pre-define the entities contained in the requirements specification. Fur-thermore, representing the entities using a semi-formal or formal modeling language enables syntactic or semantic checks via database queries.
Select Contents. A subactivity common to all QA activities is to select the objects contained in the requirements specification that should be investigated. Queries can automate the task of extracting and preparing the data needed for further inspection.
The definition of RE concepts enables to store the contents of a requirements speci-fication according to these definitions. If each object is annotated with its type, a query can refer to these entities. A query then can select objects based on the defini-tions. Section4.4discussed a set of concepts to support QA activities that are candi-date inputs for such a query. Trace linkscapture the dependencies within the entities contained in a requirements specification and from the requirements specification to other development artifacts. Trace links include cross-references from stakehold-ers to their requirements, refinement links between requirements, and external trace links between requirements and the system architecture specification. These trace links can be evaluated in queries. For instance, the definition of goals, system re-quirements and refinement links between them supports the completeness check on system requirements. To support this analysis, a query can extract all system require-ments that refine a goal by evaluating the refinement links. The result of this query is the input to check the system requirements for completeness. A second example are stakeholders that want to validate their requirements using simulation. Stakehold-ers and requirements are documented including cross-references from stakeholdStakehold-ers to their requirements. Then the stakeholders could identify the relevant subset of requirements using these links. If the information is stored so that it is machine-readable, then the relevant set of requirements can be extracted by a query. The def-inition of RE concepts facilitates todefine attributeson these concepts to increase the preciseness of queries. For example, a quality assurance status enables to determine only those entities that need further analysis.
4.5 Automated Analytical Quality Assurance
Analyze Consistency and Completeness. Queries can be used to automatically performconformance constraintsthatanalyzethe structural conformance of the require-ments specification to a set of rules. A language to define conformance constraints is OCL [OMG06]. Schätz [Sch09] defines conformance constraints for automating completeness and consistency analyses. Schätz defines consistency conditions on the RE concepts to be contained in the requirements specification, their attributes and trace links. Similarly, conformance constraints can be defined on the RE concepts, in-cluding the trace links discussed in Section4.4. In addition, van Lamsweerde [vL09, p. 241f] discusses queries on semi-formal and formal representations of parts of the requirements specification.
4.5.2 Semi-automated Simulation
If parts of the requirements specification are executable or can be transformed into an executable form, then this part can be simulated [vL09, p. 187ff]. Simulation is a common means for theanimation-based validationof the requirements specification.
With the help of an animation tool, various events to which the system could be ex-posed can be re-enacted in order to validate whether the response of the model is adequate. For instance, Gaucher and Jeannet [GJ16] report on the successful applica-tion of simulaapplica-tion for the validaapplica-tion of requirements in the STIMULUS tool, detecting ambiguities and omissions.
4.5.3 Formal Techniques
Mathematical techniques that can be performed on a formal specification are called formal techniques. To use advanced mathematical quality assurance techniques, re-quirements need to be expressed in a formal modeling language that uses a precise, mathematical notation and forms part of a formal system modeling theory. The sys-tem modeling theory enables a formal reasoning that can be automated with corre-sponding tool support. For automated formal analysis and verification, the modeling language needs to be translated into the input language of a model-checker, for ex-ample NuSMV2, or a theorem prover such as Isabelle3.
Analyze Consistency and Completeness and Verify Adequacy. Formal tech-niques enable checks such as type consistency checks [vL09, p. 202f], logical consis-tency and behavioral completeness checks [vL09, p. 203] and deductive verification that a behavioral model satisfies a desired property [vL09, p. 205ff]. A formal veri-fication of requirements and subsequent development artifacts prerequisites a com-mon comprehensive system modeling theory that spans both the formal represen-tation of requirements and subsequent development artifacts. This system model-ing theory is “the theoretical basis to ensure a thorough formalization of all artifacts produced during the development of a system” [BFH+10]. A modeling paradigm that enforces this comprehensive modeling theory isseamless model-based development [BFH+10].
2Available athttp://nusmv.irst.itc.it/, last accessed 9.5.2016
3Available athttps://isabelle.in.tum.de/, last accessed 9.5.2016
Formal techniques have been used for example by Rockwell Collins for the formal analysis and verification of requirements for a flight guidance system [MTWH06]
based on a formalization to the Architecture Analysis and Design Language (AADL) [FG12]. They identified a logical inconsistency between requirements and a mis-match between requirements and the implementation. As a consequence of discus-sions with domain experts, the requirements had to be changed in order to corre-spond to the implementation.
A comprehensive system modeling theory does not require to formalize require-ments and design at the same level of detail. Aformal refinement specification[BS01]
is a means to define the mapping of the syntactic interfaces of two formal mod-els. A formal refinement specification is a means to connect formal requirements on different levels of detail or to connect formal requirements and a formal model of the architecture. For example, at the requirements level, an input of the system would be defined as ‘the user activates the traffic light system’, formalized in the Boolean variabletlc_activated. At the architectural level, the according system input stems from a sensor, a button (button1), and is modelled as the integer input variable sensor_value_button1. The formal refinement specification would define the map-ping between tlc_activated andsensor_value_button1. By providing the mapping from requirements to design, a formal refinement specification facilitates a design-independent formal representation of requirements. A design-design-independent formal representation facilitates an early formal analysis of requirements before any archi-tectural model is developed. Design-independent formal requirements do not need to be adjusted, when the architecture changes. Nevertheless, the formal refinement specification needs to be adjusted in this case.
4.5.4 Document Results
Automated quality techniques often only detect quality issues, but do not resolve them automatically. Therefore, the identification and resolution are decoupled and quality assurance results need to be documented automatically.
4.5.5 Summary
This section discussed three model-based techniques, database queries, simulation and formal techniques. For each technique, the necessary QA quality factors have been discussed that the requirements specification or some of its concepts must ex-hibit. In answer to research question RQ 1.3, the table provided in Figure4.7 sum-marizes the study results for automated QA. The table sumsum-marizes the concepts and their QA quality factors that enable automated model-based QA. The impacts show, which QA factors enable which activities and which system quality factors can be improved.