ISO/IEC/IEEE FDIS 21840

• Abstract:

  This document provides guidance on the application of processes in ISO/IEC/IEEE 15288 to systems of systems (SoS). The scope of this document is the same as ISO/IEC/IEEE 15288, which addresses more than systems engineering activities. NOTE 1 Throughout the document, there is mixed use of "system of systems" and "systems of systems". "SoS" could refer to a system of systems or systems of systems. Similarly, "CS" could refer to a constituent system or constituent systems. This document provides general guidance for each ISO/IEC/IEEE 15288 process and process outcome in the context of SoS, but it does not address specific activities, tasks, methods, or procedures. Additional processes and process outcomes unique to SoS can still be needed and are not covered by this document. This document explores the similarities and differences between systems and SoS and, by extension, the similarities and differences between engineering of systems and SoS. The guidance contained in this document is expected to evolve as the discipline matures. NOTE 2 In many cases, this document notes that ISO/IEC/IEEE 15288 processes or process outcomes "? applies as stated to SoS." Some interpretation within the context of SoS can still be needed.

• Status: Not Published
• 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 7 - Life cycle management
• Current Stage: 5060 - Close of voting Proof returned by Secretariat
• Start Date: 17-Jun-2026
• Completion Date: 16-Jun-2026

• Revises: ISO/IEC/IEEE 21840:2019 - Systems and software engineering — Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS)
• Effective Date: 12-Jul-2025

Overview

ISO/IEC/IEEE FDIS 21840: Systems and Software Engineering - Guidelines for the Utilization of ISO/IEC/IEEE 15288 in the Context of System of Systems (SoS) is an international standard developed by ISO and IEEE. This document delivers essential guidance on applying the ISO/IEC/IEEE 15288 system life cycle processes to the specialized context of systems of systems (SoS). As complex, large-scale networks of independent systems become integral to modern industries-from healthcare and transportation to energy and defense-this standard helps organizations better understand, manage, and govern SoS.

ISO/IEC/IEEE 21840 does not prescribe specific tasks or methods for SoS engineering but provides high-level guidance to support consistent, effective process adoption where multiple autonomous systems interact to create a unique capability.

Key Topics

• Differences Between Systems and Systems of Systems (SoS):
  The standard clarifies that while both "systems" and "systems of systems" involve interacting components, SoS are characterized by the managerial and operational independence of their constituent systems (CS). These constituent systems remain capable, managed, and operated independently, yet participate collectively in delivering emergent capabilities not achievable by any single system alone.

• SoS Types and Governance:
  ISO/IEC/IEEE 21840 outlines several SoS types, such as acknowledged, collaborative, directed, and virtual SoS, each with unique ownership, management, and autonomy structures. The guidance addresses how governance, stakeholder management, and strategic objectives differ from traditional systems engineering approaches.

• Application of ISO/IEC/IEEE 15288 Processes:
  The document provides general advice on interpreting and applying the processes and outcomes described in ISO/IEC/IEEE 15288 in SoS scenarios. This includes:

  • Agreement and organizational project-enabling processes
  • Technical management processes, such as risk management and configuration management
  • Technical processes including requirements definition, integration, verification, validation, operation, and maintenance.

• Emergence and Complexity:
  An SoS demonstrates "emergent behavior," meaning the whole exhibits properties or delivers results not attributable to any part alone. The standard emphasizes the challenges of engineering for desired emergence and managing unintended effects inherent in SoS operation.

Applications

Organizations and practitioners in systems engineering and software engineering use ISO/IEC/IEEE 21840 to:

• Harmonize Process Implementation:
  Ensure consistent application of life cycle management processes across a range of autonomous, interacting systems.

• Support Collaboration and Governance:
  Manage relationships between independent system owners and align their objectives, resources, and responsibilities at the SoS level.

• Facilitate Communication:
  Enable effective communication among a diverse set of stakeholders involved in SoS governance, engineering, operations, and management-especially when coupled with supporting standards like ISO/IEC/IEEE 21841 for SoS taxonomy.

• Adapt and Tailor Systems Engineering Practices:
  Modify established engineering processes to fit the unique needs and challenges posed by SoS, including evolving requirements, dynamic boundaries, and emergent behaviors.

Typical application domains include:

• Smart cities and urban mobility
• Healthcare infrastructure networks
• National defense and security systems
• Energy and utility grids
• Large-scale enterprise or government IT ecosystems

Related Standards

• ISO/IEC/IEEE 15288:
  Fundamental standard for system life cycle processes, serving as the foundation for ISO/IEC/IEEE 21840.
• ISO/IEC/IEEE 24748-1 & 24748-2:
  Guide on system life cycle models and interpretation issues relevant to SoS and their constituent systems.
• ISO/IEC/IEEE 21839:
  Provides considerations for the life cycle stages of a system-of-interest that is an SoS.
• ISO/IEC/IEEE 21841:
  Supplies a taxonomy for systems of systems, facilitating alignment with stakeholder viewpoints and improving communication in SoS environments.

ISO/IEC/IEEE FDIS 21840 is a valuable resource for any organization or project seeking to apply robust systems and software engineering processes to complex, interconnected, and independently managed systems. By following its guidelines, stakeholders can better realize the potential that systems of systems offer in today's interconnected world.

