ISO/IEC/IEEE 21840:2019

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2019-12
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/IECC 15288 dans le contexte d'un système de
systèmes (SdS)
Reference number
©
ISO/IEC 2019
©
IEEE 2019
© ISO/IEC 2019
© IEEE 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO 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
Fax: +41 22 749 09 47
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2019 – All rights reserved
ii © IEEE 2019 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative References . 1
3 Terms, definitions, and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 3
4 Relationship to other standards . 3
5 Key concepts and application . 4
5.1 Differences between systems and SoS . 4
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 .12
6.1.3 Supply process .13
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 .20
6.2.6 Quality management process.21
6.2.7 Knowledge management process .22
6.3 Technical management processes .23
6.3.1 General.23
6.3.2 Project planning process .24
6.3.3 Project assessment and control process .25
6.3.4 Decision management process .27
6.3.5 Risk management process .28
6.3.6 Configuration management process .29
6.3.7 Information management process .30
6.3.8 Measurement process .31
6.3.9 Quality assurance process .32
6.4 Technical processes .33
6.4.1 General.33
6.4.2 Business or mission analysis process .36
6.4.3 Stakeholder needs and requirements definition process .37
6.4.4 System requirements definition process .39
6.4.5 Architecture definition process .41
6.4.6 Design definition process .44
6.4.7 System analysis process.46
6.4.8 Implementation process .47
6.4.9 Integration process .48
6.4.10 Verification process .49
6.4.11 Transition process .51
6.4.12 Validation process . . .52
6.4.13 Operation process .54
6.4.14 Maintenance process .55
6.4.15 Disposal process .56
Bibliography .58
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved iii

IEEE notices and abstract .59
© ISO/IEC 2019 – All rights reserved
iv © IEEE 2019 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of 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 the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of
the information contained in its standards.
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.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved v

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 defense, and contexts such as corporations, cities, and
government. This has been intensified in the last fifteen 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 2019 – All rights reserved
vi © IEEE 2019 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC/IEEE 21840:2019(E)
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 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.
2 Normative References
There are no normative references in this document.
3 Terms, definitions, and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
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.
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 http:// www .electropedia .org/
— IEEE Standards Dictionary Online: available at: http:// dictionary .ieee .org
3.1.1
capability
measure of capacity and the ability of an entity (system (3.1.8), 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 2019 – All rights reserved
© IEEE 2019 – All rights reserved 1

3.1.2
constituent system
independent system (3.1.8) that forms part of a system of systems (SoS) (3.1.10)
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.5), utilization, goals, and resources, but interacts within
the SoS to provide the unique capability (3.1.1) of the SoS.
[SOURCE: ISO/IEC/IEEE 21839:2019, 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).
Note 2 to entry: The definition is adapted from Reference [9].
3.1.4
governance
process of establishing and enforcing strategic goals and objectives, organizational policies, and
performance parameters
[SOURCE: ISO/IEC 24765:2017, 3.1757, modified — The article "the" at the beginning of the definition
has been removed.]
3.1.5
management
system (3.1.8) 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).
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2338]
3.1.6
satisficing
decision technique that discards any alternative with an attribute value outside an acceptable range
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3601]
3.1.7
stage
period within the life cycle 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 15288:2015, 4.1.43, modified — The expression "this International Standard"
has been replaced with "this document".]
3.1.8
system
combination of interacting elements organized to achieve one or more stated purposes
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.46, modified — Note 1, 2, and 3 to entry have been removed.]
© ISO/IEC 2019 – All rights reserved
2 © IEEE 2019 – All rights reserved

3.1.9
system-of-interest
system (3.1.8) whose life cycle is under consideration
Note 1 to entry: In this document, the system-of-interest is a system of systems (3.1.10).
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.48, modified — The words "in the context of this International
Standard" have been removed; Note 1 to entry has been added.]
3.1.10
system of systems
set of systems (3.1.8) 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.
[SOURCE: ISO/IEC/IEEE 21839:2019, 3.1.4, modified — The abbreviated term "SoS" has been removed.]
3.1.11
system life cycle
period that begins when a system (3.1.8) is conceived and ends when the system is no longer
available for use
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4108]
3.1.12
taxonomy
scheme that partitions a body of knowledge and defines the relationships among the pieces
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.4167, modified — Note 1 to entry has been removed.]
3.2 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 21839 addresses SoS considerations in life cycle stages of a system.
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 taxa in
ISO/IEC/IEEE 21841 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.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 3

