ISO/IEC 25030:2019

Systems and software engineering - Systems and software quality requirements and evaluation (SQuaRE) - Quality requirements framework

This document provides the framework for quality requirements for systems, software products and data, which includes concept of the quality requirements, and requirements and recommendations for the processes and methods to elicit, define, use and govern them. Intended readers of this document include, but are not limited to: - acquirers: evaluate if the system/software products/data fulfills their value proposition, i.e., meets the expected quality, - developers: design, implement and test the system/software products/data to ensure that it meets the expected quality, - testers: verify and validate that the system/software products/data meets the expected quality, - project managers: plan, monitor and control the achievement of the expected quality, and - independent evaluators: evaluate the system/software products/data with the objective criteria. This document complies with the technical processes defined in ISO/IEC/IEEE 15288, which are relevant for elicitation of stakeholders' quality needs and for defining, analyzing and maintaining quality requirements. In this document, the quality models in ISO/IEC 25010 and ISO/IEC 25012 are used to categorize quality requirements and to provide a basis for quantifying them in terms of quality measures in the quality measure division of ISO/IEC 2502n. This document does not cover specification of the other requirements (such as functional requirements, process requirements, etc.), and prescribes neither any specific quality measure nor any specific development process.

Titre manque

General Information

• Status: Published
• Publication Date: 27-Aug-2019
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7/WG 6 - Software Product and System Quality
• Current Stage: 9093 - International Standard confirmed
• Start Date: 03-Jan-2025
• Completion Date: 30-Oct-2025

Relations

• Revises: ISO/IEC 25030:2007 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Quality requirements
• Effective Date: 06-Aug-2016

Overview

ISO/IEC 25030:2019 - part of the SQuaRE (Systems and software Quality Requirements and Evaluation) family - provides a framework for quality requirements for systems, software products and data. It defines the concept of quality requirements and gives requirements and recommendations for the processes and methods used to elicit, define, use and govern those requirements. The standard is aimed at improving clarity, traceability and measurability of non‑functional requirements so stakeholders can objectively evaluate whether a system meets expected quality.

Key topics and technical requirements

• Concept and types of quality requirements: explains categories, targets and important considerations (sources, derivation, trade‑offs).
• Quality models and measures: uses the quality models from ISO/IEC 25010 and ISO/IEC 25012 to categorize requirements and provides a basis for quantification with quality measures from the ISO/IEC 2502n series.
• Processes for quality requirements: prescribes processes and steps for elicitation, definition, analysis, maintenance and governance of quality requirements, aligned with ISO/IEC/IEEE 15288 lifecycle processes.
• Traceability and governance: emphasizes traceability of quality requirements, critical success factors, and how to use requirements for planning, testing and evaluation.
• Practical guidance: includes informative annexes with recommended elicitation processes, mapping examples, specification examples, and relationships to other standards (e.g., ISO/IEC/IEEE 29148).

Note: ISO/IEC 25030:2019 does not specify functional requirements, prescribe specific quality measures, nor mandate a particular development process.

Practical applications and who uses it

ISO/IEC 25030:2019 is practical for organizations that need to make non‑functional requirements explicit and measurable:

• Acquirers and procurement teams: to write clearer requirements in contracts and evaluate vendors against objective quality criteria.
• Developers and architects: to identify architecture drivers and design for required quality attributes (security, reliability, performance, usability, etc.).
• Testers and QA: to derive test criteria and acceptance tests from quantifiable quality requirements.
• Project managers: to plan, monitor and control quality objectives and risk trade‑offs.
• Independent evaluators and auditors: to apply objective measures and evaluation modules during certification or acceptance.

Related standards (SQuaRE family)

• ISO/IEC 25010 - system and software quality models (characteristics/subcharacteristics)
• ISO/IEC 25012 - data quality model
• ISO/IEC 2502n series - quality measurement (quality measures)
• ISO/IEC/IEEE 15288 - system lifecycle processes (alignment for elicitation)
• ISO/IEC/IEEE 29148 - requirements engineering (related guidance)

