ISO/IEC 25030:2007

INTERNATIONAL ISO/IEC
STANDARD 25030
First edition
2007-06-01
Software engineering — Software product
Quality Requirements and Evaluation
(SQuaRE) — Quality requirements
Ingénierie du logiciel — Exigences de qualité et évaluation du produit
logiciel (SQuaRE) — Exigences de qualité

Reference number
©
ISO/IEC 2007
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2007
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2007 – All rights reserved

Contents Page
Foreword. v
Introduction . vi

1 Scope . 1
2 Conformance .1
3 Normative references. 1
4 Terms and definitions . 2
5 Fundamental concepts for quality requirements. 2
5.1 Software and systems. 2
5.2 Stakeholders and stakeholder requirements .3
5.3 Stakeholder requirements and system requirements . 4
5.4 Software quality model . 5
5.5 Software properties. 7
5.6 Software quality measurement model . 7
5.7 Software quality requirements . 8
5.8 System requirements categorisation. 9
5.9 Quality requirements life cycle model . 10
6 Requirements for quality requirements. 12
6.1 General requirements and assumptions . 12
6.2 Stakeholder requirements . 12
6.3 Software requirements. 14
Annex A (normative) Terms and definitions. 19
Annex B (informative) Processes from ISO/IEC 15288. 32
Bibliography . 35

© ISO/IEC 2007 – All rights reserved iii

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. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
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.
ISO/IEC 25030 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
ISO/IEC 25030 is part of the ISO/IEC 25000 SQuaRE series of standards. The series consists of the following
divisions under the general title Software product Quality Requirements and Evaluation (SQuaRE):
⎯ ISO/IEC 2500n, Quality Management Division,
⎯ ISO/IEC 2501n, Quality Model Division,
⎯ ISO/IEC 2502n, Quality Measurement Division,
⎯ ISO/IEC 2503n, Quality Requirements Division, and
⎯ ISO/IEC 2504n, Quality Evaluation Division.
ISO/IEC 25050 to ISO/IEC 25099 are reserved to be used for SQuaRE extension International Standards,
Technical Specifications, Publicly Available Specifications (PAS) and/or Technical Reports: ISO/IEC 25051
and ISO/IEC 25062 are already published.
iv © ISO/IEC 2007 – All rights reserved

Introduction
It is important to identify and specify software quality requirements as part of specifying the requirements for a
software product. Software is usually part of a larger system. System requirements and software requirements
are closely related and software requirements can therefore not be considered in isolation. This International
Standard focuses on software quality requirements, but takes a system perspective. Software quality
requirements can be categorized by use of a quality model, for example the quality model defined in
ISO/IEC 9126-1 [ISO/IEC 25010]. Measures of attributes of these characteristics and their subcharacteristics
can be used to specify software quality requirements and evaluate the quality of a software product.
Software quality requirements address important issues of quality for software products. Software product
quality requirements are needed for:
⎯ specification (including contractual agreement and call for tender);
⎯ planning (including feasibility analysis and translation of external software quality requirements into
internal software quality requirements);
⎯ development (including early identification of potential quality problems during development); and
⎯ evaluation (including objective assessment and certification of software product quality).
If software quality requirements are not stated clearly, they may be viewed, interpreted, implemented and
evaluated differently by different people. This may result in software which is inconsistent with user
expectations and of poor quality; users, clients and developers who are unsatisfied; and time and cost
overruns to rework software.
This International Standard aims to improve the quality of software quality requirements. It does this by
providing requirements and recommendations for quality requirements, and guidance for the processes used
to define and analyse quality requirements.
Application of this International Standard should help ensure that software quality requirements are:
⎯ in accordance with stakeholder needs;
⎯ stated clearly and precisely;
⎯ correct, complete, and consistent; and
⎯ verifiable and measurable.
This International Standard is intended to be used in conjunction with the other parts of the SQuaRE series of
Standards (ISO/IEC 25000 – ISO/IEC 25049), and with ISO/IEC 14598 and ISO/IEC 9126, until superseded
by the ISO/IEC 25000 series.
This International Standard complies with the technical processes defined in ISO/IEC 15288:2002 related to
quality requirements definition and analysis.
© ISO/IEC 2007 – All rights reserved v

