ISO/IEC 26551:2016

INTERNATIONAL ISO/IEC
STANDARD 26551
Second edition
2016-05-01
Software and systems engineering —
Tools and methods for product line
requirements engineering
Ingénierie du logiciel et des systèmes — Outils et méthodes pour
l’ingénierie d’exigences pour gammes de produits
Reference number
ISO/IEC 26551:2016(E)
©
ISO/IEC 2016

---------------------- Page: 1 ----------------------
ISO/IEC 26551:2016(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 26551:2016(E)

Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Reference model for product line requirements engineering . 3
5 Product line scoping . 7
5.1 Product scoping . 8
5.1.1 Purpose of product scoping. 8
5.1.2 Structure information to be used for scoping . 9
5.1.3 Identify products . 9
5.1.4 Analyse common and variable features .10
5.1.5 Define a product portfolio .10
5.2 Domain scoping .10
5.2.1 Purpose of domain scoping .10
5.2.2 Identify functional domains .11
5.2.3 Map features to functional domains .11
5.2.4 Define domain scope .12
5.3 Asset scoping .12
5.3.1 Purpose of asset scoping .12
5.3.2 Gather historical data from existing single products .13
5.3.3 Estimate additional effort required to adapt potential assets .14
5.3.4 Estimate expected development effort for new products in the product
portfolio definition .14
5.3.5 Estimate economic benefits from reusing proposed assets .14
5.3.6 Derive asset proposals from economic evaluation results .15
6 Domain requirements engineering .15
6.1 Domain requirements elicitation .16
6.1.1 Purpose of the domain requirements elicitation .16
6.1.2 Draw a context diagram .17
6.1.3 Gather domain information .17
6.1.4 Identify initial domain requirements .18
6.1.5 Review the elicited initial domain requirements .18
6.2 Domain requirements analysis .19
6.2.1 Purpose of the domain requirements analysis .19
6.2.2 Classify and balance initial domain requirements .20
6.2.3 Analyse commonalities and variabilities .20
6.2.4 Model domain requirements .21
6.2.5 Create prototypes and analyse feasibility .21
6.2.6 Develop conceptual test cases and scenarios for acceptance testing . .22
6.2.7 Review the analysed domain requirements .22
6.3 Domain requirements specification .23
6.3.1 Purpose of the domain requirements specification .23
6.3.2 Identify sources of domain requirements .23
6.3.3 Establish traceability . .24
6.3.4 Document domain requirements .24
6.3.5 Review the domain requirements specification .25
6.4 Domain requirements verification and validation .25
6.4.1 Purpose of the domain requirements verification and validation .25
6.4.2 Verify domain requirements .26
6.4.3 Validate domain requirements .26
6.4.4 Validate conceptual test cases and scenarios for acceptance testing .27
© ISO/IEC 2016 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 26551:2016(E)

6.4.5 Baseline domain requirements .27
6.4.6 Initiate change management process .28
6.5 Domain requirements management .28
6.5.1 Purpose of the domain requirements management .28
6.5.2 Manage domain requirements change.29
6.5.3 Manage traceability .30
6.5.4 Manage versions of domain requirements .30
6.5.5 Record and report status .30
6.5.6 Manage process improvement .31
6.5.7 Manage feedback .31
7 Variability management in requirements engineering .32
7.1 Variability in textual requirements .32
7.1.1 Purpose of variability in textual requirements.32
7.1.2 Define requirements variability in textual requirements .33
7.1.3 Document requirements variability in textual requirements .33
7.2 Variability in requirements models .33
7.2.1 Purpose of variability in requirements models.33
7.2.2 Define requirements variability in model .34
7.2.3 Document requirements variability in requirements model .34
7.3 Variability mechanisms in requirements .35
7.3.1 Purpose of variability mechanisms in requirements .35
7.3.2 Identify variability mechanisms in requirements .35
7.3.3 Guide the use of variability mechanisms in requirements .36
7.3.4 Verify the usage of variability mechanisms in requirements .36
7.3.5 Improve variability mechanisms in requirements .37
7.4 Traceability between requirements variability and variability model .37
7.4.1 Purpose of traceability between requirements variability and variability model 37
7.4.2 Define explicit links between requirements variability and variability model .37
8 Asset management in requirements engineering .38
8.1 Domain requirements artefacts as domain assets .38
8.1.1 Purpose of domain requirements artefacts as domain assets .38
8.1.2 Identify domain requirements artefacts managed as domain assets.39
8.1.3 Define configuration and annotation .39
8.2 Application requirements artefacts as application assets .40
8.2.1 Purpose of application requirements artefacts as application assets .40
8.2.2 Identify application requirements artefacts managed as application assets .40
8.2.3 Define configuration and annotation for application requirements assets .40
9 Application requirements engineering .41
9.1 Application requirements elicitation .42
9.1.1 Purpose of the application requirements elicitation .42
9.1.2 Draw a context diagram for an application .42
9.1.3 Identify the requirements gaps between domain and application requirements 43
9.1.4 Bind the best matching variants .43
9.1.5 Select domain assets .44
9.1.6 Review the elicited application requirements .44
9.2 Application requirements analysis .45
9.2.1 Purpose of the application requirements analysis .45
9.2.2 Classify and balance application specific initial requirements .46
9.2.3 Analyse commonalities and variabilities .46
9.2.4 Model application specific requirements .47
9.2.5 Create prototypes and analyse feasibility .47
9.2.6 Develop conceptual test cases and scenarios for acceptance testing . .48
9.2.7 Review the analysed application requirements .48
9.3 Application requirements specification .49
9.3.1 Purpose of the application requirements specification .49
9.3.2 Identify sources of application specific requirements .50
9.3.3 Establish traceabilities for application specific requirements .50
iv © ISO/IEC 2016 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 26551:2016(E)

9.3.4 Document application specific requirements .50
9.3.5 Document the rationale for variability decision .51
9.3.6 Review the application requirements specification .51
9.4 Application requirements verification and validation.51
9.4.1 Purpose of the application requirements verification and validation .51
9.4.2 Verify application specific requirements .52
9.4.3 Validate application specific requirements.52
9.4.4 Validate conceptual test cases and scenarios for acceptance testing .53
9.4.5 Baseline application specific requirements.53
9.4.6 Initiate application change management process .54
9.5 Application requirements management .54
9.5.1 Purpose of the application requirements management .54
9.5.2 Manage application specific requirements change .55
9.5.3 Manage application specific traceability .55
9.5.4 Manage versions of application specific requirements artefacts .56
9.5.5 Record and report status of application requirements management .56
9.5.6 Manage application specific process improvement.56
Annex A (informative) Comparison of requirements engineering tasks between single
product and product line .58
Annex B (informative) Process mapping with ISO/IEC 12207, ISO/IEC/IEEE 15288, and ISO/
IEC/IEEE 29148 .60
Annex C (informative) A construct for process, method, tool, and aspect .63
Bibliography .64
© ISO/IEC 2016 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC 26551:2016(E)

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.
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).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 7, Software and systems engineering.
This second edition of ISO/IEC 26551 cancels and replaces the first edition (ISO/IEC 26551:2012), which
has been technically revised.
vi © ISO/IEC 2016 – All rights reserved