DRAFT
International
Standard
ISO/IEC/IEEE
DIS
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — Guidelines for the
Voting begins on:
utilization of ISO/IEC/IEEE 15288
2025-09-11
in the context of system of systems
Voting terminates on:
(SoS)
2025-12-04
Ingénierie des systèmes et du logiciel — Lignes directrices pour
l'utilisation de l'ISO/IEC/IECC 15288 dans le contexte d'un
système de systèmes (SdS)
ICS: 35.080
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
This document has not been edited by the ISO Central Secretariat.
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
© ISO/IEC 2025
ISO/IEC/IEEE DIS 21840:2025(en)
© IEEE 2025
DRAFT
ISO/IEC/IEEE DIS 21840:2025(en)
International
Standard
ISO/IEC/IEEE
DIS
ISO/IEC JTC 1/SC 7
Systems and software engineering —
Secretariat: BIS
Guidelines for the utilization of ISO/
Voting begins on:
IEC/IEEE 15288 in the context of
system of systems (SoS)
Voting terminates on:
Ingénierie des systèmes et du logiciel — Lignes directrices pour
l'utilisation de l'ISO/IEC/IECC 15288 dans le contexte d'un
système de systèmes (SdS)
ICS: 35.080
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
© ISO/IEC 2025
BEING ACCEPTABLE FOR INDUSTRIAL,
© IEEE 2025
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
This document has not been edited by the ISO Central Secretariat. BE CONSIDERED IN THE LIGHT OF THEIR
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the
POTENTIAL TO BECOME STANDARDS TO
respective address below or ISO’s member body in the country of the requester.
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva NY 10016-5997, USA
NOTIFICATION OF ANY RELEVANT PATENT
Phone: [phone]
RIGHTS OF WHICH THEY ARE AWARE AND TO
Email: [e-mail] Email: [e-mail]
PROVIDE SUPPORTING DOCUMENTATION.
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
Reference number
© ISO/IEC 2025
ISO/IEC/IEEE DIS 21840:2025(en)
© IEEE 2025
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ii
ISO/IEC/IEEE DIS 21840:2025(en)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative References . 1
3 Terms, definitions, and abbreviated terms . 1
3.1 General terms .1
3.2 SoS types .3
3.3 Abbreviated terms .4
4 Relationship to other standards . 4
5 Key concepts and application . 5
5.1 Differences between systems and SoS .5
5.2 Managerial and operational independence .8
6 Application of system life cycle processes to SoS .11
6.1 Agreement processes .11
6.1.1 General .11
6.1.2 Acquisition process . 12
6.1.3 Supply process .14
6.2 Organizational project-enabling processes . 15
6.2.1 General . 15
6.2.2 Life cycle model management process .16
6.2.3 Infrastructure management process .17
6.2.4 Portfolio management process .18
6.2.5 Human resource management process .19
6.2.6 Quality management process . 20
6.2.7 Knowledge management process .21
6.3 Technical management processes . 22
6.3.1 General . 22
6.3.2 Project planning process . . . 22
6.3.3 Project assessment and control process .24
6.3.4 Decision management process. 25
6.3.5 Risk management process . 26
6.3.6 Configuration management process .27
6.3.7 Information management process . 28
6.3.8 Measurement process . 29
6.3.9 Quality assurance process . 29
6.4 Technical processes . . 30
6.4.1 General . 30
6.4.2 Business or mission analysis process .31
6.4.3 Stakeholder needs and requirements definition process . 33
6.4.4 System requirements definition process. 35
6.4.5 System architecture definition process . 36
6.4.6 Design definition process . 38
6.4.7 System analysis process . 40
6.4.8 Implementation process .41
6.4.9 Integration process .42
6.4.10 Verification process .43
6.4.11 Transition process . 44
6.4.12 Validation process . 46
6.4.13 Operation process .47
6.4.14 Maintenance process . 48
6.4.15 Disposal process . 49
Bibliography .52

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
iii
ISO/IEC/IEEE DIS 21840:2025(en)
IEEE notices and abstract .53

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
iv
ISO/IEC/IEEE DIS 21840:2025(en)
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 ISO documents should be noted. This document was drafted in accordance with the rules given in the ISO/
IEC Directives, Part 2 (see www.iso.org/directives).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of
IEEE or IEEE SA and participate without compensation from IEEE. While IEEE administers the process and
establishes rules to promote fairness in the consensus development process, IEEE does not independently
evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained
in its standards.
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, Systems and software engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
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.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 21840:2019), which has
been technically revised to include updates to ISO/IEC/IEEE 15288, ISO/IEC/IEEE 24748-1, and
ISO/IEC/IEEE 24748-2.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
v
ISO/IEC/IEEE DIS 21840:2025(en)
Introduction
Application of systems engineering to systems of systems has become increasingly important for the
realization and sustainability of large and persistent sociotechnical systems in domains as varied as
healthcare, transportation, energy, and defence, and contexts such as corporations, cities, and government.
This has been intensified in the last twenty years by the pervasiveness of information technology (IT),
illustrated by new technologies and paradigms such as Sensor Networks, Cloud Computing, the Internet
of Things, Big Data, Smart Devices and Ambient Intelligence. It is, for instance, the application of these
technologies to cities that transform them into smarter cities.
This document provides guidance for the utilization of ISO/IEC/IEEE 15288 in the context of SoS. While
ISO/IEC/IEEE 15288 applies to systems in general (including constituent systems), this document provides
guidance on the application of these processes to the special case of SoS. However, ISO/IEC/IEEE 21840
is not a self-contained SoS replacement for ISO/IEC/IEEE 15288. This document is intended to be used in
conjunction with ISO/IEC/IEEE 15288, ISO/IEC/IEEE 21839 and ISO/IEC/IEEE 21841 and is not intended to
be used without them.
For example, ISO/IEC/IEEE 21841 provides a taxonomy for SoS, providing specific viewpoints that
align with stakeholder concerns. Using a taxonomy in conjunction with this document facilitates better
communications among the various stakeholders that are involved in activities like governance, engineering,
operation, and management of these SoS. However, this document does not require the use of any specific
taxa in ISO/IEC/IEEE 21841.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
vi
DRAFT International Standard ISO/IEC/IEEE DIS 21840:2025(en)
Systems and software engineering — Guidelines for the
utilization of ISO/IEC/IEEE 15288 in the context of system of
systems (SoS)
1 Scope
This document provides guidance on the application of processes in ISO/IEC/IEEE 15288 to systems of
systems (SoS). The scope of this document is the same as ISO/IEC/IEEE 15288, which addresses more than
systems engineering activities.
NOTE 1 This document also can be productively applied by users of ISO/IEC/IEEE 12207.
NOTE 2 Throughout the document, there is mixed use of "system of systems" and "systems of systems". "SoS" can
refer to a system of systems or systems of systems. Similarly, "CS" can refer to a constituent system or constituent
systems.
This document provides general guidance for each ISO/IEC/IEEE 15288 process and process outcome in the
context of SoS, but it does not address specific activities, tasks, methods, or procedures. Additional processes
and process outcomes unique to SoS can still be needed and are not covered by this document.
This document explores the similarities and differences between systems and SoS and, by extension,
the similarities and differences between engineering of systems and SoS. The guidance contained in this
document is expected to evolve as the discipline matures.
2 Normative References
There are no normative references in this document.
3 Terms, definitions, and abbreviated terms
For the purposes of this document, the following terms and definitions apply.
ISO, IEC, and IEEE maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/
— IEC Electropedia: available at https:// www .electropedia .org/
— IEEE Standards Dictionary Online: available at: http:// dictionary .ieee .org
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software
Engineering Vocabulary) database and which is publicly accessible at www .computer .org/ sevocab.
3.1 General terms
3.1.1
capability
measure of capacity and the ability of an entity (system (3.1.9), person or organization) to achieve its
objectives
[SOURCE: ISO/IEC 19770-1:2017, 3.10, modified — Note 1 to entry has been removed.]

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
3.1.2
constituent system
CS
independent system (3.1.9) that forms part of a system of systems (SoS) (3.1.11)
Note 1 to entry: Constituent systems can be part of one or more SoS. Each constituent system is a useful system by
itself, having its own development, management (3.1.6), utilization, goals, and resources, but interacts within the SoS
to provide the unique capability (3.1.1) of the SoS.
Note 2 to entry: While CS operate independently from each other for their own purposes, they also operate
interdependently with each other and other elements to produce the SoS outputs. CS are never totally independent, since
they work interdependently when operating as part of the SoS. However, they are never totally subservient to the SoS.
Because CS have their own stakeholders and CS remain managerially independent, CS managers generally are not
motivated to make adjustments to address SoS-desired capabilities.
3.1.3
emergence
principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts
Note 1 to entry: These properties cannot be reduced or decomposed back down to the those of any individual
constituent system (3.1.2).
3.1.4
governance
process of establishing and enforcing strategic goals and objectives, organizational policies, and performance
parameters
3.1.5
life cycle
evolution of a system (3.1.9), product, service, project or other human-made entity from conception through
retirement
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.24]
3.1.6
management
system (3.1.9) of controls and processes required to achieve the strategic objectives set by the organization's
governing body
Note 1 to entry: Management is subject to the policy guidance and monitoring set through corporate governance
(3.1.4).
3.1.7
satisficing
decision technique that discards any alternative with an attribute value outside an acceptable range
3.1.8
stage
period within the life cycle (3.1.5) of an entity that relates to the state of its description or realization
Note 1 to entry: As used in this document, stages relate to major progress and achievement milestones of the entity
through its life cycle.
Note 2 to entry: Stages often overlap.
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.48]
3.1.9
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun,
e.g. aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym (e.g.
aircraft), though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services, and personnel required for operations and support to the degree
necessary for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]
3.1.10
system-of-interest
SoI
system (3.1.9) whose life cycle (3.1.5) is under consideration
Note 1 to entry: In this document, the system-of-interest is a system of systems (3.1.11).
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48, modified —Note 1 to entry has been added.]
3.1.11
system of systems
SoS
set of systems (3.1.9) and system elements that interact to provide a unique capability (3.1.1) that none of the
constituent systems (3.1.2) can accomplish on its own
Note 1 to entry: System elements can be necessary to facilitate interaction of the constituent systems in the system of
systems.
Note 2 to entry: A collection of systems is not always an SoS. The differences between a system and an SoS are not
in the structure of the parts, but rather in the behavioural and managerial independence of those parts. There is no
distinct boundary that separates systems from SoS, as the transition between the two is often gradual and context
dependent.
3.1.12
system of systems engineering
SoS engineering
process of planning, analysing, organizing, developing and integrating the capabilities of a mix of existing and
new systems (3.1.9), including inter-system infrastructure, facilities, and overarching processes into a system
of systems capability (3.1.1) that is greater than the sum of the capabilities of the constituent systems (3.1.2)
Note 1 to entry: SoSE also includes testing, modification, maintenance and other post-integration activities.
3.1.13
taxonomy
scheme that partitions a body of knowledge and defines the relationships among the pieces
[SOURCE: ISO/IEC/IEEE 26531:2023, 3.1.30]
3.2 SoS types
3.2.1
acknowledged system of systems
acknowledged SoS
SoS (3.1.11) with recognized objectives, a designated manager, and resources for the SoS
Note 1 to entry: Constituent systems (3.1.2) retain their independent ownership, objectives, funding, and development
and sustainment approaches. Changes in the systems (3.1.9) are based on cooperative agreements between the SoS
and the system.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
3.2.2
collaborative system of systems
collaborative SoS
SoS (3.1.11) in which constituent systems (3.1.2) interact more or less voluntarily to fulfil agreed-upon central
purposes
Note 1 to entry: Constituent systems collectively decide how to provide or deny service, thereby providing means of
enforcing and maintaining consistency.
3.2.3
directed system of systems
directed SoS
SoS (3.1.4) created and managed to fulfil specific purposes, and the constituent systems (3.1.2) are
subordinated to the SoS
Note 1 to entry: Constituent systems maintain an ability to operate independently; however, their normal operational
mode is subordinated to the central managed purpose.
3.2.4
virtual system of systems
virtual SoS
SoS (3.1.11) that lacks a central management (3.1.6) authority and a centrally-agreed-upon purpose for the SoS
Note 1 to entry: Large-scale behaviour emerges—and can be desirable—but this type of SoS relies on relatively
invisible mechanisms to maintain it.
Note 2 to entry: Virtual SoS are typically self-organizing.
3.3 Abbreviated terms
CS constituent system, constituent systems
SE systems engineering
SoI system-of-interest
SoS system of systems, systems of systems
SoSE system of systems engineering
4 Relationship to other standards
This document is part of a set of documents that are intended to be used together:
ISO/IEC/IEEE 15288 provides the fundamental basis for this document by establishing a model set of system
life cycle processes.
ISO/IEC/IEEE 24748-1 addresses life cycle models, including implications for SoS and CS participating in SoS.
ISO/IEC/IEEE 24748-2 provides guidance on the application of ISO/IEC/IEEE 15288, including implications
for SoS and CS participating in SoS.
ISO/IEC/IEEE 21839 addresses considerations in life cycle stages of a system-of-interest that is an SoS.
This document provides guidance on the use of ISO/IEC/IEEE 15288 in the context of SoS, including
considerations for how CS relate to each other within the SoS. However, the use of any specific taxonomy is
not required.
ISO/IEC/IEEE 21841 provides a taxonomy for SoS, providing specific viewpoints that align with
management and governance concerns. Using a taxonomy in conjunction with this document facilitates

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
better communications among the various stakeholders that are involved in activities like governance,
engineering, operation, and management of these SoS.
Figure 1 highlights the relationships between the SoS standards.
Figure 1 — Relationship between the SoS standards
5 Key concepts and application
5.1 Differences between systems and SoS
To apply the guidance in the document, it is necessary to understand the differences between systems and
[13]
SoS in which the CS are managerially and operationally independent. Figure 2 shows that an SoI consists of
system elements, some of which can be systems themselves. These systems also consist of system elements,
some of which can be systems and so on. ISO/IEC/IEEE 15288 can be applied to any of these systems. If SoS
were the same as systems, but just on a bigger scale, there would be little need for additional guidance.
It is important to note that a collection of systems is not always an SoS. For example, Figure 2 shows a
collection of systems and system elements, but is this an SoS?

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
NOTE This figure is adapted from ISO/IEC/IEEE 24748-1:2024, Figure 2.
Figure 2 — Overview of a system
It is not possible to determine from a hierarchy diagram if a collection of systems is an SoS. Rather than
being described in terms of hierarchies, SoS are often described as general networks as shown in Figure 3.
Figure 3 — Overview of an SoS
Within an SoS, each CS is an independent system that forms part of an SoS. CS can be part of one or more
SoS. Each CS is a useful system by itself, having its own development, management, utilization, goals, and
resources, but interacts within the SoS to provide the unique capability of the SoS.
The differences between a system and an SoS are not in the structure of the parts, but rather in the
behavioural and managerial independence of those parts. There is no distinct boundary that separates

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
systems from SoS, as the transition between the two is often gradual and context dependent. The differences
between systems and SoS (and between SE and SoSE) are complex. Table 1 describes examples of drivers of
SE compared with SoSE, while Table 2 and Table 3 describe some of the differences between systems and
SoS. These differences reflect the attributes or characteristics around which the guidance on the application
of ISO/IEC/IEEE 15288 to SoS are framed.
However, it is important to understand that characteristics differ between system and SoS and are not
mutually exclusive.
Table 1 — Example drivers of SE and SoSE
SE SoSE
Focus Single complex system Multiple integrated complex systems
Objective Optimization Satisficing, sustainment
Boundaries Static Dynamic
Problem Defined Emergent
Structure Hierarchical Network
Goals Unitary Pluralistic
Timeframe System life cycle Continuous
Centricity Platform Network
Tools Many Few
Management framework Established Various
NOTE This table is adapted from Reference [12].
Table 2 — Examples of differences between systems and SoS
Systems tend to have SoS tend to have
Multiple levels of stakeholders with mixed and possibly com-
A clear set of stakeholders
peting interests
Clear objectives and purpose Multiple and possibly contradictory objectives and purpose
Clear management structure and clear Disparate management structures with no clear
accountabilities accountability
Clear operational priorities, with escalation to Multiple, and sometimes different, operational priorities with
resolve priorities no clear escalation routes
Multiple lifecycles with elements being implemented
A single life cycle
asynchronously
Clear ownership with the ability to move resources
Multiple owners making individual resourcing decisions
between elements
NOTE This table is adapted from Reference [13].

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
Table 3 — Examples of attribute-specific differences between systems and SoS
Attribute System SoS
Autonomy is ceded by parts to grant Autonomy is retained and exercised by CS while
Autonomy
autonomy to the system. contributing to fulfilling the purpose of the SoS.
While some CS are directed or coerced to belong to
SoS, some CS can be unaware of the SoS. Some CS
Parts are akin to family members; they did not
choose to belong on a cost/benefits basis; also, to
Belonging choose themselves but came from
cause greater fulfilment of their own purposes, and
parents. Belonging of parts is in their nature.
because of belief in the
overarching SoS purpose.
Prescient design, along with parts, with high Dynamically supplied by CS with every
connectivity hidden in elements, and possibility of myriad connections between CS,
Connectivity
minimum connectivity among major possibly via a net-centric architecture, to enhance
subsystems. SoS capability.
Managed i.e. reduced or minimized by Increased diversity in SoS capability achieved by
modular hierarchy; parts’ diversity released autonomy, committed belonging, and
Diversity encapsulated to create a known discrete open connectivity.
module whose nature is to project simplicity
into the next level of the hierarchy.
Foreseen, both good and bad behaviour, and Enhanced by deliberately not being foreseen,
designed in or tested out as appropriate. though its crucial importance is, and by
Emergence creating an emergence capability climate, that can
support early detection and elimination of bad
behaviours.
NOTE This table is adapted from Reference [11].
5.2 Managerial and operational independence
SoS are characterized by managerial and operational independence of the constituent systems (CS), which
in many cases were developed and continue to support originally identified users concurrently with
users of the SoS. In other contexts, each CS itself is a SoI; its existence often predates the SoS, while its
characteristics were originally engineered to meet the needs of their initial users. As constituents of the SoS,
their consideration is expanded to encompass the larger needs of the SoS. This implies added complexity
particularly when the systems continue to evolve independently of the SoS. The CS also typically retain their
original stakeholders and governance mechanisms, which limits alternatives to address the needs of the SoS.
Emergence is a key characteristic of SoS – the unanticipated effects from the SoS attributed to the complex
interaction dynamics of the CS. In SoS, CS are intentionally considered in their combination, to obtain and
analyse outcomes not possible to obtain with the systems alone. The complexity of the CS and the fact they
can have been designed without regard to their role in the SoS, can result in new, unexpected behaviours.
Identifying and addressing unanticipated emergent results is a particular challenge in SoSE.
Applying SE to SoS aims to engineer the desired emergent behaviour and minimize the undesired emergent
behaviour - the anticipated effects are generally the reason for the SoS conceptualization.
[9]
Systems operate within a context of managerial control which is subject to governance. Organizations
govern a portfolio of programs through goals and objectives, subject to laws, regulations, and external
agreements such as contracts. Programs manage some number of projects to achieve those goals and
objectives.
An SoS comprises CS and other system elements that can be necessary to facilitate interaction of the CS in the
SoS. Relationships between CS and system elements affect the SoS. Systems that do not interact are not part
of an SoS as shown in Figure 4. Organization A owns System V which consumes inputs and produces outputs.
Likewise, Organization B owns System W which also consumes inputs and produces outputs. Systems have

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
capabilities. Outcomes can be partially or totally achieved when the system behaves. Because Systems V and
W do not interact, there is no SoS.
NOTE The terms "organization" and "owns" suggest that individual CS can reside in different companies or
enterprises. However, CS can reside within different organizational elements within a particular company or
enterprise.
Figure 4 — Systems that don’t interact are not part of an SoS
[13]
An essential characteristic is that CS within the SoS are operationally independent. That is, the CS can
(and do) operate independently to fulfil some number of purposes on their own, separate from the SoS.
However, an SoS is a set of systems and system elements that interact to provide a unique capability that
none of the CS can accomplish on its own as shown in Figure 5. Because the SoS provides unique capabilities
beyond those of the CS, the SoS can have unique inputs beyond inputs originally needed by the CS. Also,
while it is possible that the emergent capability is provided by one of the CS, this isn't necessarily the case.
Some SoS can provide outputs not conveyed by one of the CS.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
Figure 5 — A set of systems and system elements that interact to provide a unique capability
SoS add value through the unique SoS capabilities from the integration and sequencing capabilities of CS and
other elements in time and space. Consequently, SoS accommodate delivery of outputs to multiple consumers
that can have different priorities and expectations. While CS operate independently from each other for
their own purposes, they also operate interdependently with each other and other elements to produce the
SoS outputs. CS are never totally independent, since they work interdependently when operating as part
[10]
of the SoS. However, they are also never totally subservient to the SoS. Unlike a system, which has been
designed to fulfil a purpose and an expected quality of service, the quality of service provided by an SoS can
be subject to variation.
Another essential characteristic is that CS within the SoS are both managerially independent and
interdependent. Managerial independence suggests that the CS are likely to be managed by organizations
that retain some degree of independence even though they are interdependent while participating in SoS.
The implication is that these organizations can have goals and objectives for the CS that differ from those
of the SoS. If so, there is likely some degree of independence and interdependence of governance, as well as
some degree of independence and interdependence of management. Regardless of the means of managing
the organizations, alignment (or lack thereof) in the goals and objectives can affect the SoS. While some CS
are directed or coerced to belong to SoS, some CS can be unaware of the SoS. Some CS choose to belong on a
cost/benefits basis, also to cause greater fulfilment of their own purposes, and because of their belief in the
overarching SoS purpose.
Figure 6 highlights the various kinds of relationships for governance and management. Multiple projects
can be necessary to design, produce, and operate a system. SoS composed from some combination of
systems U, V, and W would need to address the operational independence of the systems and the managerial
independence of organizations.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
Figure 6 — Degree of operational and managerial independence varies
The processes from ISO/IEC/IEEE 15288 are applied in a highly iterative and concurrent manner. In some
cases, there can be “waves” of SoS revision. In other cases, SoS changes can occur continually, with many
processes operating on a continuous basis to implement evolutionary change. These complexities do not
invalidate ISO/IEC/IEEE 15288 or SE but rather form an alternative context for their application. The
descriptions of the use of the ISO/IEC/IEEE 15288 processes and outcomes should be reconsidered in light
of the alternative context.
Depending on the SoS governance independence, the potential achievement of process outcomes can align
with the SoS itself, selectively with one or more CS or both. However, CS can be unaware, unable or unwilling
to do anything to support an SoS. For example, CS participating in a virtual SoS can be unaware of their
participation. Even for directed SoS, CS remain operationally and managerially independent and can be
unable or unwilling to comply. Also, although this document assumes the use of ISO/IEC/IEEE 15288 for
the SoS, it is possible that CS organizations are unaware, unable or unwilling to use ISO/IEC/IEEE 15288 or
support the achievement of its outcomes.
Clause 6 provides general guidance in the context of SoS.
6 Application of system life cycle processes to SoS
6.1 Agreement processes
6.1.1 General
ISO/IEC/IEEE 15288’s agreement processes “define the activities necessary to establish an agreement
between two organizations. If the acquisition process is invoked, it provides the means for interacting
with a supplier. This may include products that are supplied for use as an operational system, services in

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21840:2025(en)
support of operational activities, or elements of a system being provided by a supplier. If the supply process
is invoked, it provides the means for an agreement for a product or service that is provided to the acquirer.”
(ISO/IEC/IEEE 15288:2023, 5.7.2)
Agreement processes can be important for SoS because they establish the modes of developmental and
managerial control among the organizations responsible for the SoS and the independent CS. CS, which
are acquired and managed by different organizations, often hold original objectives that do not align with
those of the SoS. Except perhaps in the directed SoS case, an SoS organization cannot task a CS organization
without their cooperation. In an acknowledged or collaborative SoS, these tasks are balanced against the
tasks of the CS as a SoI in its own right. For virtual SoS, agreement processes can be absent, informal or
considered only for analysis purposes.
Because CS exist already and are being used for other purposes, agreements between the CS and its
suppliers can already exist. Those agreements can be particularly important if the SoS expects the CS to
change to meet SoS needs. For example, if the SoS has the requirement for changes to CS, this can affect
existing agreements the CS has in place with its suppliers. However, depending on the degree of operational
or manageri
...

FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — Guidelines for the
Voting begins on:
utilization of ISO/IEC/IEEE 15288
2026-04-21
in the context of system of systems
Voting terminates on:
(SoS)
2026-06-16
Ingénierie des systèmes et du logiciel — Lignes directrices pour
l'utilisation de l'ISO/IEC/IEEE 15288 dans le contexte d'un
système de systèmes (SdS)
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number © ISO/IEC 2026
FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — Guidelines for the
Voting begins on:
utilization of ISO/IEC/IEEE 15288
in the context of system of systems
Voting terminates on:
(SoS)
Ingénierie des systèmes et du logiciel — Lignes directrices pour
l'utilisation de l'ISO/IEC/IEEE 15288 dans le contexte d'un
système de systèmes (SdS)
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
© ISO/IEC 2026
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© IEEE 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
respective address below or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
ISO copyright office Institute of Electrical and Electronics Engineers, Inc MADE IN NATIONAL REGULATIONS.
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: [phone]
Email: [e-mail] Email: [e-mail]
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
Reference number © ISO/IEC 2026
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative References . 1
3 Terms and definitions . 1
3.1 General terms .1
3.2 SoS types .4
4 Relationship to other standards . 5
5 Key concepts . 5
5.1 Differences between systems and SoS .5
5.2 Managerial and operational independence .7
6 Application of system life cycle processes to SoS .10
6.1 Agreement processes .10
6.1.1 General .10
6.1.2 Acquisition process .11
6.1.3 Supply process . 12
6.2 Organizational project-enabling processes . 13
6.2.1 General . 13
6.2.2 Life cycle model management process .14
6.2.3 Infrastructure management process . 15
6.2.4 Portfolio management process .16
6.2.5 Human resource management process .17
6.2.6 Quality management process .18
6.2.7 Knowledge management process .19
6.3 Technical management processes .19
6.3.1 General .19
6.3.2 Project planning process . . . 20
6.3.3 Project assessment and control process .21
6.3.4 Decision management process. 22
6.3.5 Risk management process . 23
6.3.6 Configuration management process . 23
6.3.7 Information management process .24
6.3.8 Measurement process . 25
6.3.9 Quality assurance process . 26
6.4 Technical processes . .27
6.4.1 General .27
6.4.2 Business or mission analysis process . 28
6.4.3 Stakeholder needs and requirements definition process . 29
6.4.4 System requirements definition process. 30
6.4.5 System architecture definition process .32
6.4.6 Design definition process . 33
6.4.7 System analysis process . 35
6.4.8 Implementation process . 35
6.4.9 Integration process . 36
6.4.10 Verification process .37
6.4.11 Transition process . 38
6.4.12 Validation process . 40
6.4.13 Operation process .41
6.4.14 Maintenance process .41
6.4.15 Disposal process .42
Bibliography .44
IEEE notices and abstract .45