Quality Model
Division
2501n
Quality
Management Division
Quality
Quality
2500n
Evaluation
Requirements
Quality
Division
Division
Measurement Division
2504n
2503n
2502n
Figure 1 — Organisation of the ISO/IEC 25000 SQuaRE series of International Standards
Figure 1 (copied from ISO/IEC 25000) illustrates the organisation of the ISO/IEC 25000 SQuaRE series
representing families of International Standards, further called Divisions.
The Divisions within SQuaRE model are:
⎯ ISO/IEC 2500n, Quality Management Division. The International Standards that form this division
define all common models, terms and definitions referred to further by all other International Standards
from the SQuaRE series. Referring paths (guidance through SQuaRE documents) and high level practical
suggestions in applying proper International Standards to specific application cases offer help to all types
of users. The division also provides requirements and guidance for a supporting function which is
responsible for the management of software product requirements specification and evaluation.
⎯ ISO/IEC 2501n, Quality Model Division. The International Standard that forms this division presents a
detailed quality model including characteristics for internal, external and quality in use. Furthermore, the
internal and external software quality characteristics are decomposed into subcharacteristics. Practical
guidance on the use of the quality model is also provided.
⎯ ISO/IEC 2502n, Quality Measurement Division. The International Standards that form this division
include a software product quality measurement reference model, mathematical definitions of quality
measures, and practical guidance for their application. Presented measures apply to internal software
quality, external software quality and quality in use. Measurement primitives forming foundations for the
latter measures are defined and presented.
⎯ ISO/IEC 2503n, Quality Requirements Division. The International Standard that forms this division
helps specify quality requirements. These quality requirements can be used in the process of quality
requirements elicitation for a software product to be developed or as input for an evaluation process. The
requirements definition process is mapped to technical processes defined in ISO/IEC 15288.
⎯ ISO/IEC 2504n, Quality Evaluation Division. The International Standards that form this division provide
requirements, recommendations and guidelines for software product evaluation, whether performed by
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 to be used for SQuaRE extension International Standards
and/or Technical Reports.
vi © ISO/IEC 2007 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 25030:2007(E)

Software engineering — Software product Quality
Requirements and Evaluation (SQuaRE) — Quality
requirements
1 Scope
This International Standard provides requirements and recommendations for the specification of software
product quality requirements.
This International Standard applies to organisations in their role as both acquirers and suppliers.
The quality model in ISO/IEC 9126-1 [ISO/IEC 25010] is used to categorize software quality requirements and
to provide a basis for quantifying the quality requirements in terms of software quality measures.
This International Standard complies with the technical processes defined in ISO/IEC 15288:2002, which are
relevant for identification of stakeholder product quality needs and for analysis of software product quality
requirements.
This International Standard does not cover specification of other requirements (such as functional
requirements, process requirements, business requirements, etc.).
This International Standard does not prescribe specific software quality measures nor does it prescribe any
specific development process.
2 Conformance
Software quality requirements conform to this International Standard if they fulfil the requirements specified in
Clause 6.
3 Normative references
The following referenced documents are indispensable for the application 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.
1)
ISO/IEC 9126-1:2001, Software engineering — Product quality — Part 1: Quality model
ISO/IEC 25020, Software engineering — Software product Quality Requirements and Evaluation
(SQuaRE) — Measurement reference model and guide

1) ISO/IEC 9126-1:2001 will be cancelled and replaced by ISO/IEC 25010.
© ISO/IEC 2007 – All rights reserved 1