---------------------- Page: 6 ----------------------
ISO/IEC 26551:2016(E)

Introduction
The main purpose of this International Standard is to establish a baseline for the capabilities of tools
and methods of software and systems product line (SSPL) requirements engineering. This International
Standard defines how the tools and methods can support the software and systems product line specific
requirements engineering processes.
A decision for the initial boundaries of domain is made to define a product line scope before initiating
domain requirements engineering processes. Domain requirements engineering is carried out in a
comprehensive manner because common and variable requirements and captured variabilities have
consequential impacts on member products in a product line. The outcomes of domain requirements
engineering processes are transferred into the requirements of a family of products at the application
requirements engineering processes. Therefore, requirements engineering tools and methods are to be
considered (both engineering processes), namely domain requirements engineering, and application
requirements engineering.
Product line requirements engineering can be differentiated from a single product requirement
engineering because of the following reasons:
— There are two core processes in requirements engineering, domain requirements engineering and
application requirements engineering. The major aims of the domain requirements engineering
processes are to analyse commonality and variability for a family of products and to prepare
necessary variability information for variability modelling. The major aims of the application
requirements engineering processes are to define application specific requirements and bind
variability defined in domain requirements engineering processes;
— It is essential to analyse the costs and benefits estimate of a product line and thereby, an organization
can make a go/no-go decision. Moreover, the costs and benefits estimate plays a pivotal role as an
indicator for assessing the effectiveness and efficiency of a product line.
A detailed comparison showing the differences in requirements engineeing tasks between single
product and product line is described in Annex A.
This International Standard can be used in the following modes:
— by the users of this International Standard: to benefit people who develop, operate, and manage
requirements engineering for software and systems product lines;
— by a product line organization: to provide guidance in the evaluation and selection for tools and
methods for product line requirements engineering;
— by providers of tools and methods: to provide guidance in implementing or developing tools and
methods by providing a comprehensive set of the capabilities of tools and methods for product line
requirements engineering.
The ISO/IEC 26550 family of standards addresses both engineering and management processes and
covers the key characteristics of product line development. The ISO/IEC 26550 family of standards
provides an overview of the consecutive International Standards (i.e. this International Standard
through ISO/IEC 26599), as well as the structure of the model:
ISO/IEC 26550, ISO/IEC 26551 and ISO/IEC 26555 are published. ISO/IEC 26557, ISO/IEC 26558 and
ISO/IEC 26559 are to be published. ISO/IEC 26552, ISO/IEC 26553, ISO/IEC 26554, ISO/IEC 26556,
ISO/IEC 26560, ISO/IEC 26561, ISO/IEC 26562, ISO/IEC 26563 are planned International Standards.
— Processes and capabilities of methods and tools for domain requirements engineering and
application requirements engineering are provided in this International Standard;
— Processes and capabilities of methods and tools for domain design and application design are
provided in ISO/IEC 26552 (International Standard under development);
© ISO/IEC 2016 – All rights reserved vii