Using ISO/IEC 25030:2019 helps organizations turn vague quality expectations into measurable, governable quality requirements, improving procurement outcomes, development focus and objective evaluation of system quality.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 25030
Second edition
2019-08
Systems and software engineering —
Systems and software quality
requirements and evaluation
(SQuaRE) — Quality requirements
framework
Reference number
©
ISO/IEC 2019
© ISO/IEC 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2019 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 4
5 Conformance . 5
6 Concept of quality requirements . 5
6.1 General . 5
6.2 Types of quality requirements . 5
6.3 Targets for quality requirements . 5
6.4 Quality models and measures for quality requirements . 7
6.5 Important considerations of quality requirements. 7
6.5.1 Sources of quality requirements . 7
6.5.2 Categories of ICT products . 8
6.5.3 Interrelation with functional/data requirements . 8
6.5.4 Derivation of quality requirements . 9
6.5.5 Quality requirements trade-offs . 9
7 Quality requirements processes .10
7.1 General .10
7.2 Overview of quality requirements processes .10
7.3 Elicitation of quality needs .11
7.3.1 Identification of stakeholders .11
7.3.2 Defining stakeholder needs .11
7.4 Steps for defining quality requirements .12
7.4.1 Overall description .12
7.4.2 Definition of steps .14
8 Using and governing quality requirements .16
8.1 Critical success factors for implementing quality requirements .16
8.2 Quality requirements traceability .17
8.3 Critical factors for testing quality requirements .17
Annex A (informative) Recommended process for elicitation of quality needs .18
Annex B (informative) Example for mapping quality needs to quality characteristics .24
Annex C (informative) Example for specifying quality requirements .27
Annex D (informative) Relationship to ISO/IEC/IEEE 15288 (System lifecycle processes) .28
Annex E (informative) Relationship to ISO/IEC/IEEE 29148 (Requirement engineering) .31
Annex F (informative) Derivation from quality in use requirements to product quality
requirements.35
Annex G (informative) Example of relationship between product quality characteristics .37
Annex H (informative) Example of deployment and traceability of quality requirements to
software .39
Annex I (informative) Example of stakeholder-target matrix .40
Annex J (informative) Examples of level of quality required for different ICT products(using
decision table format) .42
Annex K (informative) IT service quality requirements .45
© ISO/IEC 2019 – All rights reserved iii

