4. Summary of Results 41
4.3. RQ 3: How Can We Efficiently Ensure Quality Factors?
4.3.2. Summary of Approach: Requirements Smells
In the previous study, we argue that two of the main challenges of RE artifact QC today is that manual QA is inefficient and slow. We furthermore motivate to combine manual with automatic QA to ensure certain quality factors already during the time of writing, similar to a spell-checker. In the following, we explain the concept of requirements smells and give a taxonomy of requirements smells.
This section is based on Publications F and G, and extends them through the relation to ABRE-QM and a taxonomy of requirements smells.
4.3.2.1. Defining Requirements Smells
A requirements smell is an indicator of a quality violation, which may lead to a defect, with a concrete indication and a concrete detection mechanism.
In detail, we consider a requirements smell as having the following characteristics:
1. A requirements smell is anindicatorfor a quality violation of a RE artifact. For this definition, we understand requirements quality in terms of quality-in-use, meaning that bad RE artifact quality is defined by its (potential) negative effects on activities in the software lifecycle that rely on these RE artifacts.
56
4. Summary of Results 2. A requirements smell doesnot necessarily lead to a defect and, thus, has to be judged by the context (supported e.g. by (counter-/)indications). Whether a requirements smell is or is not a problem in a certain context must be individually decided for that context and is subject to reviews and other follow-up quality assurance activities.
3. A requirements smell has aconcrete indication (symptoms) in an entity of the RE artifact itself, e.g. a word or a sentence. Requirements smells always provide a pointer to a certain location that QA must inspect. In this regard, it differs from general quality characteristics, e.g. completeness, that only provide abstract criteria.
4. A requirements smell has aconcrete detection mechanism5. Due to its concrete nature, requirements smells offer techniques for detection of the smells. These techniques can, of course, be more or less accurate.
Furthermore, we define aquality defect as a concrete instance or manifestation of a quality violation in the artifact, in contrast to a finding as instances of a smell.
However, like a requirements smell indicates for a quality violation, the finding indicates for a defect. Fig. 4.7 visualizes the relation of these terms as well as the given definition of requirements smells.
Instance Level
indicates for
Location located at Finding Quality Defect
Requirements Smells Definition
Quality Problem indicates for
Scope present in Smell
instance of instance of
detects Smell Detector evaluated by Activity-based
RE Artifact Quality Model (ABRE-QM)
Artifact
Entity Quality Factor
Stakeholder Role
Activity
Impact performs
impacts is present
contains
contains
instance of
instance of
Figure 4.7.:This figure shows terminology of requirements smells. In this terminology, we define requirements smells as specific quality factors of ABRE-QMs.
5 An instance of anAssessment in the terms of ABRE-QM in RQ 1.
4.3. RQ 3: How Can We Efficiently Ensure Quality Factors?
In the following, we focus on natural language requirements smells, since, as we discussed in the introduction, requirements are mostly written in natural lan-guage [MFNI04]. Furthermore, as motivated by our study in Publication H, the best benefits of requirements smell detection come with automation. Therefore, the remainder of the thesis discusses requirements smells where the detection mechanism can be executed automatically (i.e. it requires no manual creation of intermediate or supporting artifacts).
4.3.2.2. Defining a Requirements Smell Taxonomy
Various natural language requirements smells exist (see the appendix to Publication G for an overview). In the following, we present a classification of these smells according to their scope (see Fig. 4.7). This classification allows to understand which types of requirements smells exist.
As defined above, each smell has a detection mechanism, is indicator for a quality problem, and has a scope on which a requirements smell can potentially exist. In each scope, different quality problems exist, and for each scope, different detection mechanisms are required. In the following, we detail these scopes, before explaining our requirements smell taxonomy.
Scopes for Requirements Smells Entities, as defined in the ABRE-QM, can be broken down deeper than just the level of artifact model (e.g. use case documents, use case steps, etc.) but also into what we call thelanguage model. The language model reflects the state of the art natural language processing and includes information on sentence boundaries and other grammatical features, such as the parse tree [JM14, SK13] or Part-of-Speech (POS) tags [JM14, GE09, HEZ15]. An excerpt of such a resulting model, including the language model, is depicted in Fig. 4.8. In this figure, we can see the artifact model with entities on top, where each element that is built on natural language text, e.g. Step is aTextItem containing one or more text chunks. These text chunks are broken down into its grammatical features.
The features included in this language model represent the grammatical features of state-of-the-art NLP (based on the popular collection of NLP methods Stanford Core NLP [MSB+14] and DKPro [dCG14]) and might grow with research progressing in NLP.
Requirements Smell Types Based on the scopes provided above and the definition by Berry et al. [BBG+06], we suggest the following classes of requirements smells.
Structural Smells refer to smells within the artifact model. These can be of either of three typical types:
1. {min,max} Number of content items, e.g. a use case must have between 5 and 9 steps. This includes also the presence or absence of content items.
2. Naming conventions: E.g. that all use cases are two-digits, numbered and preceeded by a project abbreviation.
3. Coordination of elements, i.e. each element at a certain location must have an identical element at another location. One example is the factor that each referenced step in a flow must be defined elsewhere.
Grammatical Smells refer to smells that have a grammatical feature as the scope6. Grammatical smells are mostly in the form of counting of a grammatical
6 This is strongly related to the class of syntactic manifestations of Berry et al. [BBG+06].
Berry refers to the meaning of syntax as defined by Chomsky [Cho57]. However, we consider grammatical smells a more fitting category, due to the different meanings of syntax in the linguistic and computer science world: In computer science, every automatic requirements smell
58
4. Summary of Results
Sentence Requirement
Use Case User Story
Role Feature Reason
ID Text
ID State Precondition Postcondition
Basic Flow
Alternative Fl.
...
Flow
Step entry point
exit point
Artifact ModelLanguage Model
Chunk
TextUnit
Constituent Syntactic Label Sentiment
references parts
Word Part-of-Speech Lemma Stem Flexion Word Sense Named-entity-t.
Semantic Role Spelling Correct Grammar Corr.
compounds Text Item
Figure 4.8.:This figure visualizes a detailed view on the entities of an ABRE-QM in the context of requirements smells. It shows the interplay between artifact model on the top and language model on the bottom. For simplicity, we omitted relations between textual entities of the artifact model and their parent classText Item.
4.3. RQ 3: How Can We Efficiently Ensure Quality Factors?
feature (e.g. number of subclauses), including the presence of absence of a grammatical feature (such as superlatives or passive voice).
Lexical Smells refer to smells where a word or phrase in itself is problematic in RE artifacts, e.g. due to ambiguity. Lexical smells are mostly in the form of presence or absence of certain combinations of words.
Semantic Smells are those smells that aim at detecting problems in the content that is described. For example, the smell UI Design Elements in Use Cases is able (based on word lists) to understand that a use cases probably describes something that is considered a problem in maintenance (see also Section 4.2.3.2 and Publication C for further details on this quality factor). Since the semantics can only be detected automatically if it is reduced to syntactic features, semantic smells must be broken down into syntax (such as the other smells) to automatically detect findings.
Please note, that these are the basic types of requirements smells. The concrete smells often form a mixture of these elements, e.g. the naming convention requires that the use case starts with a verb, and thus needs some grammatical information.
This smell definition allows to classify different types of requirements smells. Further-more, this taxonomy might allow future work to define requirements smell detection languages, as well as false positive filters for each type of requirements smell.