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?
Quality requirements are also subject to myths. Therefore, it is important to examine the different types of requirements closely.
Three types of requirements can be distinguished:
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.
Furthermore, we differentiate subtypes of assurance requirements:
- Technical assurances These are requirements that define the technical specifications for implementation, e.g., the programming language or processor. Example of a technical specification:
The software for the fully automatic coffee machine must be modeled using UML (Unified Modeling Language). - Project-related assurances These are requirements that relate to the entire project, e.g. compliance with valid standards, costs (for development, production) and data that are reflected in the project plans.
- Delivery-related assurances These are requirements relating to system delivery, e.g. scope of delivery, delivery variants, delivery times, delivery quantities and transport.
- Legal and contractual assurances These are requirements that affect 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 These are requirements regarding the development process (methodology), e.g., whether the development must be based on the V-Model XT.
Non-functional requirements The above classification reduces them to quality characteristics. Quality features differentiate themselves 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 factors (e.g., reusability) are not always clear. In this case, it is not entirely clear what needs to be done during implementation to achieve reusability in the software; reusability cannot be tested "just like that".
➔ abstract quality characteristic
This Awareness and understanding The 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
- Differentiating between product and process quality – both influence each other.
- Distinguishing between internal (developer perspective) and external quality (customer perspective)
- Quality cannot be "tested in" later.
- Quality characteristics must be defined before development begins.
- Some quality characteristics and their implementation measures support each other; for example, modifiability and reusability have a positive influence on each other.
- Some quality characteristics and their implementation measures are contradictory; for example, performance and reliability negatively influence each other.
Guideline: Select four out of six quality characteristics for implementation.
Let's consider an example application and its implementation: Can you create a Formula 1 racing car that is suitable as a three-liter car and for container transport?
Relevant standards
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
Figure 1: Exemplary overview of quality and sub-quality characteristics
Please always observe the standards applicable to your industry and products.
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 2 of the article Regarding quality requirements, it provides an overview of which method for capturing quality requirements is best suited to your project.
In Part 3 Our author guides us through the most important steps of capturing quality requirements using an example.
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