Bibliography .46
iv © ISO/IEC 2019 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents) or the IEC
list of patent declarations received (see http: //patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and Systems Engineering.
This second edition cancels and replaces the first edition (ISO/IEC 25030:2007), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— extension of the view from software to system;
— enhancement and deployment of quality requirements;
— clarification of quality requirements definition steps:
— stating them exhaustively by using the quality models;
— specifying them with the quality measures with criteria for evaluation;
— clarification of how to use quality requirements.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
© ISO/IEC 2019 – All rights reserved v

Introduction
It is important to identify and specify quality requirements as part of system, software and data
requirements, because finding the right balance of quality requirements, in addition to well-specified
functional requirements, is a critical success factor to meet the stakeholders' objectives. Quality
requirements are needed for:
— specifying the system, including contractual agreements and call for tender;
— planning the project, including feasibility analysis;
— developing the system, including identification of architecture drivers or potential quality problems
during development; and
— evaluating the system, including objective assessment and certification of quality.
This document focuses on defining, using and governing quality requirements. If not clearly defined,
they can be viewed, interpreted, implemented and evaluated differently by the relevant stakeholders.
This can result in systems that are inconsistent with user expectations and of poor quality; and time
and cost overruns to rework the system. Therefore quality requirements for the system need to be
specified clearly at the earliest stage of the development or acquiring process as possible, to provide a
critical input to the development or acquisition.
This document can be used to improve the quality of quality requirements, by providing requirements
and recommendations for them, and provides guidance for the steps used to define and use them.
Quality requirements can be categorized into characteristics/subcharacteristics by using the
quality models defined in the ISO/IEC 2501n family of standards. Measures of these characteristics/
subcharacteristics, which are defined in the ISO/IEC 2502n family of standards, can be used to specify
quality requirements and evaluate the quality of the target system or data. After ISO/IEC 25030:2007
was published, several international standards which define these models and measures have been
published and so the previous edition has become inconsistent with these standards.
Furthermore many systems are now deeply embedded into social infrastructures used in daily life. This
requires the systems to achieve much higher quality; e.g., connected systems need to be interoperable
and secure, reliable, maintainable and usable.
This revision updates the quality requirements division of SQuaRE series, aligning it with the other
divisions, and furthermore providing more practical guidelines for defining and using quality
requirements.
Figure 1 illustrates the organization of the SQuaRE series representing families of standards, further
called divisions. The SQuaRE series consists of five main divisions and on extension division. The
divisions within the SQuaRE series are:
— ISO/IEC 2500n — Quality Management Division. The standards that form this division define
all common models, terms and definitions used by all other standards in the SQuaRE series. The
division also provides requirements and guidance for the planning and management of a project.
— ISO/IEC 2501n — Quality Model Division. The standards that form this division provide quality
models for system/software products, quality in use (QIU), data, and IT services. Practical guidance
on the use of the quality model is also provided.
— ISO/IEC 2502n — Quality Measurement Division. The standards that form this division include
a system/software product quality measurement reference model, definitions of quality measures,
and practical guidance for their application. This division presents internal measures of software
quality, external measures of software quality, QIU measures and data quality measures. Quality
measure elements forming foundations for the quality measures are defined and presented.
— ISO/IEC 2503n — Quality Requirements Division. The standard that forms this division helps
specifying quality requirements. These quality requirements can be used in the process of quality
vi © ISO/IEC 2019 – All rights reserved

requirements elicitation for a system/software product to be developed, designing a process for
achieving necessary quality, or as inputs for an evaluation process.
— ISO/IEC 2504n — Quality Evaluation Division. The standards that form this division provide
requirements, recommendations and guidelines for system/software product evaluation, whether
performed by independent evaluators, acquirers or developers. The support for documenting a
measure as an Evaluation Module is also presented.
ISO/IEC 25050 to ISO/IEC 25099 are reserved for SQuaRE extension International Standards, which
currently include in ISO/IEC 25051 requirements for quality of Ready to Use Software Products (RUSP)
and instructions for testing, and in ISO/IEC TR 25060 to ISO/IEC 25069 common industry format for
usability.
Figure 1 — Organization of the SQuaRE series of International Standards
© ISO/IEC 2019 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEC 25030:2019(E)
Systems and software engineering — Systems and software
quality requirements and evaluation (SQuaRE) — Quality
requirements framework
1 Scope
This document provides the framework for quality requirements for systems, software products and
data, which includes concept of the quality requirements, and requirements and recommendations for
the processes and methods to elicit, define, use and govern them. Intended readers of this document
include, but are not limited to:
— acquirers: evaluate if the system/software products/data fulfills their value proposition, i.e., meets
the expected quality,
— developers: design, implement and test the system/software products/data to ensure that it meets
the expected quality,
— testers: verify and validate that the system/software products/data meets the expected quality,
— project managers: plan, monitor and control the achievement of the expected quality, and
— independent evaluators: evaluate the system/software products/data with the objective criteria.
This document complies with the technical processes defined in ISO/IEC/IEEE 15288, which are
relevant for elicitation of stakeholders’ quality needs and for defining, analyzing and maintaining
quality requirements. In this document, the quality models in ISO/IEC 25010 and ISO/IEC 25012 are
used to categorize quality requirements and to provide a basis for quantifying them in terms of quality
measures in the quality measure division of ISO/IEC 2502n.
This document does not cover specification of the other requirements (such as functional requirements,
process requirements, etc.), and prescribes neither any specific quality measure nor any specific
development process.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 25000:2014, Systems and software engineering — Systems and software Quality Requirements
and Evaluation (SQuaRE) — Guide to SQuaRE
ISO/IEC 25010:2011, Systems and software engineering — Systems and software Quality Requirements
and Evaluation (SQuaRE) — System and software quality models
ISO/IEC 25012, Software engineering — Software product Quality Requirements and Evaluation
(SQuaRE) — Data quality model
ISO/IEC 25022, Systems and software engineering — Systems and software quality requirements and
evaluation (SQuaRE) — Measurement of quality in use
ISO/IEC 25023, Systems and software engineering — Systems and software Quality Requirements and
Evaluation (SQuaRE) — Measurement of system and software product quality
© ISO/IEC 2019 – All rights reserved 1

ISO/IEC 25024, Systems and software engineering — Systems and software Quality Requirements and
Evaluation (SQuaRE) — Measurement of data quality
ISO/IEC/IEEE 15288:2015, Systems and software engineering — System life cycle processes
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 25000 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
NOTE The essential definitions from ISO/IEC 25000 and the other ISO standards are reproduced here.
3.1
classification axis
total range of a mapping of systems and software for categorizing them from a particular perspective
[SOURCE: ISO/IEC TR 12182:2015, 3.7]
3.2
context of use
conditions and constraints under which ICT products (3.8) are used by specific users (3.20) in a specific
environment to achieve specific goals as part of the larger information system (3.10)
Note 1 to entry: Environment includes physical aspects such as equipment and resources as well as social aspects
such as demographics and culture.
3.3
deployment
deployment of requirements
assignment of requirements (3.16) along with the system decomposition
3.4
derivation
derivation of requirements
translation and elaboration of requirements (3.16) from one type of requirements to another in the
same system level
Note 1 to entry: Types of requirements include quality in use (3.13) requirements, product quality requirements
(3.15) and data requirements.
3.5
domain-based requirement
requirement (3.16) originated from its application domain
3.6
functional requirement
requirement (3.16) that specifies a function that a system or system component shall perform
[SOURCE: IEEE 730:2014, 3.2]
3.7
ICT requirement
requirement (3.16) resulting from adoption of some information and communication technologies (ICTs)
technical solutions in the design process
Note 1 to entry: ICT technical solutions include web-based technologies, cloud servers, and so on.
2 © ISO/IEC 2019 – All rights reserved

3.8
ICT product
product (3.12) which uses information and communication technologies (ICTs) and can be a part of
information system (3.10)
Note 1 to entry: Figure 3 describes what ICT product consists of and the relationship to information system.
3.9
indirect user
person who receives output from a system, but does not interact with the system
EXAMPLE Executive manager, service acquirer.
[SOURCE: ISO/IEC 25010:2011, 4.3.6, modified — EXAMPLE has been added.]
3.10
information system
system that comprises of software, hardware, communication facility, data and the people who use it in
a given environment to satisfy their information processing needs
Note 1 to entry: Figure 3 describes what information system consists of.
3.11
primary user
user (3.20) who interacts with the system to achieve the primary goals
Note 1 to entry: The definition is adapted from ISO/IEC 25010:2011, 3.6.
3.12
product
artifact that is produced, is quantifiable and is deliverable to the user (3.20) as either an end item in
itself or a component item
Note 1 to entry: This definition is adapted from A Guide to the Project Management Body of Knowledge (PMBOK)
Fifth Edition.
Note 2 to entry: Product includes ICT products (3.8), software, and software components.
3.13
quality in use
extent to which the behavioral and attitudinal outcomes and consequences of use of a product (3.12),
system or service meets the needs of users (3.20) or other stakeholders (3.18) in specific contexts of
use (3.2)
3.14
quality measure
measure that is defined as a measurement function of two or more values of quality measure elements
[SOURCE: ISO/IEC 25010:2011, 4.3.10]
3.15
quality requirement
requirement (3.16) for quality properties or attributes of an ICT product (3.8), data or service that satisfy
needs which ensue from the purpose for which that ICT product, data or service is to be used
Note 1 to entry: Quality requirements in this document do not cover quality requirements for service.
3.16
requirement
statement which translates or expresses a need and its associated constraints and conditions
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.37]
© ISO/IEC 2019 – All rights reserved 3