---------------------- Page: 7 ----------------------
ISO/IEC 26551:2016(E)

— Processes and capabilities of methods and tools for domain realization and application realization
are provided in ISO/IEC 26553 (International Standard under development);
— Processes and capabilities of methods and tools for domain testing and application testing are
provided in ISO/IEC 26554 (International Standard under development);
— Processes and capabilities of methods and tools for technical management are provided in
ISO/IEC 26555;
— Processes and capabilities of methods and tools for organizational management are provided in
ISO/IEC 26556 (International Standard under development);
— Processes and capabilities of methods and tools for variability mechanisms are provided in
ISO/IEC 26557;
— Processes and capabilities of methods and tools for variability modeling are provided in
ISO/IEC 26558;
— Processes and capabilities of methods and tools for variability traceability are provided in
ISO/IEC 26559;
— Processes and capabilities of methods and tools for product management are provided in
ISO/IEC 26560 (International Standard under development);
— Processes and capabilities of methods and tools for technical probe are provided in ISO/IEC 26561
(International Standard under development);
— Processes and capabilities of methods and tools for transition management are provided in
ISO/IEC 26562 (International Standard under development);
— Processes and capabilities of methods and tools for configuration management of asset are provided
in ISO/IEC 26563 (International Standard under development);
— Others (ISO/IEC 26564 to ISO/IEC 26599): To be developed.
viii © ISO/IEC 2016 – All rights reserved

---------------------- Page: 8 ----------------------
INTERNATIONAL STANDARD ISO/IEC 26551:2016(E)
Software and systems engineering — Tools and methods
for product line requirements engineering
1 Scope
This International Standard, within the context of tools and methods of requirements engineering for
software and systems product lines:
— provides the terms and definitions specific to requirements engineering for software and systems
product lines and associated member products;
— defines process groups and their processes performed during product line requirements engineering
(those processes are described in terms of purpose, inputs, tasks, and outcomes);
— defines method capabilities to support the defined tasks of each process;
— defines tool capabilities to automate/semi-automate tasks or defined method capabilities.
This International Standard concerns processes and capabilities of requirements tools and methods for
a family of products, not for a single system.
This International Standard is not applicable to physical artefacts. Instead, system-level artefacts and
software lifecycle artefacts such as requirements documents, architectural data, validation plans,
behavioural models, etc. are pro
...