© ISO/IEC 2026, © IEEE 2026 – 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.
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 or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of
IEEE or IEEE SA and participate without compensation from IEEE. While IEEE administers the process and
establishes rules to promote fairness in the consensus development process, IEEE does not independently
evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained
in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
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.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Systems and software engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 21840:2019), which has been
technically revised.
The main changes are as follows:
— the text has been updated to be aligned with ISO/IEC/IEEE 15288:2023, ISO/IEC/IEEE 21839,
ISO/IEC/IEEE 21841, ISO/IEC/IEEE 24748-1:2024, and ISO/IEC/IEEE 24748-2:2024.
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 2026, © IEEE 2026 – All rights reserved
iv
Introduction
Application of systems engineering (SE) to systems of systems (SoS) has become increasingly important
for the realization and sustainability of large and persistent sociotechnical systems in domains as varied as
healthcare, transportation, energy, and defence, and contexts such as corporations, cities, and government.
This has been intensified in the last twenty years by the pervasiveness of information technology (IT),
illustrated by new technologies and paradigms such as sensor networks, cloud computing, the internet
of things, big data, smart devices and artificial intelligence. It is, for instance, the application of these
technologies to cities that transform them into smarter cities.
This document provides guidance for the utilization of ISO/IEC/IEEE 15288 in the context of SoS. While
ISO/IEC/IEEE 15288 applies to systems in general, including constituent systems (CS), this document
provides guidance on the application of these processes to the special case of SoS. However, this document
is not a self-contained SoS replacement for ISO/IEC/IEEE 15288. This document is intended to be used in
conjunction with ISO/IEC/IEEE 15288, ISO/IEC/IEEE 21839 and ISO/IEC/IEEE 21841.
For example, ISO/IEC/IEEE 21841 provides a taxonomy for SoS, providing specific viewpoints that
align with stakeholder concerns. Using a taxonomy in conjunction with this document facilitates better
communications among the various stakeholders that are involved in activities like governance, engineering,
operation, and management of these SoS. However, this document does not require the use of any specific
taxa in ISO/IEC/IEEE 21841.
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
v
FINAL DRAFT International Standard ISO/IEC/IEEE FDIS 21840:2026(en)
Systems and software engineering — Guidelines for the
utilization of ISO/IEC/IEEE 15288 in the context of system of
systems (SoS)
1 Scope
This document provides guidance on the application of processes in ISO/IEC/IEEE 15288 to systems of
systems (SoS).
This document also can be productively applied by users of ISO/IEC/IEEE 12207.
This document provides general guidance for each ISO/IEC/IEEE 15288 process and process outcome in the
context of SoS, but it does not address specific activities, tasks, methods, or procedures. Additional processes
and process outcomes unique to SoS can still be needed and are not covered by this document.
This document explores the similarities and differences between systems and SoS and, by extension, the
similarities and differences between engineering of systems and SoS.
2 Normative References
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC, and IEEE maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/
— IEC Electropedia: available at https:// www .electropedia .org/
— IEEE Standards Dictionary Online: available at: http:// dictionary .ieee .org
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software
Engineering Vocabulary) database and which is publicly accessible at www .computer .org/ sevocab.
3.1 General terms
3.1.1
capability
measure of capacity and the ability of an entity (system (3.1.11), person or organization (3.1.8)) to achieve its
objectives
[SOURCE: ISO/IEC 19770-1:2017, 3.10, modified — Note 1 to entry has been removed.]

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.1.2
constituent system
CS
independent system (3.1.11) that forms part of a system of systems (SoS) (3.1.13)
Note 1 to entry: Constituent systems (CS) can be part of one or more SoS. Each CS is a useful system by itself, having
its own development, management (3.1.7), utilization, goals, and resources, but interacts within the SoS to provide the
unique capability (3.1.1) of the SoS.
Note 2 to entry: While CS operate independently from each other for their own purposes, they also operate
interdependently with each other and other system elements (3.1.12) to produce the SoS outputs. CS are never totally
independent, since they work interdependently when operating as part of the SoS. However, they are never totally
subservient to the SoS. CS have their own stakeholders and CS remain managerially and operationally independent;
managers of CS or CS projects can be unaware, unable or unwilling to make adjustments to address SoS-desired
capabilities (3.1.1).
3.1.3
emergence
principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its
parts
Note 1 to entry: These properties cannot be reduced or decomposed back down to the those of any individual
constituent system (3.1.2).
3.1.4
governance
practice of establishing and enforcing strategic goals and objectives, organizational policies, and
performance parameters
[SOURCE: ISO/IEC/IEEE 12207:—, 3.1.28]
3.1.5
interoperating system
system (3.1.11) that exchanges information with the system of interest (3.1.15) and uses the information that
has been exchanged
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.20]
3.1.6
life cycle
evolution of a system (3.1.11), product, service, project or other human-made entity from conception through
retirement
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.24]
3.1.7
management
system (3.1.11) of controls and processes required to achieve the strategic objectives set by the organization's
(3.1.8) governing body
Note 1 to entry: Management is subject to the policy guidance and monitoring set through corporate governance
(3.1.4).
3.1.8
organization
person or group of people that has its own functions with responsibilities, authorities, and relationships to
achieve its objectives
EXAMPLE Company, corporation, firm, enterprise, manufacturer, institution, charity, sole trader, association, or
parts or combination thereof.
[SOURCE: ISO 9000:2015, 3.2.1, modified — Notes to entry have been removed; EXAMPLE has been added.]

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.1.9
satisficing
decision-making strategy or selection approach that prioritizes sufficiency over optimization
3.1.10
stage
period within the life cycle (3.1.6) of an entity that relates to the state of its description or realization
Note 1 to entry: As used in this document, stages relate to major progress and achievement milestones of the entity
through its life cycle.
Note 2 to entry: Stages often overlap.
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.48]
3.1.11
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun,
e.g. aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym (e.g.
aircraft), though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services, and personnel required for operations and support to the degree
necessary for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]
3.1.12
system element
discrete part of a system (3.1.11) that can be implemented to fulfil specified requirements
EXAMPLE Hardware, software, data, humans, processes [e.g. processes for providing service to users, procedures
[e.g., operator instructions], facilities, materials, and naturally occurring entities or any combination.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.47]
3.1.13
system of systems
SoS
set of systems (3.1.11) and system elements (3.1.12) that interact to provide a unique capability (3.1.1) that
none of the constituent systems (3.1.2) can accomplish on its own
Note 1 to entry: System elements can be necessary to facilitate interaction of the constituent systems in the system of
systems.
Note 2 to entry: A collection of systems is not always an SoS. The differences between a system and an SoS are not
in the structure of the parts, but rather in the managerial and operational independence of those parts. There is no
distinct boundary that separates systems from SoS, as the transition between the two is often gradual and context
dependent.
3.1.14
system of systems engineering
SoSE
process of planning, analysing, organizing, developing and integrating the capabilities (3.1.1) of a mix
of existing and new systems (3.1.11), including inter-system infrastructure, facilities, and overarching
processes into a system of systems (SoS) (3.1.13) capability that is greater than the sum of the capabilities of
the constituent systems (3.1.2)
Note 1 to entry: SoSE also includes testing, modification, maintenance and other post-integration activities.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.1.15
system of interest
SoI
system (3.1.11) whose life cycle (3.1.6) is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48.]
3.1.16
systems engineering
transdisciplinary and integrative approach to enable the successful realization, use, and retirement
of engineered systems (3.1.11) using systems principles and concepts and scientific, technological and
management (3.1.7) methods
[SOURCE: INCOSE-TP-2020-002-06]
3.1.17
taxonomy
scheme that partitions a body of knowledge and defines the relationships among the parts
[SOURCE: ISO/IEC/IEEE 26531:2023, 3.1.30]
3.2 SoS types
3.2.1
acknowledged SoS
acknowledged system of systems
SoS (3.1.13) with recognized objectives, a designated manager, and resources
Note 1 to entry: Constituent systems (3.1.2) retain their independent ownership, objectives, funding, and development
and sustainment approaches. Changes in the systems (3.1.11) are based on cooperative agreements between the
managers of the SoS and the managers of the CS.
3.2.2
collaborative SoS
collaborative system of systems
SoS (3.1.13) in which constituent systems(CS) (3.1.2) operationally interact more or less voluntarily to fulfil
agreed-upon central purposes
Note 1 to entry: Managers of CS or CS projects collaboratively decide how to provide or deny service, thereby providing
means of enforcing and maintaining consistency.
3.2.3
directed SoS
directed system of systems
SoS (3.1.13) created and managed to fulfil specific purposes, with constituent systems (3.1.2) that are
subordinated to the SoS
Note 1 to entry: Constituent systems maintain an ability to operate independently; however, their normal operational
mode is subordinated to the central managed purpose.
3.2.4
virtual SoS
virtual system of systems
SoS (3.1.13) that lacks a central management (3.1.7) authority and a centrally-agreed-upon purpose
Note 1 to entry: Large-scale behaviour emerges – and can be desirable – but this type of SoS relies on relatively
invisible mechanisms to maintain it.
Note 2 to entry: Virtual SoS are typically self-organizing.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
4 Relationship to other standards
This document is part of a set of documents that are intended to be used together:
ISO/IEC/IEEE 15288 provides the fundamental basis for this document by establishing a model set of system
life cycle processes.
ISO/IEC/IEEE 24748-1 addresses life cycle models, including implications for SoS and CS participating in SoS.
ISO/IEC/IEEE 24748-2 provides guidance on the application of ISO/IEC/IEEE 15288, including implications
for SoS and CS participating in SoS.
ISO/IEC/IEEE 21839 addresses considerations in life cycle stages of a system of interest that is a constituent
system that forms a part of an SoS.
This document provides guidance on the use of ISO/IEC/IEEE 15288 in the context of SoS, including
considerations for how CS relate to each other within the SoS. However, the use of any specific taxonomy is
not required.
ISO/IEC/IEEE 21841 provides a taxonomy for SoS, providing specific viewpoints that align with
management and governance concerns. Using a taxonomy in conjunction with this document facilitates
better communications among the various stakeholders that are involved in activities like governance,
engineering, operation, and management of these SoS.
Figure 1 highlights the relationships between the SoS standards.
Figure 1 — Relationship between the SoS standards
5 Key concepts
5.1 Differences between systems and SoS
To apply the guidance in the document, it is necessary to understand the differences between systems and
[14]
SoS in which the CS are managerially and operationally independent . Figure 2 shows that an SoI consists of
system elements, some of which can be systems themselves. These systems also consist of system elements,

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
some of which can be systems and so on. ISO/IEC/IEEE 15288 can be applied to any of these systems. If SoS
were the same as systems, but just on a bigger scale, there would be little need for additional guidance.
It is important to note that a collection of systems is not always an SoS. For example, Figure 2 shows a
collection of systems and system elements.
NOTE This figure is adapted from ISO/IEC/IEEE 24748-1:2024, Figure 2.
Figure 2 — Overview of a system
It is not possible to determine from a hierarchy diagram if a collection of systems is an SoS. Rather than
being described in terms of hierarchies, SoS are often described as general networks as shown in Figure 3.
Figure 3 — Overview of an SoS
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Within an SoS, each CS is an independent system that forms part of an SoS. CS can be part of one or more
SoS. Each CS is a useful system by itself, having its own development, management, utilization, goals, and
resources, but interacts within the SoS to provide the unique capability of the SoS.
The differences between a system and an SoS are not in the structure of the parts, but rather in the managerial
and operational independence of those parts. There is no distinct boundary that separates systems from
SoS, as the transition between the two is often gradual and context dependent. The differences between
systems and SoS (and between SE and SoSE) are complex. Reference [13] describes examples of drivers of SE
compared with SoSE, while Table 1 and Reference [12] describe some of the differences between systems and
SoS. These differences reflect the attributes or characteristics around which the guidance on the application
of ISO/IEC/IEEE 15288 to SoS are framed.
However, it is important to understand that characteristics differ between system and SoS and are not
mutually exclusive.
Table 1 — Examples of differences between systems and SoS
Systems tend to have SoS tend to have
Multiple levels of stakeholders with mixed and possibly com-
A clear set of stakeholders
peting interests
Clear objectives and purpose Multiple and possibly contradictory objectives and purpose
Clear management structure and clear Disparate management structures with no clear
accountabilities accountability
Clear operational priorities, with escalation to Multiple, and sometimes different, operational priorities with
resolve priorities no clear escalation routes
Multiple lifecycles with elements being implemented
A single life cycle
asynchronously
Clear ownership with the ability to move resources
Multiple owners making individual resourcing decisions
between elements
NOTE This table is adapted from Reference [16].
5.2 Managerial and operational independence
SoS are characterized by managerial and operational independence of the constituent systems (CS), which
in many cases were developed and continue to support originally identified users concurrently with
users of the SoS. In other contexts, each CS itself is a SoI; its existence often predates the SoS, while its
characteristics were originally engineered to meet the needs of their initial users. As constituents of the SoS,
their consideration is expanded to encompass the larger needs of the SoS. This implies added complexity
particularly when the systems continue to evolve independently of the SoS. The CS also typically retain their
original stakeholders and governance mechanisms, which limits alternatives to address the needs of the
SoS.
Emergence is a key characteristic of SoS – the unanticipated effects from the SoS attributed to the complex
interaction dynamics of the CS. In SoS, CS are intentionally considered in their combination, to obtain and
analyse outcomes not possible to obtain with the systems alone. The complexity of the CS and the fact they
can have been designed without regard to their role in the SoS, can result in new, unexpected behaviours.
Identifying and addressing unanticipated emergent results is a particular challenge in SoSE.
Applying SE to SoS aims to engineer the desired emergent behaviour and minimize the undesired emergent
behaviour - the anticipated effects are generally the reason for the SoS conceptualization.
[ ]
Systems operate within a context of managerial control which is subject to governance 10 . Organizations
govern a portfolio of programs through goals and objectives, subject to laws, regulations, and external
agreements such as contracts. Programs manage some number of projects to achieve those goals and
objectives.
An SoS is composed of CS and other system elements that can be necessary to facilitate interaction of the CS
in the SoS. Relationships between CS and system elements affect the SoS. Systems that do not interact are
not part of an SoS as shown in Figure 4. Organization A owns System V which consumes inputs and produces

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
outputs. Likewise, Organization B owns System W which also consumes inputs and produces outputs.
Systems have capabilities. Outcomes can be partially or totally achieved when the system behaves. Because
Systems V and W do not interact, there is no SoS.
NOTE The terms "organization" and "owns" suggest that individual CS can reside in different companies or
enterprises. However, CS can reside within different organizational elements within a particular company or
enterprise.
Figure 4 — Systems that don’t interact are not part of an SoS
[ ]
An essential characteristic is that CS within the SoS are operationally independent 14 . That is, the CS can
(and do) operate independently to fulfil some number of purposes on their own, separate from the SoS.
However, an SoS is a set of systems and system elements that interact to provide a unique capability that
none of the CS can accomplish on its own as shown in Figure 5. Because the SoS provides unique capabilities
beyond those of the CS, the SoS can have unique inputs beyond inputs originally needed by the CS. Also,
while it is possible that the emergent capability is provided by one of the CS, this isn't necessarily the case.
Some SoS can provide outputs not conveyed by one of the CS.
Figure 5 — A set of systems and system elements that interact to provide a unique capability
SoS add value through the unique SoS capabilities from the integration and sequencing capabilities of CS and
other elements in time and space. Consequently, SoS accommodate delivery of outputs to multiple consumers
that can have different priorities and expectations. While CS operate independently from each other for
their own purposes, they also operate interdependently with each other and other elements to produce the
SoS outputs. CS are never totally independent, since they work interdependently when operating as part
[11]
of the SoS. However, they are also never totally subservient to the SoS . Unlike a system, which has been

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
designed to fulfil a purpose and an expected quality of service, the quality of service provided by an SoS can
be subject to variation.
Another essential characteristic is that CS within the SoS are both managerially independent and
interdependent. Managerial independence suggests that the CS are likely to be managed by organizations
that retain some degree of independence even though they are interdependent while participating in SoS.
The implication is that these organizations can have goals and objectives for the CS that differ from those
of the SoS. If so, there is likely some degree of independence and interdependence of governance, as well as
some degree of independence and interdependence of management. Regardless of the means of managing
the organizations, alignment (or lack thereof) in the goals and objectives can affect the SoS. While some
CS are directed or coerced to belong to SoS, some managers of CS or CS projects can be unaware of the SoS.
Some managers of CS choose to belong on a cost/benefits basis, also to cause greater fulfilment of their own
purposes, and because of their belief in the overarching SoS purpose.
Figure 6 highlights the various kinds of relationships for governance and management. Multiple projects can
be necessary to design, produce, and operate a system. SoS composed from some combination of systems U,
V, and W should address the operational independence of the systems and the managerial independence of
organizations.
Figure 6 — Degree of operational and managerial independence varies
The processes from ISO/IEC/IEEE 15288 are applied in a highly iterative and concurrent manner. In some
cases, there can be “waves” of SoS revision. In other cases, SoS changes can occur continually, with many
processes operating on a continuous basis to implement evolutionary change. These complexities do not
invalidate ISO/IEC/IEEE 15288 or SE but rather form an alternative context for their application. The
descriptions of the use of the ISO/IEC/IEEE 15288 processes and outcomes should be reconsidered in light
of the alternative context.
Depending on the degree of governance or managerial independence of the SoS and the CS, the potential
achievement of process outcomes can align with the SoS itself, selectively with one or more CS or both.
However, managers of CS or CS projects can be unaware, unable or unwilling to do anything to support an
SoS. For example, CS participating in a virtual SoS can be unaware of their participation. Even for directed
SoS, CS remain operationally and managerially independent and can be unaware, unable or unwilling to
comply. Also, although this document assumes the use of ISO/IEC/IEEE 15288 for the SoS, it is possible that

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
CS organizations are unaware, unable or unwilling to use ISO/IEC/IEEE 15288 or support the achievement
of its outcomes.
Clause 6 provides general guidance on the application of ISO/IEC/IEEE 15288 system life cycle processes in
the context of SoS.
6 Application of system life cycle processes to SoS
6.1 Agreement processes
6.1.1 General
ISO/IEC/IEEE 15288’s agreement processes “define the activities necessary to establish an agreement
between two organizations. If the acquisition process is invoked, it provides the means for interacting
with a supplier. This may include products that are supplied for use as an operational system, services in
support of operational activities, or elements of a system being provided by a supplier. If the supply process
is invoked, it provides the means for an agreement for a product or service that is provided to the acquirer”
(ISO/IEC/IEEE 15288:2023, 5.7.2).
Agreement processes can be important for SoS because they establish the modes of developmental and
managerial control among the organizations responsible for the SoS and the independent CS. CS, which
are acquired and managed by different organizations, often hold original objectives that do not align with
those of the SoS. Except perhaps in the directed SoS case, an SoS organization cannot task a CS organization
without their cooperation. In an acknowledged or collaborative SoS, these tasks are balanced against the
tasks of the CS as a SoI in its own right. For virtual SoS, agreement processes can be absent, informal or
considered only for analysis purposes.
Because CS exist already and are being used for other purposes, agreements between the CS and its
suppliers can already exist. Those agreements can be particularly important if the SoS expects the CS to
change to meet SoS needs. For example, if the SoS has the requirement for changes to CS, this can affect
existing agreements the CS has in place with its suppliers. However, depending on the degree of operational
or managerial independence, CS are not necessarily obliged to acknowledge or adjust based on the SoS
requirements.
For some SoS, it is possible that the agreement processes do not apply at all, with no evidence of acquisition
or supply processes. In such cases, “agreement” can be considered in the conceptual sense only, in that
participating CS managers can form agreements among each other. In some cases, participating CS managers
can even be competing and conflicting with each other. In others, formal agreements can be absent.
In SoS, agreements can be needed when there are no existing authority arrangements between the SoS and
the CS. Agreements within SoS can be formal agreements, memoranda of agreement, or other less formal
agreements. Loose agreements can be more appropriate for non-critical elements, while tighter, more
formal agreements and associated processes can be appropriate for managing areas of higher risk or greater
criticality. However, CS can interact even without formal or explicit agreement.
ISO/IEC/IEEE 15288 does not contain processes addressing collaboration or competition. Collaboration
and competition involve independent action among the CS managers that facilitate collaboration or create
conflicting relationships among the CS managers and SoS manager (if any). These relationships result in
dynamic changes to the CS that modify the objectives, goals, and capabilities of the SoS.
Realizing a new SoS capability that is not supported by the existing CS requires some recognition of the need
for the new capability, and support for the need from the CS managers. Revised agreements for example,
can be needed to establish and maintain interoperability between CS. These agreements can be obtained
external to a typical SE span of control; however, application of SE processes can help influence reaching
suitable agreements. The obtainment of SoS capabili
...