3.17
secondary user
user (3.20) who interacts with the product (3.12) to support the primary users (3.11)
EXAMPLE Content provider, system manager, administrator, security manager, maintainer, installer.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3651, modified — The word "person" has been replaced with
"user"; EXAMPLE has been added.]
3.18
stakeholder
individual or organization having a right, share, claim or interest in a system or in its possession of
characteristics that meet their needs and expectations
Note 1 to entry: Stakeholders include users (3.20), developers, testers, project managers, acquirers, independent
evaluators, data owners, supporters, trainers, regulatory bodies and other people influenced by the system.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.44, modified — The original EXAMPLE and Note 1 to entry
have been replaced with a new Note 1 to entry.]
3.19
technical product quality requirement
product (3.12) quality requirement (3.15) on its technically identified properties which are used in its
development and maintenance processes
3.20
user
individual or group that interacts with a system or benefits from a system during its utilization
[SOURCE: ISO/IEC 25010:2011, 4.3.16, modified — NOTE has been removed.]
3.21
validation
confirmation, through the provision of objective evidence, that the requirements (3.16) for a specific
intended use or application have been fulfilled
[SOURCE: ISO/IEC 25000:2014, 4.41, modified — Note 1 to entry has been removed.]
3.22
verification
confirmation, through the provision of objective evidence, that specified requirements (3.16) have been
fulfilled
[SOURCE: ISO/IEC 25000:2014, 4.43, modified — Note 1 to entry has been removed.]
4 Abbreviated terms
ICT information and communication technology
PQR product quality requirement
QIUR quality in use requirement
DQR data quality requirement
SRS software requirements specification
StRS stakeholder requirements specification
SyRS system requirements specification
4 © ISO/IEC 2019 – All rights reserved

