EN 
DE The art of watertight quality requirements
Author: Thomas Batt, MicroConsult GmbH
Contribution – Embedded Software Engineering Congress 2018
Capturing and managing requirements is a key to project success. Describing embedded software functionality in requirements is simpler than defining quality attributes. Nevertheless, quality attributes must be captured because they cannot be tested to achieve the desired functionality. The more abstract the quality attributes, the more complex and time-consuming their capture becomes. This article addresses precisely this challenge.
Quality requirements and their myths
Requirements can be divided into functional requirements, assurances as requirements, and non-functional requirements.
Functional requirements
Functional requirements describe the externally visible functionalities of the embedded software. Example of a functional requirement:
The software of the fully automatic coffee machine must be able to update itself.
Assurances as requirements
Constraints are general, global assurances that apply to the product and/or product development. Project constraints also fall under the category of constraints.
Subtypes of assurance requirements:
- Technical assurances
Technical assurances are requirements that define technical specifications for implementation, e.g., determining the programming language or the processor. - Project-related assurances
Project-related commitments are requirements that relate to the entire project, e.g., compliance with valid standards, costs (for development, production) and data, which are reflected in the project plans. - Delivery-related assurances
Delivery-related assurances are requirements that relate to the system delivery, e.g. scope of delivery, delivery variants, delivery times and delivery quantities. - Legal and contractual assurances
Legal and contractual assurances are requirements that relate to the execution of the development, e.g., costs, completion date, payment milestones, penalties, handling of new requirements, handling of requirement changes, and escalation paths. - Process-related assurances
Process-related assurances are requirements regarding the development process (methodology model), e.g., the development must be carried out based on the V-Model XT.
Example of a technical assurance as a requirement:
The software for the fully automatic coffee machine must be modeled using UML (Unified Modeling Language).
Non-functional requirements
This classification reduces the non-functional requirements to quality characteristics. Quality features They can be differentiated into:
- Quality features which a functionality Describe the requirement in more detail using a functional requirement (e.g., a time consumption). In this case, it is clear what needs to be done during implementation to ensure the time consumption is met. The time consumption can be easily tested, provided a concrete time value, consisting of a value and unit, is specified in the quality requirement.
> specific quality feature
- Quality characteristics which are important for the all software Relevant aspects (e.g., reusability) are not entirely clear in this case; reusability is not "simply" testable.
>abstract quality characteristic
This awareness and understanding of quality requirements should be present in all employees from the company's sales, marketing, product management, project management, development, testing and production departments.
Facts about quality
- Distinction: Product and process quality – both influence each other
- Distinction: Internal (developer perspective) and external quality (customer perspective)
- Quality cannot be tested in later.
- Quality characteristics must be defined before development begins.
- Some quality features support each other; for example, modifiability and reusability have a positive influence on each other.
- Some quality characteristics are contradictory; for example, performance and reliability negatively affect each other.
- Guideline: Select four out of six quality characteristics for implementation.
Can you create a Formula 1 race car that is suitable as a three-liter car and for container transport?
The following exist regarding software quality characteristics, their specification and testing. Standards:
- ISO/IEC 9126-1:2001 Software Engineering – Product Quality – Part 1: Quality Model
This standard has been superseded by:
- ISO/IEC 25010:2011 Systems and Software Engineering – Systems and Software Quality Requirements and Evaluation (SQuaRE) – System and Software Quality Models
See image 1 (PDF): Exemplary overview of quality and sub-quality characteristics
Please always observe the standards applicable to your industry and products.
Method for recording quality requirements
See image 2-1 (PDF): Method for recording quality requirements (Part 1)
Define an abstract quality characteristic:
The requirements analyst formulates a description for each quality characteristic. Exploratory questions and further questions for each sub-quality characteristic. This initially results in abstract requirements. The analyst can then check the database to see if the quality characteristic has already been quantified. If so, the requirements analyst can directly formulate the concrete requirement.
Is the quality characteristic already recorded in the database?
If the quality characteristic has already been specified in previous products, the requirements analyst can directly formulate the specific requirement and the test team the specific test case.
Set quantization 1 (reference part for product):
The requirements analyst, together with subject matter experts, develops a quantization scheme for the quality characteristic.
Derive criteria for implementation:
The quantization scheme provides criteria and facts for implementing the requirement.
See image 2-2 (PDF): Method for recording quality requirements (Part 2)
Derive criteria for the test:
The quantization scheme provides criteria and facts for verifying the requirement.
Define quantization 2 (control section) for project:
Many quantization schemes allow the requirements analyst to adapt values and/or relationships to specific projects.
Preservation for reuse:
The requirements analyst enters newly developed quantization schemes for quality characteristics into the database for reuse.
Define specific requirements with a test case:
Based on the existing abstract requirement, together with the quantization scheme for the quality characteristic under consideration, the requirements analyst defines an implementable and verifiable requirement. The test team then derives the appropriate test case from this requirement.
See image 3 (PDF): Database structure for quality requirements
The reference database should be kept as generic as possible so that it can meet the constantly growing and ever-changing requirements from theory and practice.
General section:
- Valid and to be taken into account when collecting all quality characteristics
- General and cross-feature information and notes
- Technical contacts
- Further reading and internal link references
Reference example:
Reference examples are created for the solutions contained in the database. Each reference example includes a reference section and a control section.
Reference section:
The reference section includes key figures and possible value ranges for calculating the corresponding sub-characteristics.
Regulation section:
The regulatory section describes the solution path to the specific solution using examples. The specific requirement for the corresponding feature may be stated at the end of the regulatory section.
Example of data collection
See image 4 (PDF): Define (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 Figure 1, the sub-quality characteristics of analyzability, modifiability, stability and testability apply to the quality characteristic of changeability.
The requirements analyst formulates a description for each quality characteristic. Exploratory questions:
Changeability
Do you want to define key performance indicators (KPIs) for the characteristics that relate to the effort required to implement specified changes to the system under development?
The requirements analyst formulates a definition for each sub-quality characteristic. Further questions:
Analyzability
Do you want to define key performance indicators (KPIs) for the characteristics that relate to the effort required to diagnose defects or causes of failure in the system to be built, or to determine parts that require modification?
Modifiability
Do you want to define key performance indicators (KPIs) for the characteristics that relate to the effort required to implement improvements, correct errors, or adapt to environmental changes?
stability
Do you want to define key performance indicators for the characteristics that relate to the effort required to test the changed hardware/software/...?
Verifiability
Do you want to define key performance indicators for the characteristics that relate to the effort required to test the changed hardware/software/...?.
See image 5-1 (PDF): Set Quantization 1 (reference part for product): Software metrics
The following example is based on a 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. Changeability. The metrics and threshold values can be used to determine the sub-quality characteristics. Analyzability, modifiability, stability and Verifiability be used.
See image 5-2 (PDF): Define Quantization 1 (reference part for product): Assignment and weighting
After determining the Metrics must these correspond to the sub-characteristics assigned become:
| Analyzability = | a + b + c + … |
| Modifiability = | a + b + c + … |
| Stability = | a + b + c + … |
| Verifiability = | a + b + c + … |
After assigning the Metrics must these weighted become:
| Analyzability = | a * x + b * x + c * x + … |
| Modifiability = | a * x + b * x + c * x + … |
| Stability = | a * x + b * x + c * x + … |
| Verifiability = | 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.
See image 5-3 (PDF): Define Quantization 1 (reference section for product): Rating scheme for each (sub-)quality characteristic
The reference section is based on the calculable results. Quantization in [degree of fulfillment]. At Sub-quality characteristic The meaning of quantization is clear. Definition: In Quality feature The degree of fulfillment must be applied 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.
See Figure 6-1 (PDF): Define Quantization 2 (control section for project): Define value ranges for the software metrics
The regulatory section contains the project-specific details. Adjustment the Value ranges the Metrics.
See Figure 6-2 (PDF): Define Quantization 2 (control section for project): Weighting of software metrics
The regulatory section contains the project-specific details. Adjustment the Weighting the metrics for each quality characteristic.
See Figure 6-3 (PDF): Define Quantization 2 (control section for project): Quantization
In this example, the degree of fulfillment is identical for all sub-quality characteristics and the quality characteristic.
See image 7 (PDF): Capture specific requirements with test cases
Based on these specific software requirements, the software developer knows which metrics to consider and how to apply them 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 and test case, the term "changeable" is linked to the reference and control section in the database.
Summary
Create awareness and understanding of quality requirements among your employees in your company.
The initial effort required to quantify abstract quality characteristics into concrete ones is high. However, you will benefit from this in all subsequent projects.
Referenced and further links
[1] MicroConsult Download for this article – complete and up-to-date
[2] MicroConsult Download: Requirements – A checklist for maturity
[3] MicroConsult Trainings:
Requirements engineering and management for embedded systems
Functional safety (safety) of electronics and their software
Security: Security of embedded systems in the context of functional safety
Usability Practical Seminar: Developing User-Friendly Products
SysML: Model-based systems analysis and design using the Systems Modeling Language
[4] Technical literature: Requirements Engineering and Management, SOPHIST GmbH, HANSER Verlag
Print ISBN: 978-3-446-43893-4, E-Book ISBN: 978-3-446-44313-6, https://www.hanser-fachbuch.de
author
Dipl.-Ing. (FH) Thomas Batt Thomas Batt is a native of Freiburg. After training as a radio and television technician, he studied communications engineering in Offenburg. Since 1994, he has worked continuously in various industries and roles in the field of embedded/real-time systems development. In 1999, Thomas Batt joined MicroConsult GmbH. There, as a certified trainer and coach, he is currently responsible for systems/software engineering for embedded/real-time systems, as well as development process consulting.
Contact
Internet: www.web-dev-weissblau.de
E-mail: t.batt@microconsult.com
Requirements – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of requirements/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Requirements – Expertise
Valuable expertise in the field of requirements/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