ISO/IEC JTC 1/SC 7/WG 7 N10073
Secretariat: BIS
Date: 2026-01-1204-07
Systems and software engineering — Guidelines for the utilization of
ISO/IEC/IEEE 15288 in the context of system of systems (SoS)
Ingénierie des systèmes et du logiciel — Lignes directrices pour l'utilisation de l'ISO/IEC/IECCIEEE 15288 dans
le contexte d'un système de systèmes (SdS)
FDIS stage
© ISO/IEC/IEEE 2026
© IEEE 2026
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
or IEEE at the respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: + 41 22 749 01 11
Email: Email: E-mail: [e-mail]
Website: www.iso.org Website:
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
ii
Contents
Foreword . iv
Introduction . vi
1 Scope . 1
2 Normative References . 1
3 Terms and definitions . 1
3.1 General terms . 1
3.2 SoS types . 4
4 Relationship to other standards . 5
5 Key concepts . 7
5.1 Differences between systems and SoS . 7
5.2 Managerial and operational independence . 10
6 Application of system life cycle processes to SoS . 15
6.1 Agreement processes . 15
6.2 Organizational project-enabling processes . 19
6.3 Technical management processes . 28
6.4 Technical processes . 38
Bibliography . 62
IEEE notices and abstract . 63

© ISO/IEC 2026, © /IEEE 2026 – 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.
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 or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA and participate without compensation from IEEE. While IEEE administers the process and establishes
rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test,
or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
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.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Systems and software engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 21840:2019), which has been
technically revised.
The main changes are as follows:
© ISO/IEC 2025 – All rights reserved
iv
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
iv
— — the text has been updated to be aligned with ISO/IEC/IEEE 15288:2023, ISO/IEC/IEEE 21839:2026,
ISO/IEC/IEEE 21841:2026, ISO/IEC/IEEE 24748-1:2024, and ISO/IEC/IEEE 24748-2:2024.
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 2026, © /IEEE 2026 – All rights reserved
v
Introduction
Application of systems engineering (SE) to systems of systems (SoS) has become increasingly important for
the realization and sustainability of large and persistent sociotechnical systems in domains as varied as
healthcare, transportation, energy, and defence, and contexts such as corporations, cities, and government.
This has been intensified in the last twenty years by the pervasiveness of information technology (IT),
illustrated by new technologies and paradigms such as sensor networks, cloud computing, the internet of
things, big data, smart devices and artificial intelligence. It is, for instance, the application of these technologies
to cities that transform them into smarter cities.
This document provides guidance for the utilization of ISO/IEC/IEEE 15288 in the context of SoS. While
ISO/IEC/IEEE 15288 applies to systems in general, including constituent systems (CS), this document
provides guidance on the application of these processes to the special case of SoS. However, this document is
not a self-contained SoS replacement for ISO/IEC/IEEE 15288. This document is intended to be used in
conjunction with ISO/IEC/IEEE 15288, ISO/IEC/IEEE 21839 and ISO/IEC/IEEE 21841.
For example, ISO/IEC/IEEE 21841 provides a taxonomy for SoS, providing specific viewpoints that align with
stakeholder concerns. Using a taxonomy in conjunction with this document facilitates better communications
among the various stakeholders that are involved in activities like governance, engineering, operation, and
management of these SoS. However, this document does not require the use of any specific taxa in
ISO/IEC/IEEE 21841.
© ISO/IEC 2025 – All rights reserved
vi
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
vi
DRAFT International Standard ISO/IEC/IEEE FDIS 21840:2026(en)