5 Conformance
Any quality requirements specification that conforms to this document shall meet all the requirements
described in Clauses 6, 7 and 8.
6 Concept of quality requirements
6.1 General
This clause describes the concept of quality requirements, including their target entities for which the
quality requirements are to be defined, and important considerations on them.
6.2 Types of quality requirements
Quality in use requirements (QIURs) specify the required levels of quality from the stakeholders' point
of view. These requirements are derived from the needs of various stakeholders. QIURs relate to the
outcome when the product is used in a particular context of use, and QIURs can be used as the target for
validation of the product.
Product quality requirements (PQRs) specify levels of quality required from the viewpoint of the ICT
product. Most of them are derived from stakeholder quality requirements including QIURs, which can
be used as targets for verification and validation of the target ICT product. Technical product quality
requirements are requirements for technically identified attributes (targeting specifications, source
code, etc.) to meet the other PQRs. Technical product quality requirements can be used as targets for
verification at various stages of development and maintenance.
NOTE 1 PQRs can also be used to specify attributes of deliverable, non-executable software products such as
documentation and manuals.
The data quality requirements (DQRs) specify levels of quality required for the data associated with
the product. These include requirements derived from QIURs and PQRs of input and output products.
DQRs can be used for verification and validation from the data side.
NOTE 2 Many DQRs can be derived from PQRs for the target product, while some DQRs such as data integrity
can be derived directly from QIURs.
6.3 Targets for quality requirements
The scope of the three types of quality requirements is shown in Figure 2. QIURs are defined on the
information system, which includes not only an ICT product but also its users and relevant environments
(e.g., mechanicals monitored/controlled by the ICT product and business processes in which the ICT
product is used). PQRs are defined on the ICT product or its constituents (including sub-ICT products,
hardware, communication facilities, software and, in some cases, software components), and DQRs are
defined on the data inside the ICT product.
© ISO/IEC 2019 – All rights reserved 5

