ISO/IEC/IEEE 29148:2011

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2011-12-01
Systems and software engineering —
Life cycle processes — Requirements
engineering
Ingénierie des systèmes et du logiciel — Processus du cycle de vie —
Ingénierie des exigences
Reference number
©
ISO/IEC 2011
©
IEEE 2011
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,
the IEC Central Office and IEEE do not accept any 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
and IEEE members. In the unlikely event that a problem relating to it is found, please inform the ISO Central Secretariat or IEEE at the
address given below.
©  ISO/IEC 2011
©  IEEE 2011
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 ISO, IEC or IEEE at the respective
address below.
ISO copyright office IEC Central Office Institute of Electrical and Electronics Engineers, Inc.
Case postale 56 3, rue de Varembé 3 Park Avenue, New York
CH-1211 Geneva 20 CH-1211 Geneva 20 NY 10016-5997, USA
Tel. + 41 22 749 01 11 Switzerland E-mail stds.ipr@ieee.org
Fax + 41 22 749 09 47 E-mail inmail@iec.ch Web www.ieee.org
E-mail copyright@iso.org Web www.iec.ch
Web www.iso.org
Published in Switzerland
© ISO/IEC 2011 – All rights reserved
ii © IEEE 2011 – All rights reserved

Contents Page
Foreword . vi
Introduction . vii
1 Scope . 1
2 Conformance . 1
2.1 Intended Usage . 1
2.2 Conformance to processes . 2
2.3 Conformance to information item content . 2
2.4 Full conformance . 2
2.5 Tailored conformance . 2
2.5.1 Processes . 2
2.5.2 Information items . 3
3 Normative references . 3
4 Terms, definitions and abbreviated terms . 3
4.1 Terms and definitions . 3
4.2 Abbreviated terms . 8
5 Concepts . 8
5.1 Introduction . 8
5.2 Requirements fundamentals . 8
5.2.1 General . 8
5.2.2 Stakeholders . 8
5.2.3 Transformation of needs into requirements . 9
5.2.4 Requirements construct . 9
5.2.5 Characteristics of individual requirements . 11
5.2.6 Characteristics of a set of requirements . 11
5.2.7 Requirement language criteria . 12
5.2.8 Requirements attributes . 12
5.3 Practical considerations . 14
5.3.1 Iteration and recursion of processes . 14
5.3.2 Iteration and recursion in requirements engineering . 16
5.4 Requirement information items . 17
6 Processes . 18
6.1 Requirement processes . 18
6.1.1 Guidelines for Processes . 19
6.2 Stakeholder requirements definition process . 19
6.2.1 Purpose . 19
6.2.2 Outcomes . 19
6.2.3 Activities and tasks . 20
6.3 Requirements analysis process . 27
6.3.1 Purpose . 27
6.3.2 Outcomes . 27
6.3.3 Activities and tasks . 27
6.4 Requirements engineering activities in other technical processes . 33
6.4.1 Requirements in architectural design . 33
6.4.2 Requirements in verification . 34
6.4.3 Requirements in validation . 36
6.5 Requirements management . 37
6.5.1 Management Overview . 37
6.5.2 Change management . 37
6.5.3 Measurement for requirements . 39
© ISO/IEC 2011 – All rights reserved
iii
© IEEE 2011 – All rights reserved