Systems and software engineering — Guidelines for the utilization of
ISO/IEC/IEEE 15288 in the context of system of systems (SoS)
1 Scope
This document provides guidance on the application of processes in ISO/IEC/IEEE 15288 to systems of
systems (SoS).
This document also can be productively applied by users of ISO/IEC/IEEE 12207.
This document provides general guidance for each ISO/IEC/IEEE 15288 process and process outcome in the
context of SoS, but it does not address specific activities, tasks, methods, or procedures. Additional processes
and process outcomes unique to SoS can still be needed and are not covered by this document.
This document explores the similarities and differences between systems and SoS and, by extension, the
similarities and differences between engineering of systems and SoS.
2 Normative References
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC, and IEEE maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/
— — IEC Electropedia: available at https://www.electropedia.org/
— — IEEE Standards Dictionary Online: available at: http://dictionary.ieee.org
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software Engineering
Vocabulary) database and which is publicly accessible at www.computer.org/sevocab.
3.1 General terms
3.1.1
capability
measure of capacity and the ability of an entity (system (3.1.11(3.1.11),), person or organization
(3.1.8(3.1.8)))) to achieve its objectives
[SOURCE: ISO/IEC 19770-1:2017, 3.10, modified — Note 1 to entry has been removed.]
3.1.2
constituent system
CS
independent system (3.1.11(3.1.11)) that forms part of a system of systems (SoS) (3.1.13(3.1.13))
© ISO/IEC 2026, © IEEE 2026 – All rights reserved