4 Terms and definitions
For the purposes of this International Standard, the terms and definitions given in ISO/IEC 25000
(repeated in Annex A for convenience) apply. There are no definitions specific to this International
Standard.
5 Fundamental concepts for quality requirements
Clause 5 describes concepts related to software quality requirements that are used in this Interna-
tional Standard. This clause does not include requirements.
5.1  Software and systems
Software is the main focus of this International Standard. However, software usually appears as
part of a larger system. Therefore it can be useful to take a system view. A system is defined as a
combination of interacting elements organised to achieve one or more stated purposes. This defini-
tion allows a high degree of freedom to decide, what constitute a system and what the elements of
the system are. The boundaries of a system will depend on the point of view.
Note 1 The boundary of a system depends on the point of view as illustrated by the following three examples.
One example is the control system of an aircraft engine, the second example is the complete engine of an
aircraft, and a third example is the complete aircraft. An aircraft can be considered as a combination of ele-
ments (the engines, the wings, etc.). These elements can also be considered systems on their own.
Enterprice system
Information system Human business
processes
Computer system
Computer Operating Application Data
Hardware system software
communication
communication
communication
Computer system
Mechanical system
Computer Operating Application Data
communication
Hardware system software
Figure 2 – Example of a system model
Figure 2 is an example of a system model showing hierarchies of systems including an information
system, a mechanical system, human business processes and communication among them.
2 © ISO/IEC 2007 – All rights reserved

There may be several different appropriate ways of defining the elements of a system. Software
may be considered one of the elements of a system. A computer system is an example of a system,
which includes software. The elements of a computer system include the computer hardware, op-
erating system and data necessary to apply the software. A computer system represents an appli-
cable model when discussing single user software like a word processor. Client–server software or
internet applications need a more complex system model like an information system which includes
more communicating computer systems. E-commerce applications often include human business
processes as well. Many devices include both computer systems and mechanical systems such as
an antilock braking system (ABS) of a car. The luggage handling at an airport includes both
computer systems, mechanical systems (such as conveyer belts), and human business processes.
This example illustrates that humans can be part of a system.
5.2  Stakeholders and stakeholder requirements
Systems have a variety of stakeholders who have an interest in the system throughout its life cycle.
The stakeholders of a system include all persons (for example end users), organisations (for ex-
ample end user organisations or development organisations) and bodies (for example statutory and
regulatory authorities or the general public) having a legitimate interest in the system. Stakeholders
have different needs and expectations to the system. Their needs and expectations may change
throughout the systems life cycle.
Stakeholder needs can be explicitly stated or only implied. Implied needs are often implied by the
context where the software product is to be used and represent expectations based on similar
software products or existing work routines, normal working procedures and operations of business,
laws and regulations, etc. Stakeholders are sometimes not aware of all their needs. In many situa-
tions stakeholder needs only become evident when the software product and related business
processes or tasks can be tried out. Scenarios, use cases, and prototypes are examples of meth-
ods that can be used to identify implied needs and other needs that stakeholders are not aware of
(unaware needs) at an early stage in a development project. In some cases the real needs of some
stakeholders are different from what they express.
The stakeholders’ needs and expectations are identified through a requirements elicitation and
definition process as illustrated in figure 3. The process takes all stakeholders’ needs, wants, de-
sires, and expectations into consideration. This includes the needs and requirements imposed by
society, the constraints imposed by the acquirer, and the needs of the end users.
Different categories of stakeholders often have different needs and expectations. In some situa-
tions stakeholders have conflicting needs. Conflicts between stakeholder requirements could for
example be between different end user perspectives, or between acquirer needs and available
skills, experiences or resources in the developing organisation.
This International Standard does not prescribe any specific software life cycle processes, but it
complies with the relevant system life cycle processes in ISO/IEC 15288:2002. The International
Standard ISO/IEC 15288:2002 defines two technical processes aiming at defining stakeholder re-
quirements and analysing system requirements:
a) Stakeholder Requirements Definition Process (ISO/IEC 15288:2002 clause 5.5.2)
b) Requirements Analysis Process (ISO/IEC 15288:2002 clause 5.5.3)
Note 1 ISO/IEC 15288:2002 is used in preference to ISO/IEC 12207:1995 as ISO/IEC 12207:1995 is less ex-
plicit about quality requirements.
Although these two processes form a logical sequence, they are often used iteratively. In Annex B
of this International Standard the activities of the relevant processes are provided.
The two processes may be tailored as specified in ISO/IEC 15288:2002 Annex A to satisfy particu-
lar circumstances or factors that:
© ISO/IEC 2007 – All rights reserved 3