7 Information items .41
8 Guidelines for information items .42
8.1 Requirements information item outlines .42
8.2 Stakeholder requirements specification document .42
8.2.1 Introduction .42
8.2.2 StRS example outline .42
8.3 System requirements specification document .43
8.3.1 Introduction .43
8.3.2 SyRS example outline .44
8.4 Software requirements specification document .45
8.4.1 Introduction .45
8.4.2 SRS example outline .45
9 Information item content .46
9.1 Introduction .46
9.2 General content .46
9.2.1 Identification .46
9.2.2 Front matter .47
9.2.3 Definitions .47
9.2.4 References .47
9.2.5 Acronyms and abbreviations .47
9.3 Stakeholder requirements specification (StRS) document .47
9.3.1 Business purpose .47
9.3.2 Business scope .48
9.3.3 Business overview .48
9.3.4 Stakeholders .48
9.3.5 Business environment .48
9.3.6 Goal and Objective .48
9.3.7 Business model .48
9.3.8 Information environment .48
9.3.9 Business processes .49
9.3.10 Business operational policies and rules .49
9.3.11 Business operational constraints .49
9.3.12 Business operation modes .49
9.3.13 Business operational quality .49
9.3.14 Business structure .49
9.3.15 User requirements .49
9.3.16 Operational concept .50
9.3.17 Operational scenarios .50
9.3.18 Project constraints .50
9.4 System requirements specification (SyRS) document .50
9.4.1 System purpose .50
9.4.2 System scope .50
9.4.3 System overview .51
9.4.4 Functional requirements .51
9.4.5 Usability requirements .51
9.4.6 Performance requirements .51
9.4.7 System interfaces .51
9.4.8 System Operations .52
9.4.9 System modes and states .52
9.4.10 Physical characteristics .52
9.4.11 Environmental conditions .53
9.4.12 System security .53
9.4.13 Information management .53
9.4.14 Policies and regulations .53
9.4.15 System life cycle sustainment .53
9.4.16 Packaging, handling, shipping and transportation .53
9.4.17 Verification .54
9.4.18 Assumptions and dependencies .54
9.5 Software requirements specification (SRS) document .54
© ISO/IEC 2011 – All rights reserved
iv
© IEEE 2011 – All rights reserved

9.5.1 Purpose . 54
9.5.2 Scope . 54
9.5.3 Product perspective . 54
9.5.4 Product functions . 56
9.5.5 User characteristics . 57
9.5.6 Limitations . 57
9.5.7 Assumptions and dependencies . 57
9.5.8 Apportioning of requirements . 57
9.5.9 Specific requirements . 57
9.5.10 External interfaces . 58
9.5.11 Functions . 58
9.5.12 Usability requirements . 59
9.5.13 Performance requirements . 59
9.5.14 Logical database requirements . 59
9.5.15 Design constraints . 60
9.5.16 Standards compliance . 60
9.5.17 Software system attributes. 60
9.5.18 Verification . 61
9.5.19 Supporting information . 61
Annex A (normative) System operational concept . 62
A.1 Overview . 62
A.2 Operational concept document (OpsCon) . 62
A.2.1 Scope . 63
A.2.2 Referenced documents . 63
A.2.3 Current system or situation . 63
A.2.4 Justification for and nature of changes . 66
A.2.5 Concepts for the proposed system . 68
A.2.6 Operational scenarios . 70
A.2.7 Summary of impacts . 71
A.2.8 Analysis of the proposed system . 72
A.2.9 Appendices . 73
A.2.10 Glossary . 73
Annex B (informative) Concept of operations . 74
B.1 Overview . 74
B.2 Concept of operation document . 74
B.2.1 Purpose . 74
B.2.2 Scope . 74
B.2.3 Strategic plan . 74
B.2.4 Effectiveness . 74
B.2.5 Overall operation . 74
B.2.6 Governance . 75
Annex C (informative) Process Mapping from ISO/IEC 15288 and ISO/IEC 12207 . 76
C.1 Stakeholder requirements definition process . 76
C.2 Requirements analysis Process . 77
C.3 Other technical requirements-related processes . 78
Annex D (normative) Tailoring policies . 80
D.1 Introduction . 80
D.2 Information item tailoring process . 80
D.2.1 Purpose . 80
D.2.2 Outcomes . 80
D.2.3 Activities and tasks . 80
Bibliography . 82

