EN 
DE 
Capturing and managing requirements is a key to project success. Embedded software functionality is easier to describe in requirements than quality attributes. However, quality attributes cannot simply be "tested in" at the end. The more abstract they are, the more complex and time-consuming they are to define. What challenges does this pose for a project?
In an example, our author guides the reader through the most important steps of capturing quality requirements.
Figure 4: Defining an (abstract) quality characteristic
The quality characteristic "changeable" is applied in this example to the software of a fully automatic coffee machine, but can be transferred to any product.
Referring to image 1 (Part 1 of the articleThe sub-quality characteristics of analyzability, modifiability, stability and testability apply to the quality characteristic of changeability.
For each quality characteristic, the requirements analyst formulates introductory questions:
Changeability
What key performance indicators define changeability in software?
For each sub-quality characteristic, the requirements analyst formulates further questions:
Analyzability
What key performance indicators define analyzability in software?
Modifiability
What key parameters define modifiability in software?
stability
What key performance indicators define software stability?
Verifiability
What key performance indicators define testability in software?
Figure 5-1: Define Quantization 1 (Reference part for product): Software metrics
The following example is based on the publication by DSF Deutsche Flugsicherung GmbH and Brandenburg University of Technology Cottbus: „Pieper: Definition of software quality characteristics“ and „Bennicke, Dörr: New Metric Application“.
The metrics shown above are an example of an extract from the reference database for the quality characteristic of modifiability. These metrics and threshold values can be used to quantify the sub-quality characteristics of analyzability, modifiability, stability, and testability.
Figure 5-2: Defining Quantization 1 (Reference part for product): Assignment and weighting
After determining the metrics, these must be assigned to the sub-characteristics:
Analyzability = a + b + c + …
Modifiability = a + b + c + …
Stability = a + b + c + …
Testability = a + b + c + …
After assigning the metrics, they must be weighted:
Analyzability = a * x + b * x + c * x + …
Modifiability = a * x + b * x + c * x + …
Stability = a * x + b * x + c * x + …
Testability = a * x + b * x + c * x + …
The sum of all weighting factors for each sub-quality characteristic must equal 100.
When calculating modifiability, a metric is scored as "1" if the measured value lies within the specified range. If the range is not met, the metric is scored as "0".
For the specific system, the value ranges of the individual metrics and their weighting are adjusted in the regulation section.
Figure 5-3: Define Quantization 1 (reference part for product): Rating scheme for each (sub-) quality characteristic
In the reference section, the quantization in [degree of fulfillment] is defined based on the calculable results. For the sub-quality characteristic, the meaning of the quantization is unambiguous.
Definition: For a quality characteristic, the degree of fulfillment must be transferred to each sub-quality characteristic. Therefore, if a fulfillment level of 4 is required at the quality characteristic level, then all sub-quality characteristics must also meet this level.
Figure 6-1: Define Quantization 2 (control section for project): Define value ranges of the software metrics
The regulatory section involves the project-specific adjustment of the value ranges of the metrics.
Figure 6-2: Defining Quantization 2 (Control section for project): Weighting of software metrics
The regulatory section involves the project-specific adjustment of the weighting of the metrics for each quality characteristic.
Figure 6-3: Define Quantization 2 (control section for project): Quantization
In this example, the degree of fulfillment for all sub-quality characteristics and the quality characteristic are identical.
Figure 7: Capturing a specific requirement with a test case
Based on these specific software requirements, the software developer knows which metrics to consider during implementation. The software tester can determine these metrics and thus verify whether a maintainability score of at least 2 has been achieved.
In the requirements document and the test case, the term "changeable" is linked to the reference and control section in the database.
Conclusion
Create awareness and understanding of quality requirements among your employees in your company.
Even though the initial effort required to quantify abstract quality characteristics into concrete ones is high – you will benefit from it in all subsequent projects!
Everything about requirements engineering and quality requirements
Get in MicroConsult Seminar on Requirements Engineering and Management The necessary knowledge to develop and document high-quality requirements and corresponding acceptance criteria. The recently revised version of the seminar is based on over 10 years of practical coaching and seminar experience.
Learn more in seminar, how to assess and improve the quality of existing requirements, how to introduce, evaluate, optimize, understand and implement a requirements process in your company, and how to make informed tool decisions for managing requirements.
Part 1 of the article The section on quality requirements highlights the different types of requirements.
In Part 2 provides an overview of the different methods for recording quality requirements.
Further information
MicroConsult expertise in project management
MicroConsult Training & Coaching on the topic of project management
Training: Requirements Engineering and Requirements Management
Other relevant MicroConsult training courses on this topic:
Functional safety (Fusi) of electronics and their software according to IEC 61508 and ISO 26262
Security foundations for embedded systems
Model-based systems analysis and system design using the Systems Modeling Language
