4. Summary of Results 41
4.1.1. Summary of Approach: ABRE-QMs
To precisely define RE artifact quality, we designed activity-based RE artifact quality models (ABRE-QMs). In the following, we describe the concepts behind ABRE-QMs, before reporting our experiences on validation of ABRE-QMs in the next research question (Section 4.2).
4.1. RQ 1: How Can We Precisely Define Quality for RE Artifacts?
4.1.1.1. ABRE-QM Meta Model
ABRE-QMs are based on a quality-in-use paradigm in RE: We postulate that creating an RE artifact is rarely an end in itself, but just a means to understand and reach the project’s goals. Following this line of thought, the purpose of the requirements artifact is to support the stakeholders in the activities they are performing in the project1.
To describe the structure of ABRE-QMs, we provide an ABRE-QM meta model that introduces the concepts needed to describe an ABRE-QM. The ABRE-QM meta model adapts and extends the QUAMOCO meta model [DJLW09, Dei09, WLH+12].
The QUAMOCO meta model is used to explicitly define quality-in-use characteristics of source code, such as maintainability [DWP+07, Loc13]. We simplify, but also extend the meta model to adapt it to RE artifact quality.
Artifact
Entity
Quality Factor Stakeholder
Role
Activity
Impact performs
impacts
is present contains
contains
Context Factor
Assessment
influenced by
evaluated by
includes generic role
consists of
Figure 4.1.:This figure shows the ABRE-QM meta model. The model consists of artifacts and their decomposition into entities, quality factors and their impact onto activities, which are performed by certain stakeholder roles. Impacts are influenced by context factors. Lastly, quality factors are evaluated by assessments.
ABRE-QMs define quality as an instance of the following elements (see Figure 4.1):
An artifact is a documented collection of requirements entities, which is produced during an RE process. An example for an artifact is ause case document. An entity is a coherent documented information. An entity can be a content
item [MPKB10], but can also be further decomposed, e.g. into the linguistic components of such a content item (see Section 4.3.2.2 for an instance of such a decomposition). Examples for entities are ause case, analternative flow
or astep within the flow.
A stakeholder role is the role of someone with an interest in the RE artifact [Poh10], such as the tester. Each role can include more generic roles. For example, both
1 Obviously, some projects exist, in which only a certain RE artifact is created and therefore the requirements artifact itself is the project goal. However, even in these cases there is a larger goal for which the RE artifact is just a means. The project is just scoped in a manner that this higher goal is outside of the project scope. In the following, we assume that this is not the case.
42
4. Summary of Results
test engineers anddevelopersare also readers of the requirements artifact.
Therefore, quality factors that affect the activityreadoderunderstand, affect allreaders of the artifact, includingtest engineers anddevelopersthrough their included generic rolereader. This allows combining shared activities that multiple stakeholders must execute.
An activity is an invested effort, which involves one or more of the aforementioned artifacts, such as creating test cases, and one or more of the aforementioned stakeholder roles, such as the test engineer. An activity can be broken down into subactivities. For example, the testing activity is decomposed into
creating, running,andmaintainingtest cases.
A quality factor is a property that is or is not present in an entity. This property must be objectively assessable through a measure to be used for quality control2. Depending on the abstraction level of the referred entity, we can differentiate five types of quality factors (extending the definition of Berry et al. [BBG+06], see also Section 4.3.2.2 for more details):
• Domain-semantic are quality factors that define properties of the system with reference to the domain (outside the specification). Examples for this quality factors are in the direction ofvalidity or feasibility, such as the quality factor whetheruse caseshavebusiness-valueor also whether anRE artifactcontainscontradictions between the described system and the domain.
• Language-semantic are quality factors that define properties of the system as it is described. One example is a quality factor whether anRE artifact
contains contradictions within the text.
• Structural-syntactic are quality factors that describe properties of syntac-tic relations within the artifact and content model. Examples here are fields to be filled out (under certain conditions) or required and forbidden references between parts of the content model.
• Grammatical-syntactic are quality factors that describe properties of the grammar of a description. A well-known example for this quality factor ispassive voice.
• Lexical-syntactic are quality factors that describe properties of one or more single elements of the language, such as words or phrases not to be used in the RE artifact.
However, these boundaries are often fuzzy as quality factors can refer to multiple levels. An example for this is a grammatical ambiguity that hints at an semantic incompleteness. As such, a passive voice requirement (as a grammatical-syntactic quality factor) might imply that we do not know yet who is performing a certain action in the system (a language or even domain semantic quality factor).
An impact is an explicit relation between a quality factor and an activity. The impact influences either effectiveness or efficiency of that activity. This impact is explicitly discussed through: First, a reason, i.e. an argumentation why the presence of a specified characteristic (the quality factor) of an artifact impacts the associated activity; second, consequences on costs, schedule or quality of the developed system; and third, a source from which this impact was derived and which can provide further information, i.e. a requirements quality standard or corporate guidelines.
2 Please note, that for this notion, continuous properties must be transformed into binary values.
E.g. in order to use continuous properites such asbusiness value, we have to transform the factor into a binary factor, such asbusiness value is higher than expected effort.
4.1. RQ 1: How Can We Precisely Define Quality for RE Artifacts?
A context factor influences the impact of a quality factor. For example, the problem-atic impact of apassive voicerequirement varies, depending on the background of the reader. If the reader has no or few domain knowledge, the passive voice has a stronger impact. In contrast, in cases where the reader is well aware of the domain and the ideas of the system, the impact can be less problem-atic. Please note that the usage context is already partly represented through stakeholder roles and activities. These context factors can be understood as an extension of this usage context onto individual quality factors. Context factors are of the following types:
• Human and team context factors refer to the knowledge or situation of an individual stakeholder or a team of stakeholders.
• Process context factors refer to the process within which the activities are conducted.
• Tool context factors refer to the tooling through which’s means the stakeholder role uses an RE artifact.
An assessment is a description for evaluating an entity against a quality factor. The application of a assessment against an entity (analogue to Deissenboeck [Dei09]) results in a (potentially empty) set of quality defects. Just as Deissenboeck describes, we see three potential categories of assessments: manual, automatic, and semi-automatic assessments.
4.1.1.2. Exemplary Quality Factor: Explicit Steps in Use Cases
To foster understanding, this section provides an exemplary excerpt of an ABRE-QM (see Fig. 4.2). The example shows the definition of one quality factor, which are the
presence of explicit steps in a use case flow.
1. Artifacts and entities: Ause case document(e.g. [Coc98]) is a common artifact for specifying functional requirements to software systems. A use case document contains one or multiple use cases, which usually contain a basic flow, which is a sequence of steps that describes how the user interacts with the system.
2. Stakeholder roles: For the sake of simplicity, in this example, we consider only
test engineers.
3. Activities: When we analyze how a test engineer processes the use case document in a specific project, we find out that among other activities the test engineers goes through the use case steps and creates test step(s)for the use case’s basic flow.
4. Quality factors: It is considered good practice in use cases toexplicitly separate
each step instead of describing the whole basic flow in one text block. With the aforementioned context and activity in mind, we understand why a use case with this quality factor is considered higher quality: The test engineer can directly translate the use case steps to test steps. Therefore, the test engineer’s task of creating a test sequence can be executed more effectively (and maybe also more efficiently) when the factor is present in the use case. Fig. 4.2 explicates this reasoning through a positive (’+’) impact in an ABRE-QM.
Please note, that for simplicity, we only discuss one of the impacts of this quality factor here.
5. Context factors: One could consider the applied tool to be a context factors. De-pending on the concrete tool in use, the translation is more or less efficient.
6. Assessment: One could discuss various types of assessments, depending on the tool used. A easy-to-apply assessment is a manual review, which can spot this quality defect. In addition, for various requirements management tools,
44
4. Summary of Results
Use Case Document
Basic Flow
Step is explicitly
separated Test Engineer
(T.E.)
Create Test Steps
Rationale: T.E. can translate steps
+ performs
impacts
is present contains
contains
Tool-Features
Manual Review
influenced by
evaluated by Use Case
contains
Figure 4.2.:This figure shows a simple example excerpt of a quality factor in an ABRE-QM.
The excerpt discusses why explicitly separated steps in basic flows of use cases are considered good quality. In this example, we discuss the impact onto creating test steps, i.e. explicitly separated steps in basic flows allow more efficient and effective creation of test steps through reuse.
one could discuss automatic (or at least semi-automatic) methods through automatic analysis of the use case’s structure.
This example shows the definition of one quality factor. An ABRE-QM is a com-position of a set of such quality factors with their respective relations. RE artifact quality is thus defined through an ABRE-QM.