© ISO/IEC 2011 – All rights reserved
v
© IEEE 2011 – 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. In the field of information technology, ISO
and IEC have established a joint technical committee, ISO/IEC JTC 1.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards
through a consensus development process, approved by the American National Standards Institute, which
brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers
are not necessarily members of the Institute and serve without compensation. While the IEEE administers the
process and establishes rules to promote fairness in the consensus development process, the IEEE does not
independently evaluate, test, or verify the accuracy of any of the information contained in its standards.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of ISO/IEC JTC 1 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 called to the possibility that implementation of this standard may require the use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. ISO/IEEE is not responsible for identifying essential
patents or patent claims for which a license may be required, for conducting inquiries into the legal validity or
scope of patents or patent claims or determining whether any licensing terms or conditions provided in
connection with submission of a Letter of Assurance or a Patent Statement and Licensing Declaration Form, if
any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly
advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is
entirely their own responsibility. Further information may be obtained from ISO or the IEEE Standards
Association.
ISO/IEC/IEEE 29148 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Software & Systems
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.

© ISO/IEC 2011 – All rights reserved
vi
© IEEE 2011 – All rights reserved

Introduction
This International Standard provides a unified treatment of the processes and products involved in
engineering requirements throughout the life cycle of systems and software. This International Standard is the
result of harmonization of the following sources:
ISO/IEC 12207:2008 (IEEE Std 12207-2008), Systems and software engineering — Software life cycle
processes
ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering — System life cycle
processes
ISO/IEC/IEEE 15289:2011, Systems and software engineering — Content of life-cycle information
products (documentation)
ISO/IEC TR 19759, Software Engineering — Guide to the Software Engineering Body of Knowledge
(SWEBOK)
IEEE Std 830, IEEE Recommended Practice for Software Requirements Specifications
IEEE Std 1233, IEEE Guide for Developing System Requirements Specifications
IEEE Std 1362, IEEE Guide for Information Technology — System Definition — Concept of Operations
(ConOps) Document
ISO/IEC TR 24748-1, Systems and software engineering — Life cycle management — Part 1: Guide for
life cycle management
ISO/IEC/IEEE 24765, Systems and software engineering — Vocabulary

© ISO/IEC 2011 – All rights reserved
vii
© IEEE 2011 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC/IEEE 29148:2011(E)

Systems and software engineering — Life cycle processes —
Requirements engineering
1 Scope
This International Standard
 specifies the required processes that are to be implemented for the engineering of requirements for
systems and software products (including services) throughout the life cycle,
 gives guidelines for applying the requirements and requirements-related processes described in
ISO/IEC 12207:2008 (IEEE Std 12207-2008) and ISO/IEC 15288:2008 (IEEE Std 15288-2008),
 specifies the required information items that are to be produced through the implementation of the
requirements processes,
 specifies the required contents of the required information items, and
 gives guidelines for the format of the required and related information items.
This International Standard is applicable to
 those who use or plan to use ISO/IEC 15288 and ISO/IEC 12207 on projects dealing with man-made
systems, software-intensive systems, software and hardware products, and services related to those
systems and products, regardless of project scope, product(s), methodology, size or complexity,
 anyone performing requirements engineering activities to aid in ensuring that their application of the
requirements engineering processes conforms to ISO/IEC 15288:2008 (IEEE Std 15288-2008) and/or
ISO/IEC 12207:2008 (IEEE Std 12207-2008),
 those who use or plan to use ISO/IEC/IEEE 15289:2011 on projects dealing with man-made systems,
software-intensive systems, software and hardware products, and services related to those systems and
products, regardless of project scope, product(s), methodology, size or complexity, and
 anyone performing requirements engineering activities to aid in ensuring that the information items
developed during the application of requirements engineering processes conform to
ISO/IEC/IEEE 15289:2011.
2 Conformance
2.1 Intended Usage
This International Standard provides guidance for the execution of the ISO/IEC 15288 and ISO/IEC 12207
processes that deal with requirements engineering. This International Standard also provides normative
definition of the content and recommendations for the format of the information items, or documentation, that
result from the implementation of these processes. Users of this International Standard can claim
conformance to the process provisions or to the information item provisions, or both.
© ISO/IEC 2011 – All rights reserved
© IEEE 2011 – All rights reserved