a) surround an organisation that is employing the International Standard in an agreement;
b) influence a project that is required to meet an agreement in which the International Standard
is referenced;
c) reflect the needs of an organisation in order to supply products or services.
The two processes defined in ISO/IEC 15288:2002 are concerned with system requirements activi-
ties whereas this International Standard is concerned with software quality requirements. Although
software quality requirements should be considered in a system perspective there may be activities
prescribed in ISO/IEC 15288:2002 which are not or only marginally relevant from the point of view
of software quality requirements.
Stakeholder Stakeholder System require-
needs and ex- requirements ments
pectations
Stakeholder re-
Requirements
quirements defini-
analysis proc-
* Stated
tion process
ess
Elicited from all Formalized sys-
* Implied relevant stake- tem require-
holders ments and con-
* Unaware straints
Figure 3 – Stakeholder requirements definition and analysis
The result of the definition process is called stakeholders requirements. The result of the analysis
process is called system requirements.
5.3  Stakeholder requirements and system requirements
An analysis process transforms stakeholder requirements into a technical view of system require-
ments that can be used to realise the desired system, see figure 3. The technical view of require-
ments is called system requirements. System requirements are verifiable and will state which char-
acteristics the system is to possess in order to satisfy stakeholder requirements.
A system will often be composed of different elements, each with specific characteristics and serv-
ing different purposes in the whole system. In order to be operational, system requirements have to
be formulated as requirements for the different system elements. As different elements interact to
offer the system capabilities, requirements for different system elements cannot be seen in isola-
tion, but only in a broader view including requirements for other system elements.
Stakeholder requirements may imply requirements for, for example, software, but it is not always
the case that a stakeholder requirement implies a software requirement. Stakeholder requirements
can be implemented in alternative ways, for example, either in hardware or in software or as a
business process (for example as a manual process). Such implementation decisions are part of a
high level design process. Figure 4 shows the requirements hierarchy based on system design de-
cisions applying the system model shown in figure 2.
4 © ISO/IEC 2007 – All rights reserved

System
requirements
Human business Information Mechanical
process system system
requirements requirements requirements
Computer Computer Computer
system system system
requirements requirements requirements
Computer Operating Application Data
hardware system software requirements
requirements requirements requirements

Figure 4 – System and software requirements hierarchy
5.4  Software quality model
The quality of a system is the result of the quality of the system elements and their interaction. This
International Standard focuses on the quality of the software as part of a system.
Software quality is the capability of the software product to satisfy stated and implied needs when
used under specified conditions. The software product quality model provided in ISO/IEC 9126-1
[ISO/IEC 25010] defines six quality characteristics:
• Functionality: The capability of the software product to provide functions which meet stated
and implied needs when the software is used under specified conditions.
• Reliability: The capability of the software product to maintain a specified level of perform-
ance when used under specified conditions
• Usability: The capability of the software product to be understood, learned, used and at-
tractive to the user, when used under specified conditions.
• Efficiency: The capability of the software product to provide appropriate performance, rela-
tive to the amount of resources used, under stated conditions.
• Maintainability: The capability of the software product to be modified. Modifications may
include corrections, improvements or adaptation of the software to changes in environment,
and in requirements and functional specifications.
• Portability: The capability of the software product to be transferred from one environment to
another.
The standard defines an additional quality characteristic aiming at the system level:
© ISO/IEC 2007 – All rights reserved 5

• Quality in use: The capability of the software product to enable specified users to achieve
specified goals with effectiveness, productivity, safety and satisfaction in specified contexts
of use.
The quality characteristics have defined subcharacteristics and the standard allows for user de-
fined sub-subcharacteristics in a hierarchical structure. The defined quality characteristics cover all
quality aspects of interest for most software products and as such can be used as a checklist for
ensuring a complete coverage of quality.
The quality model defines three different views of quality:
• Software quality in use
• External software quality
• Internal software quality
The software quality in use view is related to application of the software in its operational environ-
ment, for carrying out specific tasks by specific users. External software quality provides a ‘black
box’ view of the software and addresses properties related to the execution of the software on
computer hardware and applying an operating system. Internal software quality provides a ‘white
box’ view of software and addresses properties of the software product that typically are available
during the development. Internal software quality is mainly related to static properties of the soft-
ware. Internal software quality has an impact on external software quality, which again has an im-
pact on quality in use. Figure 5 shows the interaction between the different quality models and sys-
tems. The ISO/IEC 25000 SQuaRE series of International Standards covers the software quality
models and the data quality model, but not the other quality models shown in the figure.
Internal External Software
Software
software software quality in use
quality
quality quality model
models
model model
System
Information system
Computer system
Computer Operating Software Data Human Mechanical
hardware system business system
process
Computer Data quality Human Mechanical
Other
hardware model business system
quality
quality process quality
models
model quality model
model
Figure 5 – Example of system model and quality models
The quality model serves as a framework to ensure that all aspects of quality are considered from
the internal, external, and quality in use point of view.
6 © ISO/IEC 2007 – All rights reserved