Note 1 to entry: Constituent systems (CS) can be part of one or more SoS. Each CS is a useful system by itself, having its
own development, management (3.1.7(3.1.7),), utilization, goals, and resources, but interacts within the SoS to provide
the unique capability (3.1.1(3.1.1)) of the SoS.
Note 2 to entry: While CS operate independently from each other for their own purposes, they also operate
interdependently with each other and other system elements (3.1.12(3.1.12)) to produce the SoS outputs. CS are never
totally independent, since they work interdependently when operating as part of the SoS. However, they are never totally
subservient to the SoS. CS have their own stakeholders and CS remain managerially and operationally independent;
managers of CS or CS projects can be unaware, unable or unwilling to make adjustments to address SoS-desired
capabilities (3.1.1(3.1.1).).
3.1.3
emergence
principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its
parts
Note 1 to entry: These properties cannot be reduced or decomposed back down to the those of any individual constituent
system (3.1.2(3.1.2).).
3.1.4
governance
practice of establishing and enforcing strategic goals and objectives, organizational policies, and performance
parameters
[SOURCE: ISO/IEC/IEEE 12207:2026,:—, 3.1.28]
3.1.5
interoperating system
system (3.1.11(3.1.11)) that exchanges information with the system -of -interest (3.1.15(3.1.15)) and uses the
information that has been exchanged
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.20]
3.1.6
life cycle
evolution of a system (3.1.11(3.1.11),), product, service, project or other human-made entity from conception
through retirement
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.24]
3.1.7
management
system (3.1.11(3.1.11)) of controls and processes required to achieve the strategic objectives set by the
organization's (3.1.8(3.1.8)) governing body
Note 1 to entry: Management is subject to the policy guidance and monitoring set through corporate governance
(3.1.4(3.1.4).).
3.1.8
organization
person or group of people that has its own functions with responsibilities, authorities, and relationships to
achieve its objectives
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
EXAMPLE Company, corporation, firm, enterprise, manufacturer, institution, charity, sole trader, association, or
parts or combination thereof.
[SOURCE: ISO 9000:2015, 3.2.1, modified — Notes to entry have been removed; EXAMPLE has been added.]
3.1.9
satisficing
decision-making strategy or selection approach that prioritizes sufficiency over optimization
3.1.10
stage
period within the life cycle (3.1.6(3.1.6)) of an entity that relates to the state of its description or realization
Note 1 to entry: As used in this document, stages relate to major progress and achievement milestones of the entity
through its life cycle.
Note 2 to entry: Stages often overlap.
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.48]
3.1.11
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g.
aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym (e.g. aircraft),
though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services, and personnel required for operations and support to the degree necessary
for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]
3.1.12
system element
discrete part of a system (3.1.11(3.1.11)) that can be implemented to fulfil specified requirements
EXAMPLE Hardware, software, data, humans, processes [e.g. processes for providing service to users, procedures
[e.g., operator instructions], facilities, materials, and naturally occurring entities or any combination.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.47]
3.1.13
system of systems
SoS
set of systems (3.1.11(3.1.11)) and system elements (3.1.12(3.1.12)) that interact to provide a unique capability
(3.1.1(3.1.1)) that none of the constituent systems (3.1.2(3.1.2)) can accomplish on its own
Note 1 to entry: System elements can be necessary to facilitate interaction of the constituent systems in the system of
systems.
Note 2 to entry: A collection of systems is not always an SoS. The differences between a system and an SoS are not in the
structure of the parts, but rather in the managerial and operational independence of those parts. There is no distinct
boundary that separates systems from SoS, as the transition between the two is often gradual and context dependent.
© ISO/IEC 2026, © /IEEE 2026 – All rights reserved
3.1.14
system of systems engineering
SoSE
process of planning, analysing, organizing, developing and integrating the capabilities (3.1.1(3.1.1)) of a mix
of existing and new systems (3.1.11(3.1.11),), including inter-system infrastructure, facilities, and overarching
processes into a system of systems (SoS) (3.1.13(3.1.13)) capability that is greater than the sum of the
capabilities of the constituent systems (3.1.2(3.1.2))
Note 1 to entry: SoSE also includes testing, modification, maintenance and other post-integration activities.
3.1.15
system -of -interest
SoI
system (3.1.11(3.1.11)) whose life cycle (3.1.6(3.1.6)) is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48.]
3.1.16
systems engineering
transdisciplinary and integrative approach to enable the successful realization, use, and retirement of
engineered systems (3.1.11(3.1.11)) using systems principles and concepts and scientific, technological and
management (3.1.7(3.1.7)) methods
[SOURCE: INCOSE-TP-2020-002-06]
3.1.17
taxonomy
scheme that partitions a body of knowledge and defines the relationships among the parts
[SOURCE: ISO/IEC/IEEE 26531:2023, 3.1.30]
3.2 SoS types
3.2.1
acknowledged SoS
acknowledged system of systems
SoS (3.1.13(3.1.13)) with recognized objectives, a designated manager, and resources
Note 1 to entry: Constituent systems (3.1.2(3.1.2)) retain their independent ownership, objectives, funding, and
development and sustainment approaches. Changes in the systems (3.1.11(3.1.11)) are based on cooperative agreements
between the managers of the SoS and the managers of the CS.
3.2.2
collaborative SoS
collaborative system of systems
SoS (3.1.13(3.1.13)) in which constituent systems(CS) (3.1.2(3.1.2)) operationally interact more or less
voluntarily to fulfil agreed-upon central purposes
Note 1 to entry: Managers of CS or CS projects collaboratively decide how to provide or deny service, thereby providing
means of enforcing and maintaining consistency.
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
3.2.3
directed SoS
directed system of systems
SoS (3.1.13(3.1.13)) created and managed to fulfil specific purposes, with constituent systems (3.1.2(3.1.2))
that are subordinated to the SoS
Note 1 to entry: Constituent systems maintain an ability to operate independently; however, their normal operational
mode is subordinated to the central managed purpose.
3.2.4
virtual SoS
virtual system of systems
SoS (3.1.13(3.1.13)) that lacks a central management (3.1.7(3.1.7)) authority and a centrally-agreed-upon
purpose
Note 1 to entry: Large-scale behaviour emerges – and can be desirable – but this type of SoS relies on relatively invisible
mechanisms to maintain it.
Note 2 to entry: Virtual SoS are typically self-organizing.
4 Relationship to other standards
This document is part of a set of documents that are intended to be used together:
ISO/IEC/IEEE 15288 provides the fundamental basis for this document by establishing a model set of system
life cycle processes.
ISO/IEC/IEEE 24748-1 addresses life cycle models, including implications for SoS and CS participating in SoS.
ISO/IEC/IEEE 24748-2 provides guidance on the application of ISO/IEC/IEEE 15288, including implications
for SoS and CS participating in SoS.
ISO/IEC/IEEE 21839 addresses considerations in life cycle stages of a system -of -interest that is a constituent
system that forms a part of an SoS.
This document provides guidance on the use of ISO/IEC/IEEE 15288 in the context of SoS, including
considerations for how CS relate to each other within the SoS. However, the use of any specific taxonomy is
not required.
ISO/IEC/IEEE 21841 provides a taxonomy for SoS, providing specific viewpoints that align with management
and governance concerns. Using a taxonomy in conjunction with this document facilitates better
communications among the various stakeholders that are involved in activities like governance, engineering,
operation, and management of these SoS.
Figure 1Figure 1 highlights the relationships between the SoS standards.
© ISO/IEC 2026, © /IEEE 2026 – All rights reserved
Figure 1— Relationship between the SoS standards
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
5 Key concepts
5.1 Differences between systems and SoS
To apply the guidance in the document, it is necessary to understand the differences between systems and SoS
[14] [14]
in which the CS are managerially and operationally independent . Figure 2. Figure 2 shows that an SoI
consists of system elements, some of which can be systems themselves. These systems also consist of system
elements, some of which can be systems and so on. ISO/IEC/IEEE 15288 can be applied to any of these
systems. If SoS were the same as systems, but just on a bigger scale, there would be little need for additional
guidance.
It is important to note that a collection of systems is not always an SoS. For example, Figure 2Figure 2 shows
a collection of systems and system elements.

