severe impact on the system under development.
An interesting finding of the investigation is that some of the factors mentioned by van Lamsweerde or in the ISO 29148 would not be classified as a quality factor in an activity-based quality model. They would rather be classified as activities or im-pacts. As future work, a broader systematic investigation could be conducted using the activity-based quality model. This investigation could a) classify factors from lit-erature to the activity-based quality model on a bigger scale, and b) identify more quality factors of the requirements specification that impact the quality of the system under development.
4.4 Concepts of the Requirements Specification
In order to answer research question RQ 1.2, a set of RE concepts are introduced.
Each concept has an immediate impact on specific QA activities when it is instanti-ated. Explicitly pre-definingthese RE concepts supports the person that creates the requirements specification or parts thereof to document these. Thereby, the person that performs QA can benefit from these impacts. Furthermore, defining RE concepts has immediate merits on constructive and automated QA. With corresponding tool support, the contents of a requirements specification can be stored according to these definitions. This facilitates to automatically access and evaluate the information. The precise definition of RE concepts facilitates to define further essential characteris-tics that are necessary to conduct automated QA, for example, representation forms.
These benefits are explicated in the subsequent chapters. In the following, we present the RE concepts and describe their impact on the QA activities.
4.4.1 Goals
A goal is “an objective the system under consideration should achieve" [vL01].
Thereby, goals are stakeholder intentions that “represent a first manifestation of the stakeholders’ system vision” [DTW12, p. 55]. For example, the goal of a pedestrian using a traffic light system is to safely cross the street. Documenting goals can sup-port the quality assurance: Goals provide a criterion for the external completeness of system requirements [vL01]. Assuming that the set of goals is complete, then the re-quirements are complete, if all goals can be achieved from the rere-quirements and the considered domain properties. Unrefined goals may indicate missing requirements.
“Goals give rationales and justifications for the functionality and features a system must possess” [DTW12, p. 55]. Access to these rationales and justifications enables the stakeholders to understand the rationale of a system requirement. Thereby, goals support the validation of requirements.
4.4.2 System Requirements
A system requirement is a prescriptive statement to be enforced by the system under development. System requirements form the basis for the design, implementation and quality assurance of the system under development. Defining and documenting
system requirements is a precondition for their (semi-)automated analysis, valida-tion and verificavalida-tion that is discussed in Secvalida-tion4.5. It is commonly distinguished between requirements concerning the functionality of a system and others [Gli07]. A study [EVMF16] investigated why practitioners distinguish between functional and extra-functional requirements. According to the study, the main differences in QA processes are: 1.) Different stakeholders are involved in development activities on the requirements; 2.) the quality assurance techniques differ; 3.) extra-functional requirements need to be monitored continuously during the implementation in con-trary to functional requirements. Practitioners distinguish them because they want to achieve more complete and less ambiguous requirements. The study could not confirm a clear positive impact of a distinction on quality assurance. Practitioners that distinguish functional and extra-functional requirements, claim that this leads to missing testability; others state that this results in focused tests and explicit test for extra-functional requirements. Practitioners that do not distinguish them, claim that validation and verification suffer; other state that the tests are more comprehensive.
Summarizing, from a project-independent viewpoint, the impact of distinguishing functional and extra-functional requirements on quality assurance needs to be inves-tigated further for specific QA techniques.
4.4.3 Use Cases and Scenarios
(System) use cases describe an excerpt of interactions of a system under development with its actors for a certain case of use. The system thereby responds to the request of one of the actors in order to achieve a particulargoal. Use cases can be detailed byscenarios. Scenarios describe the steps from the trigger to goal delivery, inclusive any “clean-up” [Coc00] afterwards. They can be described depending on the partic-ular requests and conditions surrounding the requests. A use case collects together those different scenarios [Coc00]. For example, a use case may collect all scenarios that describe how a pedestrian uses (or missuses) the traffic light system to cross the street. Use cases and scenarios help stakeholders to validate the goals that they cover [vL01].
4.4.4 Refinement Links
A refinement link documents the refinement from and within goals, use cases and system requirements. As discussed above, the refinement from goals to use cases, scenarios and system requirements enables specific quality assurance activi-ties. When these refinements are documented explicitly as refinement links, every-body who conducts quality assurance on the requirements specification can access the information about refinements at all times.
4.4.5 External Trace Links
External trace links connect requirements with other development artifacts, for ex-ample, a concept of the system architecture. Thereby, external trace links enable ver-ification: When requirements are derived from other artifacts, this link can be
evalu-4.4 Concepts of the Requirements Specification
ated to verify the requirements against this artifact. When an artifact is derived from requirements, the link can be evaluated to verify the artifact against its requirements.
4.4.6 Glossary
A glossary provides definitions of the domain-specific terms that are used in the requirements specification. Thereby, a glossary supports persons involved in the quality assurance activities to have a common understanding of the concepts be-hind these terms.Lexical ambiguitycan be caused by a word with different meanings (homonyms) and by different words with the same meaning (synonyms) [Poh10].
Defining the meaning of terms used in the requirements specification in a glossary can decrease these kinds of ambiguity [Poh10].
4.4.7 Requirement Sources
Each requirement has a source from where it origins. These sources can be docu-mented as requirement sources. The requirement sources can be differentiated in three types: Stakeholders, documents and external systems [Poh10]. Astakeholderis anyone with an interest in or an effect on the outcome of the system under devel-opment [RR06]. An instantiation of a stakeholder of the traffic light system is the pedestrian that uses this system to cross a street. To elaborate all instantiations of a stakeholder, all persons with an interest in or an effect on the outcome of the system under development have to be identified. Documentsinclude for example standards or specifications of similar or preceding systems. Further requirements can stem from thoseexternal systemsthat the system under development should interact with.
Pohl [Poh10] discusses the positive impact of requirements sources on a more ex-ternally complete requirements specification. Documenting requirement sources can also be valuable during the manual quality assurance of requirements as they may be the rationale for a requirement. Analogously to glossary terms, when stakeholders have access to a definition for each requirement source, then this can decreaselexical ambiguity[Poh10] and ensure a common understanding of the relevant requirement sources amongst the stakeholders.
4.4.8 Cross-References
Glossary terms and requirement sources provide term definitions on the domain-specific context of a system under development. These term definitions can help to improve the understanding of those persons that are reading the requirements.
Stakeholder read requirements as part of a manual quality assurance. A cross-reference connects the domain-specific terms used in a requirement with their term definition as glossary terms and requirement source. For example, goals state the intent of one or more stakeholders and may document this stakeholder. Therefore, a goal could have a cross-reference to this stakeholders. An alternative would be to have redundant term definitions in the specification. Less redundant information may lead to less inconsistencies, because each piece of information has to be docu-mented and changed only once. A study [JDF+10] investigated the impact of
redun-dant information in form of clones on development activities. The study was per-formed on 28 software requirement specifications from various domains including embedded systems. The authors of the study concluded that cloning significantly in-creases the effort for activities that involve reading the requirements specification, for instance, during inspections. Changing duplicated information is costly and error-prone. Cloned fragments of the requirements specification can lead to clones in the code or developing the same functionality repeatedly; cloned code may lead to in-consistent changesthat may even lead to system failures. The authors concluded that to prevent the negative consequences of clones, redundancy in a requirements spec-ification should be avoided.
4.4.9 QA Results
After the application of a quality assurance technique, theQA resultshave to be docu-mented if they are not resolved immediately. For example, QA checklists that capture the applied activity and its results could be defined in addition to the requirements specification. These checklists should be traced to the investigated contents. Specific trace link types can be used to document quality issues affecting several require-ments for further processing. An example are inconsistency trace links to document inconsistent requirements.
4.4.10 Summary
In answer to research question RQ 1.2, we investigated a set of RE concepts such as goals and use cases that enable specific quality assurance activities. The activi-ties are concrete quality assurance checks, for example, check the completeness of requirements, or are subactivities, for example, to understand the rationale of a re-quirement. Pre-defining the RE concepts facilitates the requirements engineer (or any person that writes a specification) to instantiate them and make use of the positive impact on the quality assurance activities. The impacts of these concepts on quality assurance activities are summarized in Figure4.5.