5.5  Software properties
Some software properties are inherent in the software product; some are assigned to the software
product. The capabilities of a software product are determined by its inherent properties.
Note 1 “Inherent”, as opposed to “assigned”, means existing in something, especially as a permanent charac-
teristic or feature.
Note 2 Examples of inherent properties are number of lines of code and the accuracy of a numeric calculation
provided by the software. Examples of assigned properties are the owner of a software product and the price
of a software product.
Inherent properties can be classified as either functional properties or quality properties. Functional
properties determine what the software is able to do. Quality properties determine how well the
software performs. In other words, the quality properties show the degree to which the software is
able to provide and maintain its specified services. Quality is inherent to a software product. An
assigned property is therefore not considered to be a quality characteristic of the software, since it
can be changed without changing the software. Figure 6 illustrates this classification of software
properties.
Software properties Inherent properties Functional properties
Quality properties: functionality,
reliability, usability, maintainability,
portability, efficiency, quality in use
Managerial properties like for ex-
Assigned properties
ample price, delivery date, product
future, product supplier
Figure 6 – Software properties
5.6  Software quality measurement model
Inherent software properties, that can be distinguished quantitatively or qualitatively, are called at-
tributes. Quality attributes are categorised into one or more quality characteristics and subcharacteristics.
Quality attributes are measured by applying a measurement method. A measurement method is a
logical sequence of operations used to quantify an attribute with respect to a specified scale. The
result of applying a measurement method is called a base measure. The quality characteristics and
subcharacteristics can be quantified by applying measurement functions. A measurement function
is an algorithm used to combine quality measure elements. The result of applying a measurement
function is called a software quality measure. In this way software quality measures become quan-
tifications of the quality characteristics and subcharacteristics. More than one software quality
measure may be used to measure a quality characteristic or subcharacteristic.
Figure 7 copied from ISO/IEC 25020 shows the relations between the ISO/IEC 25010 quality model,
the measure in ISO/IEC 2502n, and the measurement model suggested in ISO/IEC 15939.
© ISO/IEC 2007 – All rights reserved 7

Software product
quality
Software quality
measures
Quality
characteristics
Measurement
function
Quality sub- Quality measure
characteristics elements
Figure 7 – Software product quality measurement reference model
5.7  Software quality requirements
A measurement function provides an interpretation of a software quality property, i.e. it assigns a
value to a property. A target value of the software quality measure represents a software quality
requirement, i.e. what is the required value of the property. Similarly, the actual value of the quality
measurement represents the observed quality of the software.
Software quality requirements as well as all other requirements cannot be seen in isolation, but
must be viewed in a broader context. Software quality requirements have a particularly close rela-
tion to functional requirements. Although functional requirements are not the topic of this Interna-
tional Standard, they play an important role in specifying software quality requirements.
Note 1 Functionality is one of the six characteristics for internal and external quality in ISO/IEC 9126-1
[ISO/IEC 25010]. Functionality requirements should not be confused with functional requirements. Functional-
ity is the capability of the software to provide functions which meet its functional requirements. Functionality
requirements are refined into requirements for the software product to be suitable, accurate, interoperable,
secure and compliant with relevant functional standards and regulations.
In some situations it is meaningful to specify a software quality requirement for the complete soft-
ware product, whereas in other situations a software quality requirement only applies to a portion of
the software product. For example, some functions are only relevant for specific users and have
specific software quality requirements, which are different from quality requirements for other func-
tions intended for other purposes and other users. It is therefore important to specify which portion
of a software product is relevant for a software quality requirement. In other words, a software qual-
ity requirement applies to a portion of the software product (a set of functions). For example, some
functions may be intended for general end users and may hence require low error tolerance,
whereas another group of functions may be intended for specialists and thus permit greater error
tolerance. In both cases the error tolerance mechanism and the degree of error tolerance required
should be rigorously specified.
8 © ISO/IEC 2007 – All rights reserved