© ISO/IEC 2026, © /IEEE 2026 – All rights reserved
NOTE This figure is adapted from ISO/IEC/IEEE 24748-1:2024, Figure 2.
Figure 2— Overview of a system
It is not possible to determine from a hierarchy diagram if a collection of systems is an SoS. Rather than being
described in terms of hierarchies, SoS are often described as general networks as shown in Figure 3Figure 3.
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
Figure 3— Overview of an SoS
Within an SoS, each CS is an independent system that forms part of an SoS. CS can be part of one or more SoS.
Each CS is a useful system by itself, having its own development, management, utilization, goals, and resources,
but interacts within the SoS to provide the unique capability of the SoS.
The differences between a system and an SoS are not in the structure of the parts, but rather in the managerial
and operational independence of those parts. There is no distinct boundary that separates systems from SoS,
as the transition between the two is often gradual and context dependent. The differences between systems
and SoS (and between SE and SoSE) are complex. Reference[13] [13] describes examples of drivers of SE
compared with SoSE, while Table 1Table 1 and Reference [12][12] describe some of the differences between
systems and SoS. These differences reflect the attributes or characteristics around which the guidance on the
application of ISO/IEC/IEEE 15288 to SoS are framed.
However, it is important to understand that characteristics differ between system and SoS and are not
mutually exclusive.
© ISO/IEC 2026, © /IEEE 2026 – All rights reserved
Table 1— Examples of differences between systems and SoS
Systems tend to have SoS tend to have
Multiple levels of stakeholders with mixed and possibly
A clear set of stakeholders
competing interests
Clear objectives and purpose Multiple and possibly contradictory objectives and purpose
Clear management structure and clear Disparate management structures with no clear
accountabilities accountability
Clear operational priorities, with escalation to Multiple, and sometimes different, operational priorities with
resolve priorities no clear escalation routes
Multiple lifecycles with elements being implemented
A single life cycle
asynchronously
Clear ownership with the ability to move resources
Multiple owners making individual resourcing decisions
between elements
NOTE This table is adapted from Reference[16] [16].
5.2 Managerial and operational independence
SoS are characterized by managerial and operational independence of the constituent systems (CS), which in
many cases were developed and continue to support originally identified users concurrently with users of the
SoS. In other contexts, each CS itself is a SoI; its existence often predates the SoS, while its characteristics were
originally engineered to meet the needs of their initial users. As constituents of the SoS, their consideration is
expanded to encompass the larger needs of the SoS. This implies added complexity particularly when the
systems continue to evolve independently of the SoS. The CS also typically retain their original stakeholders
and governance mechanisms, which limits alternatives to address the needs of the SoS.
Emergence is a key characteristic of SoS – the unanticipated effects from the SoS attributed to the complex
interaction dynamics of the CS. In SoS, CS are intentionally considered in their combination, to obtain and
analyse outcomes not possible to obtain with the systems alone. The complexity of the CS and the fact they
can have been designed without regard to their role in the SoS, can result in new, unexpected behaviours.
Identifying and addressing unanticipated emergent results is a particular challenge in SoSE.
Applying SE to SoS aims to engineer the desired emergent behaviour and minimize the undesired emergent
behaviour - the anticipated effects are generally the reason for the SoS conceptualization.
[[10] [10]
Systems operate within a context of managerial control which is subject to governance . . Organizations
govern a portfolio of programs through goals and objectives, subject to laws, regulations, and external
agreements such as contracts. Programs manage some number of projects to achieve those goals and
objectives.
An SoS is composed of CS and other system elements that can be necessary to facilitate interaction of the CS
in the SoS. Relationships between CS and system elements affect the SoS. Systems that do not interact are not
part of an SoS as shown in Figure 4Figure 4. Organization A owns System V which consumes inputs and
produces outputs. Likewise, Organization B owns System W which also consumes inputs and produces
outputs. Systems have capabilities. Outcomes can be partially or totally achieved when the system behaves.
Because Systems V and W do not interact, there is no SoS.
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
NOTE The terms "organization" and "owns" suggest that individual CS can reside in different companies or
enterprises. However, CS can reside within different organizational elements within a particular company or enterprise.

Figure 4— Systems that don’t interact are not part of an SoS
[[14] [14]
An essential characteristic is that CS within the SoS are operationally independent . . That is, the CS can
(and do) operate independently to fulfil some number of purposes on their own, separate from the SoS.
However, an SoS is a set of systems and system elements that interact to provide a unique capability that none
of the CS can accomplish on its own as shown in Figure 5Figure 5. Because the SoS provides unique
capabilities beyond those of the CS, the SoS can have unique inputs beyond inputs originally needed by the CS.
Also, while it is possible that the emergent capability is provided by one of the CS, this isn't necessarily the
case. Some SoS can provide outputs not conveyed by one of the CS.
© ISO/IEC 2026, © /IEEE 2026 – All rights reserved
Figure 5— A set of systems and system elements that interact to provide a unique capability
SoS add value through the unique SoS capabilities from the integration and sequencing capabilities of CS and
other elements in time and space. Consequently, SoS accommodate delivery of outputs to multiple consumers
that can have different priorities and expectations. While CS operate independently from each other for their
own purposes, they also operate interdependently with each other and other elements to produce the SoS
outputs. CS are never totally independent, since they work interdependently when operating as part of the
[11] [11]
SoS. However, they are also never totally subservient to the SoS . . Unlike a system, which has been
designed to fulfil a purpose and an expected quality of service, the quality of service provided by an SoS can
be subject to variation.
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
Another essential characteristic is that CS within the SoS are both managerially independent and
interdependent. Managerial independence suggests that the CS are likely to be managed by organizations that
retain some degree of independence even though they are interdependent while participating in SoS. The
implication is that these organizations can have goals and objectives for the CS that differ from those of the
SoS. If so, there is likely some degree of independence and interdependence of governance, as well as some
degree of independence and interdependence of management. Regardless of the means of managing the
organizations, alignment (or lack thereof) in the goals and objectives can affect the SoS. While some CS are
directed or coerced to belong to SoS, some managers of CS or CS projects can be unaware of the SoS. Some
managers of CS choose to belong on a cost/benefits basis, also to cause greater fulfilment of their own
purposes, and because of their belief in the overarching SoS purpose.
Figure 6Figure 6 highlights the various kinds of relationships for governance and management. Multiple
projects can be necessary to design, produce, and operate a system. SoS composed from some combination of
systems U, V, and W should address the operational independence of the systems and the managerial
independence of organizations.
© ISO/IEC 2026, © /IEEE 2026 – All rights reserved
Figure 6— Degree of operational and managerial independence varies
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
The processes from ISO/IEC/IEEE 15288 are applied in a highly iterative and concurrent manner. In some
cases, there can be “waves” of SoS revision. In other cases, SoS changes can occur continually, with many
processes operating on a continuous basis to implement evolutionary change. These complexities do not
invalidate ISO/IEC/IEEE 15288 or SE but rather form an alternative context for their application. The
descriptions of the use of the ISO/IEC/IEEE 15288 processes and outcomes should be reconsidered in light of
the alternative context.
Depending on the degree of governance or managerial independence of the SoS and the CS, the potential
achievement of process outcomes can align with the SoS itself, selectively with one or more CS or both.
However, managers of CS or CS projects can be unaware, unable or unwilling to do anything to support an SoS.
For example, CS participating in a virtual SoS can be unaware of their participation. Even for directed SoS, CS
remain operationally and managerially independent and can be unaware, unable or unwilling to comply. Also,
although this document assumes the use of ISO/IEC/IEEE 15288 for the SoS, it is possible that CS organizations
are unaware, unable or unwilling to use ISO/IEC/IEEE 15288 or support the achievement of its outcomes.
Clause 6Clause 6 provides general guidance on the application of ISO/IEC/IEEE 15288 system life cycle
processes in the context of SoS.
6 Application of system life cycle processes to SoS
6.1 Agreement processes
6.1.1 General
ISO/IEC/IEEE 15288’s agreement processes “define the activities necessary to establish an agreement
between two organizations. If the acquisition process is invoked, it provides the means for interacting with a
supplier. This may include products that are supplied for use as an operational system, services in support of
operational activities, or elements of a system being provided by a supplier. If the supply process is invoked,
it provides the means for an agreement for a product or service that is provided to the acquirer”
(ISO/IEC/IEEE 15288:2023, 5.7.2).
Agreement processes can be important for SoS because they establish the modes of developmental and
managerial control among the organizations responsible for the SoS and the independent CS. CS, which are
acquired and managed by different organizations, often hold original objectives that do not align with those
of the SoS. Except perhaps in the directed SoS case, an SoS organization cannot task a CS organization without
their cooperation. In an acknowledged or collaborative SoS, these tasks are balanced against the tasks of the
CS as a SoI in its own right. For virtual SoS, agreement processes can be absent, informal or considered only
for analysis purposes.
Because CS exist already and are being used for other purposes, agreements between the CS and its suppliers
can already exist. Those agreements can be particularly important if the SoS expects the CS to change to meet
SoS needs. For example, if the SoS has the requirement for changes to CS, this can affect existing agreements
the CS has in place with its suppliers. However, depending on the degree of operational or managerial
independence, CS are not necessarily obliged to acknowledge or adjust based on the SoS requirements.
For some SoS, it is possible that the agreement processes do not apply at all, with no evidence of acquisition
or supply processes. In such cases, “agreement” can be considered in the conceptual sense only, in that
participating CS managers can form agreements among each other. In some cases, participating CS managers
can even be competing and conflicting with each other. In others, formal agreements can be absent.
In SoS, agreements can be needed when there are no existing authority arrangements between the SoS and
the CS. Agreements within SoS can be formal agreements, memoranda of agreement, or other less formal
agreements. Loose agreements can be more appropriate for non-critical elements, while tighter, more formal
agreements and associated processes can be appropriate for managing areas of higher risk or greater
criticality. However, CS can interact even without formal or explicit agreement.
© ISO/IEC 2026, © /IEEE 2026 – All rights reserved
ISO/IEC/IEEE 15288 does not contain processes addressing collaboration or competition. Collaboration and
competition involve independent action among the CS managers that facilitate collaboration or create
conflicting relationships among the CS managers and SoS manager (if any). These relationships result in
dynamic changes to the CS that modify the objectives, goals, and capabilities of the SoS.
Realizing a new SoS capability that is not supported by the existing CS requires some recognition of the need
for the new capability, and support for the need from the CS managers. Revised agreements for example, can
be needed to establish and maintain interoperability between CS. These agreements can be obtained external
to a typical SE span of control; however, application of SE processes can help influence reaching suitable
agreements. The obtainment of SoS capabilities requires interaction between the CS within the SoS. These
interactions can require agreements to establish and maintain interoperability among these systems. Used in
concert with Interface Management, the Agreement process can be used to establish and maintain technical
interface agreements between CS managers and maintainers.
6.1.2 Acquisition process
6.1.2.1 Purpose
The purpose of the acquisition process, ”"to obtain a product or service in accordance with the acquirer's
requirements” (ISO/IEC/IEEE 15288:2023, 6.1.1.1), applies to SoS with the following addition.
For an SoS, the organization (single or collaborative) for the SoS is the acquirer and the suppliers can be the
organizations that manage the CS. Organizations participating in the SoS would also have to coordinate any
system elements required by the SoS beyond the CS. Terms such as participant or "partner" can be more
applicable than acquirer and supplier.
In the context of SoS, an acquirer obtains the capabilities of CS, sometimes without explicit agreement, and
without acquiring the CS that produced the capabilities. The acquirer can still obtain system elements (i.e.
system elements that are not CS, or any system elements required by the SoS beyond the CS).
There can be the occasion where the functionality or interface behaviours for a CS require modification or an
expectation for coordinated changes to the CS. In these cases, applying SE supports the acquisition process by
defining the functional, performance or technical requirements allocated to each CS to support the capability
to be achieved by the SoS when these CS interact.
6.1.2.2 Outcomes
The outcomes of the acquisition process in ISO/IEC/IEEE 15288:2023, 6.1.1.2 apply as stated to SoS with the
following guidance:
a) a request for supply is prepared (ISO/IEC/IEEE 15288:2023, 6.1.1.2.a);
a) a request for supply is prepared (ISO/IEC/IEEE 15288:2023, 6.1.1.2.a);
It is possible that a request for supply by the organization that governs the SoS does not have the same
formality as can be expected within a system. Instead of a formal request for supply for specific products or
services, a search for specific capabilities or a request for information about existing and planned capabilities
can be made. In an SoS governance sense, a request for supply can only have or need partial influence on the
outcome. For example, there can be standards and rules for certain aspects of certain types of CS, but little
interest in definition of the full acquisition scope of that item. Things such as collaborative and informal
© ISO/IEC 2025 – All rights reserved
© IEEE 2025 – All rights reserved
© ISO/IEC/IEEE 2026 – All rights reserved
agreements and influencing by demonstrating potential mutual benefits (to both SoS governance and CS
suppliers) can apply.
b) one or more suppliers are selected (ISO/IEC/IEEE 15288:2023, 6.1.1.2.b);
b) one or more suppliers are selected (ISO/IEC/IEEE 15288:2023, 6.1.1.2.b);
In an SoS, the selection of suppliers or participants can occur in several ways. The SoS can identify and
negotiate the participation of a CS in an SoS. If the CS are managerially dependent, the selection of suppliers
can follow a path like that of conventional systems. If the CS are managerially independent, the CS likely would
decide for themselves. Rather than selecting suppliers, suppliers/candidate organizations can choose to
participate in the SoS (i.e. self-select), but at least in some cases, they can be able to do so only if they play by
the rules (established through the governance of the SoS) which can have some controls (e.g. are
accredited/meet criteria to be allowed to join the SoS context) or be uncontrolled (anyone can join, but the
integrated behaviour is uncertain or poor unless certain rules/minimum requirements are met).
c) an agreement is established between the acquirer and supplier (ISO/IEC/IEEE 15288:2023,
6.1.1.2.c);
c) an agreement is established between the acquirer and supplier (ISO/IEC/IEEE 15288:2023, 6.1.1.2.c);
In addition to formal approaches like contracts, less formal approaches such as memoranda of agreement and
memoranda of understanding can be effective in the management arrangements for some types of SoS. For
some types of SoS, though, agreements can be informal or tacit. Accepting terms of use for a product or service
is one type of agreement. Some types of SoS operate effectively even in the absence of agreements.
A supplier can be a freely available source of information, or an agreement can be already held (for example,
where the information is being used in a different context), with or without a formal agreement.
d) a product or service complying with the agreement is accepted (ISO/IEC/IEEE 15288:2023,
6.1.1.2.d);
d) a product or service complying with the agreement is accepted (ISO/IEC/IEEE 15288:2023, 6.1.1.2.d);
In the context of SoS, especially if the agreement approach is informal, "compliance" can mean something
different than in the context of systems, where agreements and means to compel compliance can be formal.
Within an SoS, especially in the absence of a formal agreement, acquirers can find that they have little leverage
over suppliers to deliver acceptable products and services on the anticipated schedule. Consequently,
acquirers should adjust their plans and processes to accommodate these realities. Obtaining or using an
existing CS to gain a product or service, and agreeing to its terms of use, is one type of acceptance.
Based on marketplace and trust, a CS can be trusted by an SoS customer to comply with appropriate standards
without explicit evidence of that compliance (e.g. a mobile phone). If the customer subsequently finds that the
CS fails in a way that shows the SoS customer that the CS is not compliant and has breached that trust, the SoS
customer can remove the CS from the SoS or seek additional means to gain the appropriate trust. This kind of
approach can work in non-critical environments; more critical environments with significant consequences
(risk) can demand more explicit up-front compliance.
e) acquirer obligations defined in the agreement are satisfied (ISO/IEC/IEEE 15288:2023, 6.1.1.2.e).
e) acquirer obligations defined in the
...