Figure 1 highlights these relationships.
Figure 1 — Relationship between the 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
[11]
and SoS in which the CS are managerially and operationally independent . Figure 2 shows that an SOI
consists of system elements, some of which could be systems themselves. These systems also consist of
system elements, some of which could 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 may not be an SoS. For example, Figure 2 shows a
collection of systems and system elements, but is this an SoS?
© ISO/IEC 2019 – All rights reserved
4 © IEEE 2019 – All rights reserved

NOTE This figure is reproduced from ISO/IEC/IEEE 15288:2015, 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. These
additional attributes are what distinguish SoS from a collection of systems.
The differences between a system and an SoS are not in the physical or hierarchical structure of the
component parts, but rather in the behavioral and managerial characteristics of those parts. 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.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 5

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 [10].
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
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
resolve priorities with no clear escalation routes
Multiple lifecycles with elements being implemented
A single life cycle
asynchronously
Clear ownership with the ability to move re-
Multiple owners making individual resourcing decisions
sources between elements
NOTE  This table is adapted from Reference [11].
Table 3 — Examples of 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 could be unaware of the SoS.
Parts are akin to family members; they did
Some CS choose to belong on a cost/benefits
Belonging not choose themselves but came from
basis; also, to cause greater fulfillment of their
parents. Belonging of parts is in their nature.
own purposes, and 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 en-
subsystems. hance SoS capability.
NOTE  This table is adapted from Reference [8].
© ISO/IEC 2019 – All rights reserved
6 © IEEE 2019 – All rights reserved

Table 3 (continued)
Attribute System SoS
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 behavior, 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
will support early detection and elimination of
bad behaviors.
NOTE  This table is adapted from Reference [8].
5.2 Managerial and operational independence
ISO/IEC/IEEE 15288:2015, Annex G contains general information on SoS. Details of SoS characteristics
and types in ISO/IEC/IEEE 15288:2015, G.2 are shown in the box.
SoS are characterized by managerial and operational independence of the constituent systems, which
in many cases were developed and continue to support originally identified users concurrently with
users of the SoS. In other contexts, each constituent system 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 constituent systems 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 at the systems of systems level
attributed to the complex interaction dynamics of the constituent systems. In SoS, constituent
systems are intentionally considered in their combination, so as to obtain and analyze outcomes not
possible to obtain with the systems alone. The complexity of the constituent systems and the fact
they may have been designed without regard to their role in the SoS, can result in new, unexpected
behaviors. Identifying and addressing unanticipated emergent results is a particular challenge in
engineering SoS.
Applying SE to SoS aims to engineer the desired emergent behavior and minimize the undesired
emergent behavior - the anticipated effects are generally the reason for the SoS conceptualization.
[7]
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 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 could reside in different companies
or enterprises. However, CS could reside within different organizational elements within a particular company
or enterprise.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 7

Figure 4 — Systems that don’t interact are not part of an SoS
[11]
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 could 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 (and do) provide outputs not conveyed by one of the CS.
© ISO/IEC 2019 – All rights reserved
8 © IEEE 2019 – 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/or sequencing capabilities
of CS and other elements in time and space. Consequently, SoS accommodate delivery of outputs
to multiple consumers that could 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, yet they are also
[8]
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 could 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 will
affect the SoS. While some CS are directed or coerced to belong to SoS, some CS could be unaware of the
SoS. Some CS choose to belong on a cost/benefits basis, also to cause greater fulfillment 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 2019 – All rights reserved
© IEEE 2019 – All rights reserved 9

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 could be “waves” of SoS revision. In other cases, SoS changes could 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. 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:2015, 6.1 contains general information on the application of system life cycle
agreement processes to a system as shown in the box.
© ISO/IEC 2019 – All rights reserved
10 © IEEE 2019 – All rights reserved