Software quality requirements may result in additional functional requirements that support the
software quality requirements. For example, a usability requirement can result in an additional func-
tion providing online help for the user.
Figure 8 shows how software quality requirements are derived as part of the requirements proc-
esses defined in ISO/IEC 15288. The definition process focuses on stakeholder requirements for
the system. The analysis process assumes some architectural decisions, which makes it possible
to identify requirements relevant for the software elements of the system. When focusing on stake-
holder quality needs the quality model defined in ISO/IEC 25010 is useful for defining stakeholder
quality requirements. Similarly the (software quality) measures defined in ISO/IEC TR 9126-2,
ISO/IEC TR 9126-3 and ISO/IEC TR 9126-4 [ISO/IEC 2502n] are useful for formalising the
stakeholder software quality requirements.
Stakeholder Stakeholder System
needs requirements requirements
Software
requirements
Definition Analysis
process process
Sw quality
requirements
Stakeholder
Quality Quality
System
quality
model measures
quality
Stakeholder
25010 requirements 2502n
requirements
quality needs
Figure 8 – Software quality requirements definition and analysis
Note 2 In figure 8 it is emphasised that stakeholder requirements and stakeholder quality requirements ad-
dresses the whole system in question and not only the software.
5.8  System requirements categorisation
A system consists of a number of interacting elements. They can be defined and categorised in
different ways. Figure 2 provides one possible categorisation. Figure 9 provides a similar categori-
sation of system requirements. System requirements can for example include requirements for
software, computer hardware, data, mechanical system, human business organisation, etc., and
may come from a variety of stakeholders including end users, organisations, and official bodies. As
this International Standard mainly focuses on software, figure 9 emphasises software requirements.
Software requirements address either the software product or the software development process.
Software product requirements include functional requirements, quality requirements and manage-
rial requirements. Functional requirements include the application domain specific requirements as
well as functional requirements that support quality requirements. Quality requirements may also
imply architectural and structural requirements.
Software development process requirements may for example include requirements for artefacts,
processes, project, development organisation, and developers. There will often be dependencies
© ISO/IEC 2007 – All rights reserved 9

between software development requirements and software product requirements. Possible de-
pendencies are not shown in figure 9.
Software product Inherent Functional requirements
requirements property
Software Quality in use requirements
requirements
quality
External quality requirements
requirements
Internal quality requirements
Assigned Managerial requirements including for example
property requirements for price, delivery date, product fu-
requirements ture, and product supplier
Software Development process requirements
development
requirements
Development organisation requirements
Include for example requirements for computer hardware, data, mechanical parts, and hu-
man business processes
Figure 9 – System requirements categorisation
5.9  Quality requirements life cycle model
Stakeholder requirements come from many sources. Figure 10 illustrates the situation where a
similar system already exists and is in use. In that case the properties and the users of the existing
system will be a major source of input to the requirements of the new system. Stakeholder re-
quirements can then largely be identified based on experiences from actual use of the existing sys-
tem. When the system in question is completely new, i.e. no similar systems exist, it may be more
difficult to identify the real needs of stakeholders.
There are three views of software quality as described in clause 5.4. These different views give rise
to three types of software quality requirements:
• Software quality in use requirements
• External software quality requirements
• Internal software quality requirements
Quality in use requirements are typically derived from stakeholder requirements such as a) busi-
ness requirements (company policy, competitors, etc.), b) functional requirements, and c) applica-
tion domain specific requirements. Quality in use requirements are normally used for software vali-
dation (is the software fit for its intended purpose). External software quality requirements are typi-
cally derived from a number of sources including a) stakeholder requirements, b) legal require-
ments, c) standards and guidelines for the relevant application, d) quality in use requirements, e)
functional requirements, f) application domain specific requirements, and g) security requirements,
which may be derived from risk analysis. External software quality requirements are used for soft-
ware validation and verification (is the software built according to specifications). Internal software
10 © ISO/IEC 2007 – All rights reserved

