This work is structured as follows: Chapter 2 summarizes the various notions of quality in software and requirements engineering, and describes fundamentals and related work. We conclude this chapter by identifying the existing research gap.
In Chapter 3, we define a thesis statement based on this research gap and derive research challenges, which we break down into research questions.
In Chapter 4, we summarize the results of this thesis, structured by the research questions. In Chapter 4.1, we propose Activity-based Requirements Engineering Artifact Quality Models (ABRE-QMs). In this chapter, we summarize the results of Publications A and B. Afterwards, in Chapter 4.2, we provide a methodical overview of different approaches for creating valid ABRE-QMs. In this chapter, we summarize Publications C, D, and E, as well as the empirical study of Publication A.
In Chapter 4.3, we propose the definition of requirements smells. In Chapter 4.4, we analyze advantages and limitations of requirements smells by reporting on the results of our published studies. The results of both of these chapters are based on the Publications F, G, H, and I.
Chapter 5 summarizes and discusses strengths and limitations of the proposed methods in a larger context, before Chapter 6 summarizes this thesis and provides an outlook into future work.
CHAPTER 2
Fundamentals and Related Work
This chapter discusses the fundamental terms and concepts that we use throughout this thesis. This chapter furthermore provides an overview over the related work to identify existing research gaps.
Therefore, this chapter first explains key terms in requirements engineering. Second, we discuss the concept of quality, quality defects, and quality assurance. Third, we look into the role of quality defects in software engineering projects. Fourth, we summarize the current state in defining RE artifact quality. Lastly, based on this overview and also the overview provided in Publication G, we summarize the state of the art in QC for RE artifacts and analyze the existing research gaps.
2.1. Key Terms in Requirements Engineering
In the following, we define key requirements engineering terms and concepts and explain how we use these terms throughout this thesis. As the IREB combines various state-of-the-art views and is widely applied in industry, we base our definitions on the IREB Glossary [Gli14]. We extend the IREB view through the views of Pohl [Poh10]
or explicitly adapt them to our own view, where we consider it required for this work.
Stakeholder. The central term in requirements engineering is the stakeholder.
Extending the definition by Glinz [Gli14, p.20], we understand a stakeholder as a role, a person or an organization with a (direct or indirect) influence on a system.
This explicitly includes persons or organizations who are impacted by the system (such as members of a company’s works council) [GW07].
Requirement and Requirements Engineering Artifact. Using this definition of a stakeholder, Glinz [Gli14, p.17] defines a requirement as one of the following concepts:
1. A need perceived by a stakeholder.
2. A capability or property that a system shall have.
3. A documented representation of a need, capability or property.
2.1. Key Terms in Requirements Engineering
In order to differentiate between the need or capability itself and the documented representation thereof, we refer withrequirementto only the former two concepts and withrequirements engineering artifactorRE artifactto the last item in the previous list. This includes commonly used terms such as requirements document or requirements specification. Examples of RE artifacts are use cases [JBR99] or user stories [Coh04].
System stakeholder and RE artifact stakeholder. In RE, when discussing the stake-holder, we usually refer to the stakeholder of the system (as defined above). However, when we discuss RE quality, we must differentiate between stakeholders of the system and stakeholders of the RE artifact. Whereas the former usually refers to roles impacted by the system, the latter refers to roles (or users) that influence the RE artifact or are impacted by the RE artifact. The latter includes not only the system stakeholders (who often have to inspect, discuss and accept the RE artifact), but in addition also testers, requirements engineers, legal departments or any other person, who, due to the software engineering process applied, has to (potentially) interact with the RE artifact.
Requirements Engineering (RE). RE can be understood as an approach towards the creation of RE artifacts. Yet, depending on the viewpoint, RE can be defined with a focus on process, stakeholders, or risks:
A systematic and disciplined approach to the specification and manage-ment of requiremanage-ments with the following goals:
1. Knowing the relevant requirements, achieving a consensus among the stakeholders about these requirements, documenting them according to given standards, and managing them systematically,
2. Understanding and documenting the stakeholders’ desires and needs, 3. Specifying and managing requirements to minimize the risk of de-livering a system that does not meet the stakeholders’ desires and needs.
[Gli14, p.18]
Please note that these goals are not mutually exclusive.
Requirements Engineer. The requirements engineer is the role which organizes and executes requirements engineering activities (see next paragraph).
Requirements Engineering Activities. In order to create RE artifacts and to achieve the goals of RE, as defined before, we usually define a set of required core activities. The previous definition for RE already hints at these key activ-ities of RE, as visualized in Fig. 2.1. We extend these with other established categorizations [DAEE08, Poh10].
Elicitation: “The process of seeking, capturing and consolidating requirements from available requirements sources.” ([Gli14, p.17]) Sources in this context include not only querying or observing stakeholders (in particular users), but also analyzing existing documents, systems or prototypes, or deriving requirements from higher level goals. The elicitation activities results in a set of, potentially contradicting, not necessarily documented, requirements.
Analysis: (including negotiation): The activity of understanding requirements and their interconnection in order to create an agreement between all stakeholders one set of non-contradicting requirements for documentation. These activities
10