Limitation to Project-Independent Quality. The relevance of the quality of the re-quirements specification depends on particular project characteristics [MMFFE15].
This means that the project context influences costs and risks of quality issues com-pared to the benefits of a high quality. However, the RE research community still lacks a deep understanding of the usage of requirements specifications in practice and the degree to which the quality of a requirements specification impacts sub-sequent development activities [MMFFE15]. Therefore, this work investigates the quality factors of a requirements specification independent of a specific project con-text. As this work does not focus on a specific project context, the investigation of costs, risks and benefits of a high quality in the requirements specification are out-side the scope of this work.
4.3 System Quality Factors
In answer to research question RQ1.1., this section classifies a set of factors from two sources into quality factors, impacts and activities as defined in the activity-based RE quality model introduced in Section4.1. We discuss and detail the factors pre-sented by van Lamsweerde [vL09, p. 36ff] and the widely used [SB13] standard ISO/IEC/IEEE 29148:2011 [ISO11b]. We will see that some of the factors consti-tute system quality factors, other factors only define activities that need to be con-ducted during the system development or impacts on these activities that need to be achieved.
4.3.1 Adequate
“The requirements must address theactual needs for a new system – explicitly ex-pressed by stakeholders or left implicit. The software requirements must be adequate translations of the system requirements [. . . ]. The domain properties must correctly describe laws in the problem world. The environmental assumptions must be realis-tic” [vL09, p. 35]. Other authors call this quality factorcorrect[ZG03]. An inadequacy may lead to animplementationthat meets its requirements, assumptions and domain properties, but that are not the right ones [vL09, p. 37].
4.3.2 Unambiguous
“The requirements, assumptions and domain properties must be formulated in a way that precludes different interpretations. Every term must be defined and used consistently” [vL09, p. 35]. Ambiguity may prevent stakeholders to understand the meaning that was intended by the author. Following van Lamsweerde [vL09, p.
37], ambiguous entities of the requirements specification allow an interpretation of statements contained in the requirements specification in different ways; ambiguous statements in the requirements specification may result in animplementationof a sys-tem built on the interpretation of requirements, assumptions or domain properties that are different from the intended interpretation.
In the field of linguistics, a distinction is made between different types of ambigu-ity [Cona]:
• Lexical ambiguitymeans that a word has multiple meanings. An example is the termbankwhich can denote a financial institution or a river side.
• Syntactic ambiguity of a sentence caused by alternative interpretations of the structure of that sentence. An example is the phrase We saw the man with the telescope.
• Semantic ambiguity occurs when a sentence contains a word or a phrase with multiple possible interpretations in the context of that sentence. The sentence We saw her duck allows to interpret her duck either as a bird or as an activity [HHS07].
This distinction facilitates to further specify the ‘different interpretations’ of a reader of a requirements specification.
4.3.3 Complete
“The requirements, assumptions and domain properties, when taken together, must be sufficient to ensure that the system-to-be [the system under development] will satisfy all its objectives. These objectives must themselves be fully identified, includ-ing quality-related ones. In other words, the needs addressed by the new system must be fully covered, without any undesirable outcomes. In particular, we must have anticipated incidental or malicious behavior of environmental components so that undesirable software effects are ruled out through dedicated requirements. A requirement on software behavior must prescribe a desired output for all possible inputs. The specification of requirements and assumptions must also be sufficiently detailed to enable subsequent software development” [vL09, p. 35]. Omitting state-ments in the requirestate-ments specification may result in animplementationthat does not take into account these statements [vL09, p. 36].
The definition of van Lamsweerde indicates the notion of external completeness.
Zowghi and Gervashi defineexternal completenessas “external completeness ensures that all of the information required for problem definition is found within the speci-fication” [ZG03]. This notion of completeness “clearly demonstrates why it is impos-sible to define and measure absolute completeness of specifications. The only truly complete specification of something would be the thing itself” [ZG03].
Behavioral completeness describes the completeness of a system with respect to its input-output behavior. Behavioral completeness can be defined by a formal descrip-tion of input-output reladescrip-tions that prescribe expected behavior. Van Lamsweerde [vL09, p. 203] suggests to require such relations to be functions where for every input situation should exist at most one corresponding output to avoid non-deterministic behavior. Requiring such functions to betotal[vL09, p. 203] ensures that an output for every input situation exists (surjective function). Often, input-output relations are defined on the input history [HL96,BS01].
The activity-based view on the requirements specification adds a third notion of com-pleteness: Activity completeness assesses completeness from the perspective of soft-ware and systems engineering activities. A requirement or requirements
specifica-4.3 System Quality Factors
tion isactivity completewith respect to a specific development activity if it comprises sufficient information to perform that activity. For example, ’performance comple-tion’ of a specification implies that it contains enough information to evaluate the performance of a system [WPS02]. The required information is highly dependent on the concrete development activity. Development activities comprise activities per-formed in RE as well as activities from other development phases such as design, im-plementation and test. Activity incompleteness may lead to the inability to perform an activity or may influence its effectivity. Depending on the activity, both may im-pact the system under development. Other activities may only imim-pact development effort and risks. It depends on the concrete activity, whether activity completeness represents a system quality factor. This chapter discusses the activity completeness for quality assurance activities. A reduced effectivity of quality assurance can affect the quality of the system under development. Therefore, activity completeness for quality assurance is a system quality factor.
4.3.4 Consistent
Requirements are elicited from different sources and viewpoints. These diverse sources and viewpoints can include contradicting expectations on the system un-der development. “The requirements, assumptions and domain properties must be satisfiable when taken together. In other words, they must be compatible with each other” [vL09, p. 35]. If a set of requirements, assumptions or domain properties con-tradicts each other, then it is impossible to produce a correctimplementation[vL09, p.
36].
Logical conditions for logical consistencyand inconsistency can be precisely defined when expressing requirements, assumptions and domain properties as logical asser-tions [GKvdBV11], [Bro13a], see also Chapter2. These conditions reveal statements that may not be implementable. Nonetheless, if the source of a conflict, for example a domain property, is not documented (not externally complete), or is an unrealistic assumption, then logical conditions may not identify inconsistencies.
Feldmann et al. [FHK+15] describetype inconsistenciesas arising from using incom-patible values and types. They also include improper type conversions and impos-sible type conversions. A prominent example for the negative impact of type incon-sistencies is the failure of the Mars Climate Orbiter; conversion errors from English imperial units to metric units resulted in a loss of the orbiter1.
4.3.5 Investigation of Further Quality Factors
Besides the system quality factors discussed above, van Lamsweerde introduces fur-ther factors. These factors do not directly impact the system under development and therefore do not constitute system quality factors.Pertinencerequires that all require-ments contribute to a goal. The absence of pertinence could lead to increased effort when finding out that a requirement is not needed. All other quality factors can be directly related to activities: Measurabilitymeans that the requirements are stated in a way that enables their testing/verification; feasibility facilitates the realization
1https://mars.jpl.nasa.gov/msp98/orbiter/
in budget, schedule and technical constraints;comprehensibilitydirectly refers to the comprehension by the users of the requirements when reading and processing the requirements;good structuringdefines the organization of the requirements specifica-tion;modifiabilitydefines a set of modification activities;traceabilitydirectly refers to the tracing activity.
The ISO 29148 also provides definitions for all system quality factors, for an unam-biguous, complete and consistent requirement as well as for complete and consistent sets of requirements. Similar to the notion of an adequate requirement, the stan-dard defines the quality factornecessary. Further factors do not directly impact the quality of the system under development, but rather impact the development efforts and risks. The quality factorboundedrelates requirements to the scope of the system, similar to the notion of a pertinent requirement. Related to the implementation of the system under development, the standard definesimplementation freeandfeasible requirements. Related to the costs of implementation is the quality factoraffordable.
Other quality factors are directly related to activities, namelyverifiableandtraceable requirements. The definition of asingularrequirement does not provide any hints on its benefits for any activity.
Without the notion of an activity-based RE quality model, the effects of many of these quality factors on the system under development remain unclear. Most quality fac-tors discussed here define and describe an activity on the requirements specification (e.g.,traceable) that should be performable. In an activity-based quality model, the quality factors that define activities would rather be defined as activities and could be refined to sub-activities and tasks.Pertinenceis a quality factor in the sense of the activity-based quality model with a clear impact (increased effort) on the implemen-tation. In an activity-based quality model, the quality factoraffordable would be a type of impact, not a quality factor. To map the quality factorsingularto the activity-based quality model requires further information.
4.3.6 Summary
The investigation answered research question RQ1.1 and identified a set of four sys-tem quality factors. Van Lamsweerde [vL09, p. 36f] provides an argumentation about the effects of these factors. We further detailed these system quality factors:
• Adequacy
• Lexical, syntactic, and semantic unambiguity
• External, behavioral, and activity completeness
• Logical and type consistency
This list is relevant, as many scientific publications in the last decades discuss these system quality factors [JLHM91, HJL96, ZG02, NER00, SBHW03,Fir05, dSAVP10].
Furthermore, an extensive interview study with experts from 30 German companies [FW13] revealed that incomplete / hidden requirements and inconsistent require-ments are two problems in the (German) industry that have been acknowledged by most of the participating practitioners (indicated by a mean and mode value of 4 on an ordinal scale, where 5 is “I agree” and 1 “I disagree”). Nonetheless, the list of quality factors is non-exhaustive; other quality factors may exist that have an equally