2.2 Conformance to processes
This International Standard provides requirements for a number of requirements engineering processes
suitable for usage during the life cycle of a system, a product, or a service.
The requirements for processes in this International Standard are contained in 5.2.4, 5.2.5, 5.2.6, 5.2.7, and
6.1.
NOTE 1 If a user of this International Standard claims full conformance to ISO/IEC 15288:2008 (IEEE Std 15288-2008)
and/or ISO/IEC 12207:2008 (IEEE Std 12207-2008), then by implication the user may claim conformance to the processes
in this International Standard.
NOTE 2 A claim to tailored conformance to ISO/IEC 15288:2008 (IEEE Std 15288-2008) and/or ISO/IEC 12207:2008
(IEEE Std 12207-2008), does not necessarily imply conformance to the processes in this International Standard.
2.3 Conformance to information item content
This International Standard provides requirements for a number of requirements engineering information items
to be produced during the life cycle of a system, a product or a service. A claim of conformance to the
information item provisions of this International Standard means that
 the user produces the required information items stated in this International Standard, and
 the user demonstrates that the information items produced during the requirements engineering activities
conform to the content requirements defined in this International Standard.
The requirements for information items in this International Standard are contained in Clause 7. The
requirements for the content of information items in this International Standard are contained in Clause 9 and
Annex A.
NOTE 1 If a user of this International Standard claims full conformance to ISO/IEC/IEEE 15289, it does not imply that
the user may claim conformance to the information items and information item content in this International Standard. The
reason is that this International Standard adds additional information items.
NOTE 2 In this International Standard, for simplicity of reference, each information item is described as if it were
published as a separate document. However, information items will be considered as conforming if they are unpublished
but available in a repository for reference, divided into separate documents or volumes, or combined with other information
items into one document.
2.4 Full conformance
A claim of full conformance to this International Standard is equivalent to claiming conformance
 to the provisions contained in subclauses 5.2.4, 5.2.5, 5.2.6, and 5.2.7,
 to the requirements-engineering-related processes of ISO/IEC 15288:2008 (IEEE Std 15288-2008) and
ISO/IEC 12207:2008 (IEEE Std 12207-2008) cited in subclause 6.1,
 to the information items cited in Clause 7, and
 to the content requirements of the information items in Clause 9 and Annex A.
2.5 Tailored conformance
2.5.1 Processes
This International Standard does not make provision for tailoring processes. ISO/IEC 15288:2008
(IEEE Std 15288-2008), Annex A provides normative direction regarding the tailoring of system life cycle
processes. ISO/IEC 12207:2008 (IEEE Std 12207-2008), Annex A provides normative direction regarding the
tailoring of software life cycle processes.
© ISO/IEC 2011 – All rights reserved
© IEEE 2011 – All rights reserved

2.5.2 Information items
When this International Standard is used as a basis for establishing a set of information items that do not
qualify for full conformance, the clauses of this International Standard are selected or modified in accordance
with the tailoring process prescribed in Annex D. The tailored text, for which tailored conformance is claimed,
is declared. Tailored conformance is achieved by demonstrating that requirements for the information items,
as tailored, have been satisfied using the outcomes of the tailoring process as evidence.
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.
ISO/IEC 12207:2008 (IEEE Std 12207-2008), Systems and software engineering — Software life cycle
processes
ISO/IEC 15288:2008 (IEEE Std 15288-2008), Systems and software engineering — System life cycle
processes
ISO/IEC/IEEE 15289:2011, Systems and software engineering — Content of life-cycle information products
(documentation)
4 Terms, definitions and abbreviated terms
4.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 15288, ISO/IEC 12207 and the
following apply.
4.1.1
acquirer
stakeholder that acquires or procures a product or service from a supplier
[ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008 (IEEE Std 12207-2008)]
NOTE Other terms commonly used for an acquirer are buyer, customer, owner, and purchaser.
4.1.2
attribute
inherent property or characteristic of an entity that can be distinguished quantitatively or qualitatively by
human or automated means
[ISO/IEC 25000:2005]
NOTE ISO 9000 distinguishes two types of attributes: a permanent characteristic existing inherently in something;
and an assigned characteristic of a product, process, or system (e.g. the price of a product, the owner of a product).
4.1.3
baseline
specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis
for further development, and that can be changed only through formal change control procedures
[ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008 (IEEE Std 12207-2008)]
© ISO/IEC 2011 – All rights reserved
© IEEE 2011 – All rights reserved