Figure 2 — Scope of quality requirements
Figure 2 describes only the scope of each type of quality requirements, not describing the system
hierarchy, which is formally defined in Figure 3.
NOTE 1 Annex K describes how IT service quality requirements are to be treated.
Figure 3 — System hierarchy used in Figure 2
NOTE 2 Users include primary users, secondary users and indirect users. See Table 2.
NOTE 3 A “system of systems” can be considered an information system, which recursively includes some
subsidiary information systems.
6 © ISO/IEC 2019 – All rights reserved

NOTE 4 An ICT product includes software, and also can include data, hardware, communication facilities, and
other ICT products as its ICT components.
6.4 Quality models and measures for quality requirements
Quality requirements are defined by using quality models and quality measures. Table 1 shows which
International Standards can be used for defining each type of quality requirements.
Table 1 — Quality models and measures for quality requirements
Quality Quality Quality
requirements model measure
ISO/IEC 25010 ISO/IEC 25022
QIURs
Quality in use model Measurement of quality in use
ISO/IEC 25023
ISO/IEC 25010
PQRs
Measurement of system and software
System and software product quality model
product quality
ISO/IEC 25012 ISO/IEC 25024
DQRs
Data quality model Measurement of data quality
ISO/IEC 25022, ISO/IEC 25023 and ISO/IEC 25024 provide a list of quality measures in a tabular form,
categorised by quality characteristics and subcharacteristics. The following information is given for
each quality measure in the tables.
ID: Identification code of the quality measure.
Name: Quality measure name.
Description: Information provided by the quality measure.
Measurement function: Mathematical formula showing how the quality measure elements
are combined to produce the quality measure.
NOTE Each quality measure listed in ISO/IEC 25022 can be used to measure effectiveness, efficiency,
satisfaction and freedom from risk in specific contexts of use. Each quality measure listed in ISO/IEC 25023 can
be used to measure internal properties (typically static measures of intermediate products), external properties
(typically by measuring the behavior of the code when executed) or both. Each quality measure listed in
ISO/IEC 25024 can be used to measure inherent or system dependent properties.
6.5 Important considerations of quality requirements
6.5.1 Sources of quality requirements
Two types of requirements for ICT products should be considered based on their sources: domain-
based requirements, which are derived directly from stakeholder needs for their domain through
requirements analysis processes, and ICT requirements, which are newly introduced by the adoption of
some ICT technical solutions through design processes. Quality requirements also have the same types.
An example of ICT requirements is as follows. Adopting a web-based system (ICT technical solution)
entails some user requirements like how to behave when clicking the back button on browsers
(functional requirement), and self-descriptiveness of its user interface (PQR: learnability), and browser
compatibility (PQR).
© ISO/IEC 2019 – All rights reserved 7

6.5.2 Categories of ICT products
Quality required for one ICT product is different from that for another, and therefore the category of the
target system is crucially important to determine which quality characteristics have higher priority
and which quality measures should be used.
ISO/IEC TR 12182 provides the framework for categorizations of ICT products, including an exemplary
set of classification axes, which are organized hierarchically with the four axes in the first layer:
Architecture/Structure, Property, Operational environment, Data, and Stakeholder of target system.
These axes can be used for determining which quality characteristics have higher priority. Classification
axes which are important for determining priority can include:
— Function (and its problem frame)
— Criticality of system and data
— Stakeholders’ characteristics
NOTE Examples of supporting IT decisions on required level of quality are shown in Annex J.
6.5.3 Interrelation with functional/data requirements
Quality requirements cannot be defined and analyzed separately from functional/data requirements.
Some quality requirements are attached to functional/data requirements; and also some quality
requirements are achieved by specifying requirements for new functions.
EXAMPLE 1 Quality requirements that are attached to functional requirements:
— Time efficiency (response time) is defined as response time for a function
EXAMPLE 2 Quality requirements that are achieved by specifying requirements for new functions:
— Some confidentiality requirements are achieved by requirements for access control function
— Some learnability requirements are achieved by requirements for help function
— Some analyzability requirements are achieved by requirements for logging function
NOTE 1 Unlike functional requirements, most quality requirements represent emergent properties of the
system, which appear on a set of components, not on a specific component. Thus it is hard to build and maintain
the traceability of quality requirements and as a result to surely implement and verify them throughout the
product lifecycle.
Product requirements cannot be defined separately from the data requirements. ICT products consume
and generate data. Quality requirements (product quality requirements or data quality requirements)
can be developed to product quality requirements and/or data quality requirements along with system
decomposition.
NOTE 2 There are three types of data from the perspective of ICT product: input and/or output data outside,
data which its components exchange and configuration data.
NOTE 3 An example of the interdependence between the ICT product and data, and the relationship between
their PQRs and DQRs is shown below:
— The configuration data file is written for the configuring the ICT product. Its DQRs (e.g., flexibility
requirements) are determined from the functions and quality requirements to be fulfilled by ICT products.
— The quality (e.g., accuracy) of customer data, which is an input to a business support system, affects the
product quality (e.g., interoperability and functional correctness) of the system.
— Data that are exchanged among software components of the ICT product, and their DQRs (e.g., efficiency)
strongly influence the method of component implementation and product quality (e.g., time efficiency) of the
ICT product.
8 © ISO/IEC 2019 – All rights reserved

