Figure 4.7:Summary of the positive impacts (++,+) of QA quality factors on automated QA techniques; in brackets behind the impacts are the sections where the impacts are discussed
4.6 Constructive Quality Assurance
The QA quality factors discussed in Section4.5impact the effectivity and efficiency of QA by automation. Creating a requirements specification with defined concepts, attributes and representation forms may already have a positive effect on the system quality factors. Hence, this section investigates these QA quality factors to determine those positive impacts in answer to research question RQ 1.4.
4.6.1 Pre-defined Entities
Pre-defining a set of mandatory RE conceptscan increaseactivity completenessof the requirements specification with respect to development activities. Each of these RE concepts to be contained in a requirements specification should be related to a de-velopment activity. A thorough analysis of all RE concepts with respect to their use in the development process reduces unnecessary documentation effort. A thorough analysis of the development process with respect to undefined RE concepts reduces the risk of undocumented or unconsolidated information. Furthermore, for each RE concepts, the QA quality factors can be determined that are necessary for a specific QA technique. For example, formal verification of requirements requires a formal representation. The precise definition of RE concepts that should be instantiated as concrete objects in the requirements specification facilitates a guideddocumentation;
the contents of the requirements specification are elaborated according to these defi-nitions. For example, VOLERE defines the main entities to be contained in a require-ments specification; the authors recommend the use of this template as a checklist in manual reviews to determine missing requirements [RR06, p. 323ff].
4.6.2 Pre-defined Attributes
“To support requirements analysis, well-formed requirements should have de-scriptive attributes defined to help in understanding and managing the require-ments” [ISO11b]. Attributes guide and restrict the instantiation of each concept of the requirements specification, ensuring that it has the necessary constituents for the development activities performed on an entity. A structured description of a concept by pre-defined attributes can further improve activity completeness of development task by defining the concrete information to be documented for a concept. Tiwari [TG14] gives indications by a comparative study that a template that defines a more detailed set of attributes for use cases yields more complete and less redundant use cases in comparison to a less detailed template. An example for a positive impact on QA efficiency is an attribute that defines the QA status of a requirement. This status indicates whether a requirement has been fully specified, analyzed, validated or verified.
Enumerations and other more rigorousdata typescan further increase the quality of a requirements specification constructively by avoidingtype inconsistencies. A uniform definition of data inputs is particularly valuable when data is entered by multiple users.
4.6.3 Pre-defined Trace Links
The fundamental concepts for the entities concerned in thetracingactivity are based on Gotel el al. [GCHH+12b]. A trace artifact is a “traceable unit of data (e.g., a single requirement, a cluster of requirements, a UML class, a UML class opera-tion, a Java class or even a person)” [GCHH+12b]. A trace artifact may be fur-ther described by its type. A trace artifact type is “a label that characterizes those trace artifacts that have the same or similar structure (syntax) and/or purpose (se-mantics). For example, requirements, design and test cases may be distinct artifact types” [GCHH+12b]. A trace link is defined as a “specified association between a pair of artifacts” [GCHH+12b]. This work extends the definition by allowing for more than one source or target artifacts, depending on the trace link type. A trace link can be directed from source artifact to target artifact, otherwise it is undirected.
A trace link can be annotated with its trace link type or other semantic attributes.
Atrace link typeis “a label that characterizes those trace links that have the same or similar structure (syntax) and/or purpose (semantics). For example, ’implements’,
’tests’, ’refines’ and ’replaces’ may be distinct trace link types” [GCHH+12b]. Atrace consists of the triplet source artifacts, target artifacts, and trace link. Precisely defin-ing RE concepts facilitates to define trace artifacts and trace links as a subset of these concepts; this definition of trace artifacts and trace links directly impactstracing pos-itively. For example, based on the definition of stakeholders and goals, it can be defined to establish a trace link between a stakeholder and its goals. Documenting the refinement links from goals to detailed system requirements may reveal missing requirements, hence improvingexternal completeness. Similarly, for cross-references, the referenced entity must exist.
4.6 Constructive Quality Assurance
4.6.4 Semi-formal and Formal Representation
The contents of the requirements specification are often documented as uncon-strained prose. A textual description of requirements is a commonly agreed specifi-cation formalism and understandable by all stakeholders of the system [Sch09]. The down-side is the lack of precision that may lead to quality issues like inconsistencies or ambiguities [Sch09].
A means to add rigor to natural language requirements that is still understandable by all stakeholders is controlled natural language. For example, a series of experi-ments showed that EARS patterns reduced many common requireexperi-ments quality is-sues [MW10]. EARS patterns define a simple sentence structure for system require-ments. The patterns improve thebehavioral completenessof a requirement by reduc-ing missreduc-ing preconditions, triggers and system responses; they helped to identify-ing missidentify-ing requirements, thereby improvidentify-ingexternal completeness; and they reduce vagueness, hence improvingunambiguity. Controlled natural language that restricts both syntax and semantics may even facilitate an automatic transformation to logical expressions, thereby enabling formal techniques [Sch10].
An experiment compared use case templates with two simple templates to define system interfaces and system functions [MMGD10]. Students used a set of templates to document system requirements for a study object. Students using the case tem-plates documented more interactions of the system with its environment and more information about the required system behavior. The study indicates that using use case templates to document system functions can improve thebehavioral and external completenessof a requirements specification compared to more simple templates.
Templates and controlled natural language add rigor to natural language require-ments, without having the same negative impact on understandability as a graphi-cal or a math-based representation of requirements. As a side effect, a semi-formal representation can also support theformalizationof an RE concept to a formal repre-sentation: Mapping rules from the semi-formal specification technique to the formal technique can guide the formalization, thereby supporting the transition from a tex-tual to a formal representation. If the template defines the information required for a formalization, this increasesactivity completeness.
When a requirement is formalized, it not only facilitates advanced analytical QA techniques; it also directly adds to constructive quality assurance. The formaliza-tion of requirements eliminates theambiguityof prose [Bro13a]. A formal modeling language enables aprecisespecification of requirements [Bro13a]. Heimdahl [Hei07]
also reports on the constructive benefits of formalizing functional requirements as properties in temporal logics (more precisely, in CTL [CGP99]): “The process of cre-ating a model from the English prose requirements caused us to go back and clarify the English statement of the requirements. In the same way, translating the English statements into SMV [a tool for symbolic model checking4] also prompted us to go back and clarify the English statement” [Hei07].
When setting up a formal refinement specification, the stimuli and reactions defined in the involved requirements are mapped. Setting up such a formal refinement spec-ification can identify stimuli or reactions that are missing in the refining or refined
4http://www.cs.cmu.edu/~modelcheck/smv.html,lastaccessed9.5.2016
requirements, thereby revealingbehavioral incompleteness.
Modeling languages and their modeling notations have limitations regarding their expressivity. Typically, not all requirements of a system can be formalized due to a lack of an appropriate modeling notation. For example, real life case studies on formalizing requirements to use cases and contracts using logical expressions could only formalize 79% of the requirements due to the missing support for arithmetic and real-time aspects [NFTJ06]. A classification of requirements into requirement types could indicate which requirement type can be expressed with which modeling notation. Therefore, distinguishing requirements into more fine-grainedRE concepts can have a positive impact on the formalization. For example, SPES distinguishes requirement types according to different SysML notations [DTW12]. The FOCUS system modeling theory facilitates to formalize interface requirements, requirements on the syntactic interface of a system and on its logical interface behavior. Auto-FOCUS3 provides a set of specification techniques to model interface requirements.
For example, a state automaton is suitable to model the required interface behavior of a system. However, a state automaton is not an appropriate means to model the communication of a system and its environment. AutoFOCUS3 provides message sequence charts that are suitable to model communication (in terms of sequences of messages). For details on FOCUS and AutoFOCUS3 see Section2.3.
4.6.5 Summary
Creating a requirements specification with the QA quality factors discussed in Sec-tion4.5 can indeed have a positive effect on the system quality factors. In answer to research question RQ 1.4., the table in Figure4.8provides an overview of the QA quality factors of the various RE concepts, it lists the activities where these QA qual-ity factors are created and it lists the positive effects on the system qualqual-ity factors.
Figure 4.8:Summary of the constructive impacts (++,+) of the QA quality factors for auto-mated QA; in brackets behind the impacts are the sections where the impacts are discussed