4.1.4
concept of operations
verbal and graphic statement, in broad outline, of an organization's assumptions or intent in regard to an
operation or series of operations
[ANSI/AIAA G-043-1992]
NOTE 1 The concept of operations frequently is embodied in long-range strategic plans and annual operational plans.
In the latter case, the concept of operations in the plan covers a series of connected operations to be carried out
simultaneously or in succession. The concept is designed to give an overall picture of the organization operations. See
also operational concept.
NOTE 2 It provides the basis for bounding the operating space, system capabilities, interfaces and operating
environment.
4.1.5
condition
measurable qualitative or quantitative attribute that is stipulated for a requirement
4.1.6
constraint
externally imposed limitation on system requirements, design, or implementation or on the process used to
develop or modify a system
NOTE A constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify the
design changes.
4.1.7
customer
organization or person that receives a product or service
[ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008 (IEEE Std 12207-2008)]
NOTE Customers are a subset of stakeholders.
4.1.8
derived requirement
requirement deduced or inferred from the collection and organization of requirements into a particular system
configuration and solution
4.1.9
developer
organization that performs development tasks (including requirements analysis, design, testing through
acceptance) during a life cycle process
[ISO/IEC 12207:2008 (IEEE Std 12207-2008)]
NOTE Developers are a subset of stakeholders.
4.1.10
document
uniquely identified unit of information for human use, such as a report, specification, manual or book in printed
or electronic form
[ISO/IEC 15289:2006]
© ISO/IEC 2011 – All rights reserved
© IEEE 2011 – All rights reserved

4.1.11
human systems integration
interdisciplinary technical and management process for integrating human considerations with and across all
system elements, an essential enabler to systems engineering practice
NOTE Adapted from INCOSE SEHbk 3.2:2010.
4.1.12
level of abstraction
view of an object at a specific level of detail
4.1.13
mode
set of related features or functional capabilities of a product
[IEEE Std 1362-1998]
4.1.14
operational concept
verbal and graphic statement of an organization's assumptions or intent in regard to an operation or series of
operations of a system or a related set of systems
[ANSI/AIAA G-043-1992]
NOTE The operational concept is designed to give an overall picture of the operations using one or more specific
systems, or set of related systems, in the organization's operational environment from the users' and operators'
perspective. See also concept of operations.
4.1.15
operational scenario
description of an imagined sequence of events that includes the interaction of the product or service with its
environment and users, as well as interaction among its product or service components
NOTE Operational scenarios are used to evaluate the requirements and design of the system and to verify and
validate the system.
4.1.16
operator
entity that performs the operations of a system
[ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008 (IEEE Std 12207-2008)]
NOTE The role of operator and the rule of user may be vested, simultaneously or sequentially, in the same individual
or organization.
4.1.17
requirement
statement which translates or expresses a need and its associated constraints and conditions
NOTE Requirements exist at different tiers and express the need in high-level form (e.g. software component
requirement).
4.1.18
requirements elicitation
process through which the acquirer and the suppliers of a system discover, review, articulate, understand, and
document the requirements on the system and the life cycle processes
NOTE Adapted from ISO/IEC/IEEE 24765:2010.
© ISO/IEC 2011 – All rights reserved
© IEEE 2011 – All rights reserved

4.1.19
requirements engineering
interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and
maintain the requirements to be met by the system, software or service of interest
NOTE Requirements engineering is concerned with
...