6.5.4 Derivation of quality requirements
In the case of a large-scale system, it is important to grasp where the target entity of the quality
requirements is located in the system hierarchy because the quality requirements are often derived
from the higher level of entities to the lower levels.
Figure 4 describes how each type of quality requirements for entities at some level derive others.
The primary source of quality requirements is users, from whom first QIURs for the information system
including the target entities are elicited and documented. Then they evolve into PQRs and DQRs for the
target entities. Other stakeholders, such as developers and regulatory bodies, also give some quality
requirements on the target entities. Finally other entities give some requirements as constraints to the
target entities, including non-target ICT products, software and data which are connected to or used in
the targets, and hardware and communication which are used in them.
NOTE A QIUR can derive a set of functions to each of which some PQRs are attached, e.g., an efficiency
requirement of a user task can derive a function to automate some portion of the task with a time behavior
requirement. Similarly in their deployment to the lower level of targets, PQRs can also derive a set of functions to
each of which some PQRs are attached. See 6.5.3.
Figure 4 — Derivation of quality requirements
6.5.5 Quality requirements trade-offs
Quality requirements can have conflicts with one other. These conflicts inevitably arise as a result of
the inter-relationships between quality characteristics. In case that some quality characteristic can
negatively influence on another, trade-offs should be conducted to resolve the conflict to find the right
balance of them.
NOTE Examples of inter-relationship between product quality characteristics are shown in Annex G.
© ISO/IEC 2019 – All rights reserved 9

7 Quality requirements processes
7.1 General
This clause describes the requirements and recommendations for quality requirements processes on
how quality requirements are prepared, defined and analyzed.
7.2 Overview of quality requirements processes
The quality requirements shall be elicited, defined, analyzed and maintained by using the requirements-
related processes defined in ISO/IEC/IEEE 15288: stakeholder needs and requirements definition
process and system requirements definition process, through which the stakeholder needs are to be
elicited and transformed into the system requirements. See Figure 5.
NOTE 1 Both a system and a software product are regarded as an ICT product in this document.
Figure 5 — From stakeholder needs to system/software requirements
The stakeholder needs and requirements definition process identifies stakeholders, or stakeholder
classes, involved with the system throughout its life cycle, and their needs. It analyzes and transforms
these needs into a common set of stakeholder requirements that express the intended interaction the
system will have with its operational environment and that is the reference against which each resulting
operational capability is validated. Quality needs for the target system as part of stakeholder needs are
also elicited and transformed into QUIRs as part of stakeholder requirements, using the quality in use
model and measures.
The system requirements definition process creates a set of measurable system requirements
that specify, from the supplier’s perspective, what characteristics, attributes, and functional and
performance requirements the system is to possess, in order to satisfy stakeholder requirements. PQRs
and DQRs as part of system requirements are also defined and analyzed in order to meet stakeholder
requirements, using the product and data quality model and measures.
NOTE 2 The detailed relationship to ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 29148 is respectively described
in Annex D and Annex E. ISO/IEC/IEEE 29148 associates the above two requirements related processes with the
processes in ISO/IEC/IEEE 12207, which is another International Standard that defines the software lifecycle
processes.
10 © ISO/IEC 2019 – All rights reserved