System requirements
Other system Software requirements
requirements
quality requirements are typically derived from a number of sources including a) external software
quality requirements, b) company policy, c) development policy and limitations, and d) best practice
guidelines. Internal software quality requirements are normally used for quality monitoring and con-
trol during development.
Software quality in use requirements may imply external software quality requirements and simi-
larly external software quality requirements may imply internal software quality requirements. The
software implementation process realises the software quality requirements. The quality of the new
system can be used as input to another new system again, thereby completing the cycle indicated
in figure 10.
Software requirements can be specified as part of an iterative development process, where one
version of the software is used as a basis for deciding the requirements for the next version. In
general it is the functional requirements that evolve in this way, whereas the software quality re-
quirements are fixed. However, quality requirements can also evolve across versions.
Stakeholder needs
Stakeholder Require- Software Quality Re- Software Product
ments quirements
Quality in use Quality in use
requirements
External External
Elicited from all rele-
quality quality
vant stakeholders
requirements
Internal quality Internal quality
requirements
Implementation
Figure 10 – Quality requirements life cycle
© ISO/IEC 2007 – All rights reserved 11

6 Requirements for quality requirements
Clause 6 provides requirements and recommendations for quality requirements for a software
product.
6.1  General requirements and assumptions
Software is often part of a larger system. Architectural decisions made at a higher level of system
hierarchal structure define boundaries and interfaces to the software.
Note 1 Architectural decisions about which parts of a system will actually be implemented in software may not
or only partly be made at the time when stakeholder quality requirements are specified. Therefore it may be
impossible to decide at an early time in the system life cycle process whether or not a quality requirement is
related to software.
Note 2 Quality requirements cannot be seen in isolation, but only in connection with other types of require-
ments.
Note 3 ISO 9001:2000 requires that quality requirements for a product are determined. More specifically,
clause 7.2.1 in 9001:2000 states the following requirements concerning determination of requirements related
to a product: The organisation shall determine a) requirements specified by the customer, including the re-
quirements for delivery and post-delivery activities, b) requirements not stated by the customer but necessary
for specified or intended use, where known, c) statutory and regulatory requirements related to the product,
and d) any additional requirements determined by the organisation.
This International Standard assumes that a software quality model with a structure similar to the
ISO/IEC 25010 quality model is used. The applied software quality model shall be documented.
Note 4 The quality model defined in ISO/IEC 25010 is suggested. This model may be used in many situations,
and is the basis for this International Standard. However, in some cases it may be appropriate to use another
quality model emphasising specific quality aspects.
No specific development model or measures are prescribed or assumed.
Note 5 This International Standard applies the generic system life cycle processes framework defined in
ISO/IEC 15288:2002. The stakeholder requirement definition process and the requirement analysis process
are most relevant for this International Standard.
Note 6 There are many similarities between processes and activities involved with requirements in general
and software product quality requirements in particular. In many cases the activities are combined.
6.2  Stakeholder requirements
Stakeholder requirements are related to a system. Some stakeholder requirements may not be
relevant for software. When system architecture decisions are made it can be decided which
stakeholder requirements influence the software. Clause 6.2 takes a system view and is not spe-
cific for software.
Note ISO/IEC 15288:2002 clause 5.5.2 describes stakeholder requirements definition process activities. See
annex B of this International Standard for more details.
6.2.1 System boundaries
The requirements and recommendations in this clause aim to ensure that system boundaries and
constraints relevant for the system quality are documented.
The boundaries of the system shall be documented.
Note 1 Clause 5.2 provides an explanation of the system concept.
12 © ISO/IEC 2007 – All rights reserved

The intended purpose of the system shall be documented. The documentation should include us-
age, the benefits, system specified life time, system criticality and risk dependencies like safety or
hazard issues.
System constraints shal
...