This subclause specifies the requirements for the establishment of agreements with organizational
entities external and internal to the organization.
The Agreement Processes consist of the following:
a) Acquisition process – used by organizations for acquiring products or services;
b) Supply process – used by organizations for supplying products or services.
These processes define the activities necessary to establish an agreement between two organizations.
If the Acquisition process is invoked, it provides the means for conducting business 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 in which the result is a product or service that is
provided to the acquirer.
NOTE Security is an increasing concern in systems engineering. See ISO/IEC 27036, Security techniques
— Information security for supplier relationships, for requirements and guidance for suppliers and acquirers
on how to secure information in supplier relationships. Specific aspects of information security supplier
relationships are addressed in Parts 3 and Part 4.
ISO/IEC/IEEE 15288:2015, Annex G contains general information on the application of system life cycle
processes to SoS. Details of agreement processes in ISO/IEC/IEEE 15288:2015, G.3.2 are shown in the box.
Agreement Processes are crucial for SoS because they establish the modes of developmental and
operational control among the organizations responsible for the SoS and the often independent
constituent systems. Constituent systems, which are acquired and managed by different
organizations, often hold original objectives that may not align with those of the SoS. Except in the
directed SoS case, the SoS organization cannot task a constituent system organization without their
cooperation. In an acknowledged or collaborative SoS, these tasks are balanced against the tasks
of the constituent system as a SOI in its own right. For virtual SoS, agreement processes may be
informal, or considered only for analysis purposes.
The Agreement processes description from ISO/IEC/IEEE 15288 applies as stated to SoS with the
following additions.
Because CS exist already and are being used for other purposes, agreements between the CS and its
suppliers can already exist. Those agreements could 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 could
affect existing agreements the CS has in place with its suppliers. However, depending on the degree of
operational or managerial independence, CS may not be obliged to acknowledge or adjust based on the
SoS requirements.
For some SoS, it is possible that the Agreement processes as stated 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 owners could form agreements among each other. In some cases,
participating CS owners could even be competing and conflicting with each other. In others, formal
agreements could be absent.
In SoS, agreements can be needed when there are no existing authority arrangements between the SoS
and the CS. Agreements within SoS could be formal agreements, memoranda of agreement, or other
less formal agreements. Loose agreements could be more appropriate for non-critical elements, while
tighter, more formal agreements and associated processes could be appropriate for managing areas of
higher risk or greater criticality. However, CS could 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 owners that facilitate collaboration or create
conflicting relationships among the CS owners and SoS owner (if any). These relationships result in
dynamic changes to the CS that modify the objectives, goals, and capabilities of the SoS.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 11

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 owners. Revised agreements
for example, may be needed to establish and maintain interoperability between CS. These agreements
could 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 could 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 owners and
maintainers.
6.1.2 Acquisition process
6.1.2.1 Purpose
The purpose of the Acquisition process in ISO/IEC/IEEE 15288:2015, 6.1.1 is shown in the box.
The purpose of the Acquisition process is to obtain a product or service in accordance with the
acquirer's requirements.
NOTE As part of this process, the agreement is modified when a change request is agreed to by both the
acquirer and supplier.
The purpose of the Acquisition process in ISO/IEC/IEEE 15288:2015, 6.1.1 applies as stated to SoS with
the following additions.
For an SoS, the organization (single or collaborative) for the SoS is the acquirer and the suppliers could
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" could 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 could still need to obtain
system elements (i.e., system elements that are not CS, or any system elements required by the SoS
beyond the CS).
There could be the occasion where the functionality or interface behaviors 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:2015, 6.1.1 apply as stated in the boxes
with the following additions:
a) A request for supply is prepared.
It is possible that a request for supply by the organization that governs the SoS does not have the same
formality as could 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 could only have or
need partial influence on the component outcome. For example, there could 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 agreements and influencing by demonstrating
potential mutual benefits (to both SoS governance and CS suppliers) could apply.
© ISO/IEC 2019 – All rights reserved
12 © IEEE 2019 – All rights reserved

b) One or more suppliers are selected.
In an SoS, the selection of suppliers or participants can occur in several ways. The SoS could identify
and negotiate the participation of a CS in an SoS. If the CS are managerially dependent, the selection of
supplie
...