NOTE 3 Iteration and recursion in requirements engineering are described in ISO/IEC/IEEE 29148. The
requirements, architecture and design processes can be iteratively applied on the same level of the system,
in order to resolve trade-offs between the requirements and architecture. These set of processes can also be
recursively applied successive levels of system elements within the system structure for successful engineering
of systems beyond trivial complexity.
NOTE 4 In general quality requirements are more stable than functional requirements over the product
lifecycle; however they can also change, e.g. security requirements need to be changed if new functionality is
added, and interoperability requirements need to be reconsidered if the environment changes even a little.
NOTE 5 As defined in ISO/IEC/IEEE 29148, the stakeholder requirements can be documented in the
stakeholder requirements specification (StRS), and the system and software requirements can be documented
respectively in the system requirements specification (SyRS) and the software requirements specification (SRS).
7.3 Elicitation of quality needs
7.3.1 Identification of stakeholders
This subclause relates to the identification of stakeholders in the activities of “(a) Prepare for
stakeholder needs and requirements definition” for Stakeholder needs and requirements definition
process in ISO/IEC/IEEE 15288 (See Annex D).
The representatives from all groups of the stakeholders who are a potential source of the quality
requirements shall be identified and, if available, involved for eliciting them. Table 2 describes which
type of stakeholders is a source of, a user of and relevant to which type of quality requirements.
Table 2 — Stakeholders and types of quality requirements
Stakeholder
User Other stakeholder
Quality requirement
Acquirer/
Primary Secondary Indirect
Developer Independent Society
user user user
evaluator
QIUR S S S U U R
S S U U
PQR
Technical S, U U
DQR S S S S, U U
Key
S: a source of
U: a user of
R: relevant to
The users of quality requirements (developer, acquirer/independent evaluator etc.) have a responsibility
for establishing and maintaining the quality requirements, and so they should consider freedom of risks
requirements relevant to society, who is a group of persons (who are supposed to be) influenced by the
system, who cannot directly be a source of requirements.
NOTE Stakeholder can be considered as a role, and so one person or organization can have more than one
role. Moreover a stakeholder is not supposed to belong to a specific kind of organization. For example, in the case
of developing consumer products, acquirers and developers can belong to the same company to consider any
risks on people influenced by the system.
7.3.2 Defining stakeholder needs
This subclause relates to the activities of “(b) Define stakeholder needs” for Stakeholder needs and
requirements definition process in ISO/IEC/IEEE 15288 (See Annex D).
© ISO/IEC 2019 – All rights reserved 11

The assumed context of use for the target information system and the quality needs in the context of
use shall be extracted from the identified stakeholders. If there is an existing system, they shall also be
extracted from analyzing feedback on the experience with using the system from the stakeholders.
NOTE 1 Annex A provides a recommended process for elicitation of quality needs.
NOTE 2 Quality needs in this case mainly relate to quality in use.
NOTE 3 Stakeholder needs include not only those stated explicitly but also those implicit or unrecognized. To
elicit relevant stakeholder needs in a particular context of use exhaustively, the stakeholder-target matrix can be
used, shown in Annex I.
The elicited stakeholders’ quality needs shall be prioritized and be selected based on it, where
the categories of the ICT product (6.5.2) should be taken into account to determine which quality
characteristics are important to the target entity.
NOTE 4 Since different stakeholders have different needs for the target system, the stakeholder needs can be
inconsistent and/or incomplete; therefore all the prepared needs are examined to define, analyze and maintain a
set of stakeholders’ requirements.
NOTE 5 Not all stakeholder needs can be sel
...