Requirements Engineering Artifact Quality: Definition and Control
Henning Femmer · mediaTUM – the media and publications repository of the Technical University Munich (Technical University Munich) · 2017
Requirements Engineering (RE) artifacts are central entities in the software engineering process.Based on these artifacts, project managers estimate effort, designers create architectures, developers build the system, and test managers set up a test-strategy.Consequently, quality defects in RE artifacts can cause expensive consequences in subsequent software development activities.Therefore, quality control of RE artifacts is key for successful software development projects.However, quality control of RE artifacts faces two problems: First, the definition of RE artifact quality often remains incomplete, inadequate and imprecise.This problem concerns both the definition of valid quality factors as well as the claimed impacts of these quality factors onto projects.Second, in addition to the lack of a precise quality definition, we also struggle to assess any definition of quality in practice, since finding defects is labor-intensive and error-prone. ContentsRE artifacts need quality control.Hence, projects employ quality control (QC) to prevent, detect or mitigate defects.However, as Mendez and Wagner [MW15] found in a large-scale survey, even though requirements engineers consider QC very beneficial, they find it very challenging at the same time.Furthermore, despite the importance of RE artifact quality, the status quo of RE artifact quality in practice is devastating: Practitioners report that many projects suffer from imprecise, inconsistent, or incomplete artifacts.According to the survey, these defects are major reasons for project failure, e.g. in terms of a software not fulfilling stakeholder needs ISO-8 characteristics are incomplete.ISO-29148 describes quality through a set of abstract characteristics (see Ch. 2.4.3.1).When analyzing the characteristics in detail, we see that there are two different types of characteristics: Some characteristics, such as ambiguity, consistency, completeness and singularity are factors that describe properties of the RE artifact itself.In the following, we call these factors artifact-based properties.In contrast, feasibility, traceability and verifiability state that activities can be performed with the artifact (we call these activity-based properties, see Fig. 1.2).This is a small, yet important difference: While the former can be assessed by analyzing just the artifact by itself, the latter describe a relationship of the artifact in the context of its usage.Yet this usage context is incompletely represented in the quality model: For example, why is it important that requirements can be implemented (feasible in the terminology of ISO-29148) and verified, but other activities, such as maintenance, are not part of the quality model?Therefore we argue that normative standards do not take all activities into account systematically, and thus, are missing relevant quality factors. ISO-8 characteristics are not context-dependent and thus inadequate.One could go even further and ask about the value of some artifact-based properties such as singularity.What is the purpose and reason behind such a property?In this case, usually, singularity is considered important especially in regulated environments, e.g. the medical sector, where regulators put the obligation on software producers to verify each requirement of the system.Identifiable, singular requirements ease such a process.But what if the requirements are not used as, e.g. a legal document, and not tested sentence by sentence?Does the property still benefit to the developers?1 Please note that while we show the arguments along the ISO-29148 in this section, the same arguments can be made for other definitions of quality.. . The Problems of RE Artifact Quality ControlSingularity Reading