ISO/IEC/IEEE FDIS 21839

• Abstract:

  1.1 Purpose This document provides a set of critical system of systems (SoS) considerations to be addressed at key points in the life cycle of the system of interest (SoI). This document refers to considerations that apply to an SoI that is a constituent system that interacts in an SoS. The considerations and life cycle model align with those which are already defined in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 24748-1. Selected subsets of these considerations can be applied throughout the life of systems through the involvement of stakeholders. The ultimate goal is to achieve customer satisfaction, so that when delivered, the SoI will operate effectively in the operational or business environment which is typically characterized as one or more systems of systems. This document concerns those systems that are man-made and are configured with one or more of the following: hardware, software, humans, procedures and facilities. 1.2 Field of application This document addresses SoS considerations that apply to systems at each stage of their respective life cycles. There is a wide variety of systems in terms of their purpose, domain of application, complexity, size, novelty, adaptability, quantities, locations, life spans and evolution. This document is concerned with describing the system of systems considerations that apply to a system that is the SoI; that is a constituent system within a system of systems. It applies to one-of-a-kind systems, mass produced systems or customized, adaptable systems. 1.3 Limitations This document does not detail the approach to addressing system of systems considerations in terms of methods or procedures. This document does not detail the described documentation in terms of name, format, explicit content and recording media of documentation.

• 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: 12-Jun-2026
• Completion Date: 11-Jun-2026

• Revises: ISO/IEC/IEEE 21839:2019 - Systems and software engineering — System of systems (SoS) considerations in life cycle stages of a system
• Effective Date: 07-Jan-2025

Overview

ISO/IEC/IEEE FDIS 21839: Systems and software engineering - System of systems (SoS) considerations in life cycle stages of a system provides comprehensive guidance on critical considerations for systems that interact within larger systems-of-systems (SoS) environments. Developed by ISO, IEC, and IEEE, this international standard outlines essential SoS considerations to be addressed at key life cycle stages of a system of interest (SoI), particularly when that system acts as a constituent system (CS) within a broader SoS.

The guidance aligns with established system life cycle models (such as those in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 24748-1) and applies to a wide variety of man-made systems-covering hardware, software, human procedures, and facilities. By addressing these considerations, stakeholders can help ensure systems are fit for purpose within complex, interdependent environments, ultimately supporting effective operation and customer satisfaction.

Key Topics

• System of Systems (SoS): Defines SoS as a set of interacting, independent systems that provide a unique capability unattainable by individual systems alone. Emphasizes the operational and managerial independence of constituent systems and their interdependencies.

• Life Cycle Stages: Applies SoS considerations throughout the system life cycle, including concept, development, production, utilization, support, and retirement stages. These stages are not strictly sequential and may involve iteration and recursion.

• Capability, Technical, and Management Focus: SoS considerations are framed under three main areas:

  • Capability: How a system supports user objectives within an SoS context, considering both material (hardware/software) and non-material (people, processes) elements.
  • Technical: Impacts on, and dependencies with, external systems, including interoperability, interfaces, and infrastructure.
  • Management: Governance, cost, scheduling, and coordination across organizational boundaries and multiple stakeholders.

• Stakeholder Involvement: Highlights the need for active stakeholder engagement throughout the system life cycle to ensure that SoS considerations are adequately addressed.

• Applicability to Various System Types: The standard can be applied to one-of-a-kind, mass-produced, or customized adaptable systems within diverse domains and industries.

Applications

ISO/IEC/IEEE FDIS 21839 is relevant across many sectors where systems must interoperate within larger ecosystems. Real-world applications include:

• Aerospace and Defense: Integration of independent subsystems (e.g., aircraft, communications, and ground control) to achieve mission objectives.
• Transportation: Collaboration between traffic management, vehicles, and infrastructure systems to improve safety and efficiency.
• Finance: Interconnected banking systems required for cross-institutional transaction processing and security.
• Healthcare: Integration of diverse health IT systems, medical devices, and support services in hospital networks.
• Smart Cities: Coordination among utilities, transport, public safety, and information systems to deliver value-added urban services.

By systematically addressing SoS considerations at each life cycle stage, organizations can mitigate integration risks, manage dependencies, and enhance interoperability in complex environments.

Related Standards

Organizations seeking comprehensive coverage on systems and software engineering in SoS contexts should refer to these related international standards:

• ISO/IEC/IEEE 15288 – Systems and software engineering – System life cycle processes
• ISO/IEC/IEEE 24748-1 – Systems and software engineering – Life cycle management – Part 1: Guidelines for life cycle management
• ISO/IEC/IEEE 21840 – Systems and software engineering – Guidelines for the application of systems engineering to a system of systems
• ISO/IEC/IEEE 12207 – Software life cycle processes (also relevant for software-intensive SoS)
• ISO/IEC/IEEE 24765 – Systems and software engineering vocabulary

These standards collectively provide robust frameworks for managing the complexity inherent in systems of systems, supporting organizations in achieving both business and operational goals.

---

Keywords: system of systems, SoS, system life cycle, constituent system, ISO/IEC/IEEE 21839, systems engineering, interoperability, stakeholder involvement, international standards, life cycle stages, system integration.

DRAFT
International
Standard
ISO/IEC/IEEE
DIS
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — System of systems
Voting begins on:
(SoS) considerations in life cycle
2025-09-10
stages of a system
Voting terminates on:
2025-12-03
Ingénierie du logiciel et des systèmes — Études du système des
systèmes (SdS) dans les étapes du cycle de vie d'un système
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 21839:2025(en)
© IEEE 2025
DRAFT
ISO/IEC/IEEE DIS 21839:2025(en)
International
Standard
ISO/IEC/IEEE
DIS
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — System of systems
Voting begins on:
(SoS) considerations in life cycle
stages of a system
Voting terminates on:
Ingénierie du logiciel et des systèmes — Études du système des
systèmes (SdS) dans les étapes du cycle de vie d'un système
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 21839:2025(en)
© IEEE 2025
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ii
ISO/IEC/IEEE DIS 21839:2025(en)
Contents Page
Foreword .iv
1 Scope . 1
1.1 Purpose .1
1.2 Field of application .1
1.3 Limitations .1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .3
4 Concepts . 3
4.1 System of systems .3
4.2 Constituent systems .4
4.3 System life cycle stages .5
4.4 SoS technical base . .7
5 SoS considerations in SoI life cycle stages . 7
5.1 Addressing SoS considerations in the concept stage .7
5.1.1 General .7
5.1.2 Concept stage capability considerations.9
5.1.3 Concept stage technical considerations .11
5.1.4 Concept stage management considerations . 12
5.2 Addressing SoS considerations in the development stage . 13
5.2.1 General . 13
5.2.2 Development stage capability considerations .14
5.2.3 Development stage technical considerations . 15
5.2.4 Development stage management considerations .18
5.3 Addressing SoS considerations during the production stage . 20
5.4 Addressing SoS considerations during utilization and support stages . 20
5.4.1 General . 20
5.4.2 Utilization and support stage capability considerations . 22
5.4.3 Utilization and support stage technical considerations . 23
5.4.4 Utilization and support stage management considerations .24
5.5 Addressing SoS considerations in retirement stage .24
Annex A (informative) SoS technical base .26
Annex B (informative) Example SoS considerations in the life cycle stages of a CS .27
Annex C (informative) Relationship to other standards .29
Bibliography .30

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
iii
ISO/IEC/IEEE DIS 21839: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 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.
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.
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, Software and systems 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.
ISO/IEC/IEEE 21839 is one of three standards dealing with systems of systems. The relationship among the
three standards is described in Annex C.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 21839:2019), which has been
technically revised.
The main changes are as follows:
— added references for interfacing and interoperating systems and general updates from
ISO/IEC/IEEE 15288:2023 and ISO/IEC/IEEE 24748-2:2024;
— updated content based on updates to ISO/IEC/IEEE 24748-1:2024, including more recent life cycle models
such as DevOps.
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 and
www.iec.ch/national-committees.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
iv
DRAFT International Standard ISO/IEC/IEEE DIS 21839:2025(en)
Systems and software engineering — System of systems (SoS)
considerations in life cycle stages of a system
1 Scope
1.1 Purpose
This document provides a set of critical system of systems (SoS) considerations to be addressed at key points
in the life cycle of the system of interest (SoI). This document refers to considerations that apply to an SoI
that is a constituent system (CS) that interoperates in an SoS. This document considers the generic life cycle
model defined in ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 24748-1. Selected subsets of these considerations
can be applied throughout the life of systems through the involvement of stakeholders. The ultimate goal is
to achieve customer satisfaction, so that when delivered, the SoI will operate effectively in the operational
or business environment which is typically characterized as one or more SoS.
This document concerns those systems that are human-made and are configured with one or more of the
following: hardware, software, humans, procedures and facilities.
NOTE This document also can be productively applied by users of ISO/IEC/IEEE 12207.
1.2 Field of application
This document addresses SoS considerations that apply to systems at each stage of their respective life cycles.
There is a wide variety of systems in terms of their purpose, domain of application, complexity, size, novelty,
adaptability, quantities, locations, life spans and evolution. This document is concerned with describing the
SoS considerations that apply to a system that is the SoI; that is a CS within an SoS. It applies to one-of-a-kind
systems, mass produced systems or customized, adaptable systems.
1.3 Limitations
This document does not detail the approach to addressing SoS considerations in terms of methods or
procedures.
This document does not detail the described documentation in terms of name, format, explicit content and
recording media of documentation.
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.
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/

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
— IEEE Standards Dictionary Online: available at https:// ieeexplore .ieee .org/ xpls/ dictionary .jsp
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.1
capability
measure of capacity and the ability of an entity (system (3.1.6)), person or organization) 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.6) that forms part of a system of systems (3.1.8) (SoS)
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, 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.
[SOURCE: ISO/IEC/IEEE 21840, 2025, 3.1.2]
3.1.3
governance
process of establishing and enforcing strategic goals and objectives, organizational policies, and performance
parameters
[SOURCE: ISO/IEC/IEEE 21840:2025, 3.1.4]
3.1.4
life cycle
evolution of a system (3.1.6), product, service, project or other human-made entity from conception through
retirement
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.24]
3.1.5
stage
period within the life cycle (3.1.4) 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.43]
3.1.6
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 21839: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.7
system of interest
SoI
system (3.1.6) whose life cycle (3.1.4) is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48]
3.1.8
system of systems
SoS
set of systems or system (3.1.6) 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 the 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.
[SOURCE: ISO/IEC/IEEE 21840, 2025, 3.1.10]
3.1.9
systems 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.6), 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.
[SOURCE: ISO/IEC/IEEE 21840, 2025, 3.11]
3.2 Abbreviated terms
CS constituent system
SoI system of interest
SoS system of systems
SoSE system of systems engineering
4 Concepts
4.1 System of systems
Both individual systems and SoS conform to the accepted definition of a system in that each consists of
parts, relationships and a whole that is greater than the sum of the parts; however, while all SoS are systems,
not all systems are SoS, even if multiple systems are interacting with each other.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
[12]
Maier postulated five key characteristics (not criteria) of SoS: operational independence of constituent
systems (CS), managerial independence of CS, geographical distribution, emergent behaviour and
evolutionary development processes. Maier identified operational independence and managerial
independence as the two principal distinguishing characteristics for applying the term “systems of
systems”. A system that does not exhibit these two characteristics is not an SoS regardless of the complexity
or geographic distribution of its constituents.
An essential characteristic is that each CS within the SoS is operationally independent. 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.
In an SoS, systems are also managerially independent. That is, each CS is likely to be managed by
organizations with a level of independence, with potentially different goals and objectives for the CS.
In some cases, there can be a designated entity with some type of responsibility that spans an SoS. These
managerial arrangements can be loosely defined or more highly structured depending on the particular
situation. In other cases, no such entity exists. 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.
4.2 Constituent systems
An essential concept is that the SoS is comprised of CS (and can include other elements) that interact to
provide capabilities that no one system or element in the SoS can provide by itself. Each CS is an independent
system that provides capabilities to meet its specified mission or business objective and has its own life cycle,
management and governance, and technical requirements. CS include systems which are often considered as
infrastructure, such as communications systems. A CS can be an entity in more than one SoS. An SoS is often
comprised of existing CS along with new CS which are developed and integrated into the SoS. The focus of
this document is a CS as the SoI, as is shown in Figure 1. The considerations provided in this document are
with respect to what is necessary to account for the life cycle of the CS or SoI to enable it to interact in the
anticipated SoS configurations.
Figure 1 — Focus of this document is on the CS in an SoS
SoS and CS can apply to any domain. For example, in an air transportation SoS, CS can include the air traffic
management systems, airports and aircraft. In a money transfer SoS (see an example in Annex B), CS can
include different banks. In a military SoS, weapons and communication systems can be considered CS. This
document addresses the SoS considerations for the life cycle stages of systems (new or evolving) which are
constituents of one or more SoS.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
4.3 System life cycle stages
As an SoS evolves, each CS follows representative life cycle stages for its own evolution. A generic system
life cycle model defined in ISO/IEC/IEEE 24748-1 includes the stages: concept, development, production,
utilization, support and retirement. These stages should not be construed to mean a sequence or a linear
progression between stages. An alternate system life cycle model is shown in Figure 2. These stages can
be implemented in different progression with iteration and recursion possible, one example of which is
shown in Figure 3. Table 1 summarizes the main purpose of each life cycle stage and shows decision options
common across all life cycle stages.
NOTE See ISO/IEC/IEEE 24748-1:2024, Figure 5.
Figure 2 — Development and operations (DevOps) example life cycle stages
NOTE See ISO/IEC/IEEE 24748-1:2024, Figure 6.
Figure 3 — Possible progress of life cycle stages

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
Table 1 — Life cycle stages, their purposes and decisions options
Life cycle stages Purpose Decision options
Identify stakeholders' needs
Concept Explore concepts
— Begin subsequent stage or
Propose viable solutions
stages
Refine system requirements
Create solution description
— Continue this stage
Development
Build system
— Go to or restart a preceding
Verify and validate system
stage
Produce systems
Production
Inspect and test — Hold project activity
Utilization Operate system to satisfy users' needs
— Terminate project
Support Provide sustained system capability
Retirement Store, archive or dispose of system
In this document, SoS considerations are addressed at each of these stages for an SoI that is intended to
interact with other systems (a CS of an SoS). The stages are addressed as follows: Concept (5.1), Development
(5.2), Production (5.3), Utilization and Support (5.4) and Retirement (5.5).
As the focus of this document is the life cycle of the CS as the SoI, SoS considerations to be addressed in each
stage in the life cycle of a system are presented as a list of questions along with the supporting material.
SoS considerations are grouped into three areas: capability, technical and management (including schedule
and cost). This document addresses both the benefit to the SoI of addressing these SoS questions and the
risks of failing to address the questions. It identifies the type of information or artefacts that provide the
information needed to address the questions and potential actions.
In this document, each stage presents three areas to consider:
— Capability considerations: In this document, capability refers to the ability to achieve overall user
objectives in a mission or business context. User capabilities are often based on the collective effects
of multiple physical systems (referred to as “material”) as well as other factors beyond the systems
themselves (training, procedures, etc. which are referred to in this document as “non-material”). Enabling
systems can be either material or non-material as defined in this document. Typically, the development
of an SoI begins with a user need based on an identified gap in capability and a proposed SoI that focuses
on filling that capability gap. From the earliest point in its life cycle, understanding the role of the SoI in
supporting the SoS capability is a key concern, particularly understanding: 1) how the SoI is envisaged
to function in the operational or business context, 2) the constraints that context places on the SoI, and
3) the relationships, interfaces and dependencies between the SoI and other interoperating and enabling
systems supporting the SoS capability. Relevant ISO/IEC/IEEE 15288 processes are business or mission
analysis and stakeholder needs and requirements definition.
— Technical considerations: As SoI are evaluated, the technical impact on external stakeholders and
external systems and infrastructure should be considered. This includes both systems/services on
which the SoI depends and systems/services that depend on the SoI. Once these have been identified, the
ability to influence resource changes in interoperating and enabling systems should be considered. When
selecting the SoI solution, consider any constraints on the SoI imposed by its SoS. Typically, technical
considerations play an important role in the SoI’s requirements and system architecture definition.
Understanding these early and factoring them into the project planning process can be key to successful
delivery of both the SoI and the capability it enables. Relevant ISO/IEC/IEEE 15288 processes are all the
technical processes.
— Management considerations: Management issues should be considered when dependencies resulting
from interactions are negotiated with organizations providing other systems involved (e.g. interfaces,
new or changed functionality in other systems). If there is an entity with some type of responsibility that
spans an SoS, management arrangements with that entity should be established. SoS-related cost and
schedule considerations should be addressed, including identifying costs and schedules associated with
external systems. Finally, mechanisms should be in place to monitor the progress in the areas of cross-

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
system dependencies for a prompt identification of any changes or delays which can mean added cost and
[5]
time. Plans should be formulated to accommodate these if necessary. Relevant ISO/IEC/IEEE 15288
processes are all the technical management processes and all the agreement processes.
In this document, certain considerations should be addressed at multiple stages, so if a question also applies
to more than one stage.
A system can interact as part of one or more SoS in support of multiple capabilities. In this document, when
the interaction of a system with an SoS is discussed, this can include one or more SoS in support of one or
more capabilities. Thus, although the terms SoS, capability and context are used in singular form throughout
this document, each use can be plural if applicable to the situation.
4.4 SoS technical base
Annex A presents what is termed the “SoS technical base”, which reflects the type of SoS-level technical
information that would ideally be available as a reference to an SoI in addressing wider SoS considerations. As
is shown in Figure 1, this document applies to a constituent SoI in an SoS. The SoS technical base information
in Annex A can be available to provide reference information used to address the SoS considerations and
help ensure that organizations responsible for CS in the SoS can address these considerations in a consistent
manner and reduce risks at both the system and the SoS levels. It is recognized that in many cases, this
information is not available, putting an added burden on the SoI to address the SoS considerations across the
multiple organizations.
5 SoS considerations in SoI life cycle stages
5.1 Addressing SoS considerations in the concept stage
5.1.1 General
This subclause describes the SoS considerations for the SoI to be addressed in the concept stage as defined
in ISO/IEC/IEEE 24748-1:2024, 5.2. Details of the concept stage from ISO/IEC/IEEE 24748-1:2024 are shown
in Box 1.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
Box 1 Concept Stage
(From ISO/IEC/IEEE 24748-1:2024, 5.2)
Concept stage (5.2)
Overview (5.2.1)
The concept stage begins with initial recognition of a need or a requirement for a new SoI or for the mod-
ification to an existing SoI. This is an initial exploration, fact finding and planning period when economic
technical, strategic and market bases are assessed through acquirer/market survey, business or mission
analysis, solution space identification and feasibility analysis and trade-off studies. Acquirer/user feed-
back to the concept is obtained.
One or more alternative concepts to meet the identified needs or requirements are developed through
analysis, feasibility evaluations, estimations (such as cost, schedule, market intelligence and logistics),
trade-off studies, risk assessment and experimental or prototype development and demonstration.
Concepts can be generated from existing systems. The need for one or more enabling systems for adap-
tation, development, production, utilization, support and retirement of the SoI is identified and candidate
solutions are included in the evaluation of alternatives in order to arrive at a balanced life cycle solution.
Typical outputs of this stage are stakeholder requirements, concepts of operation, assessment of feasibil-
ity, preliminary system requirements, outline architecture and design solutions in the form of drawings,
models, prototypes, etc., and concept plans for enabling systems, including whole life cycle cost and human
resource requirements estimates and preliminary project schedules. Decisions are made whether to con-
tinue with the implementation of a solution in the development stage or to cancel further work.
It is presumed that the organization has available enabling systems for the concept stage that consist of
the methods, techniques, tools and competent human resources to undertake market/economic analysis
and forecasting or mission analysis, feasibility analysis, trade-off analysis, technical analysis, whole life
cost estimation, modelling, simulation and prototyping.
Purpose (5.2.2)
The concept stage is executed to assess new business opportunities or mission assignments for feasibility
and to discern stakeholder needs and requirements. The concept stage can be extended into evaluation of
conceptual architecture and design solution.
Outcomes (5.2.3)
In addition to the outcomes common to all stages, outcomes of the concept stage are listed below.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
a) New concepts are identified with stakeholders’ consensus that offer such things as new capabilities,
enhanced overall performance or reduced stakeholders' total ownership costs over the system life
cycle.
b) An assessment is performed on feasible SoI concepts, with initial architectural and other solutions,
including enabling systems throughout the life cycle, for closure against technical and business or
mission stakeholder objectives.
c) Preliminary stakeholder, system and usability requirements (preliminary technical specifications
for the selected SoI and usability specifications for the envisaged human-machine interaction) are
prepared and baselined. See ISO 9241-210 for additional guidance on human-machine interactions.
d) Refined outcomes and cost estimates for stages of the system life cycle model are provided for
common use by stakeholders.
e) Risk identification, assessment and mitigation plans are prepared for common use by stakeholders for
this and subsequent stages. The system life cycle model can also be the subject of risk management.
f) Identification and initial specification of the services that are needed from enabling systems
throughout the life of the SoI are defined.
g) Concepts for execution of all succeeding stages are provided for common use by stakeholders,
including preliminary plans and preliminary entry and exit criteria.
h) Definition of the enabling system services required in subsequent life cycle stages is provided for
relevant stakeholders.
i) Project budget and schedule baselines and life cycle ownership cost estimates are provided for
common use by stakeholders.
j) Review is performed for any existing systems or system elements that can be leveraged to accelerate
meeting the customer’s need.
k) Review is performed for system of systems (SoS) considerations if the system will operate in an
existing or developing ecosystem of other systems.
5.1.2 Concept stage capability considerations
In the concept stage the following capability questions should be addressed:
— Has the operational or business context of the user capability need been described?
— Has the existing user capability been described, including the systems or SoS that currently support that
capability?
— How would a new system which might address the gap fit into current operations or business processes?
— If a new system were to be considered, have interfaces with or required changes to current systems or
systems which are planned or in development been identified?
Identifying and addressing constraints are key to effective solutions. An early description of the SoS
context and its potential impact on requirements and dependencies for the SoI provide a solid basis for the
development of a system that can meet user needs, including quality characteristics.
Potential changes to other systems, interfaces and infrastructure should be identified as early as possible.
This will allow time for multi-lateral SoS trade-off analyses, considering which changes should be
implemented or where they can best be implemented and allow time for negotiations and organizational
agreements to be put in place. Early identification of dependencies between developing or planned systems
provides the opportunity to help ensure that interoperability is maintained despite changes. An early
understanding of these factors can contribute to a sound solution selection for the SoI and an assessment of
SoS risks. This is particularly important for any long-lead items.

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
Understanding of current operations, business processes and life cycle support is also important to set the
context for the SoI. This includes systems currently supporting the SoS capability, systems in development
or planned and any non-material elements. The full impact of alternatives should be considered in the
assessment of possible approaches for addressing the gap(s), including any required changes to operations,
business processes or life cycle support to avoid unwanted effects on other capabilities.
During the concept stage, there is a set of questions concerning the capability being sought and the context
of that need. These questions build on any capability considerations addressed previously and address the
implications at the next level of detail.
— Is the SoS context (or multiple SoS contexts) given in an up-to-date description of how the users will
conduct the operation or business process and how they expect to use the new system?
— Have operational or business context constraints on potential solutions been identified? (E.g. business or
operational continuity needs based on the importance of the capability being continuously available.)
— How would the SoI fit into current and future operations?
— Have the relationships between the SoI and other CS been communicated?
— Have interfaces with or required changes to systems in development or planned systems been identified?
— Have the benefits from and for other systems been identified? Have these been communicated to these
systems?
— Have impacts on non-material factors (e.g. personnel, training, description of how the users will conduct
the operation or business process, life cycles support, other) been described?
If there is no description of how users expect to use the new SoI that is coordinated with the overall
description of how the users will conduct operations in an SoS context or environment, the risk is that
requirements and dependencies can be missed. This can lead to an ineffective SoI when placed in an SoS
context or environment, unexpected higher costs or schedule slippage due to necessary rework.
Expected here is a written description, which contains a delineation of how the SoI will work in the context
of other systems and in the operational or business context, which is consistent with the view presented
in the description of how the users will conduct SoS operations. The context also should describe how the
new SoI is expected to be used with other systems to address the user’s capability objectives. If the written
description has not been completed, priority should be given to developing and validating how users expect
to use the new system, which identifies key elements external to the proposed system, including those that
would support the SoI through its life cycle, and their impact on system attributes and functionality — as
well as impacts of the SoI on these external factors — to help ensure compatibility with existing descriptions
of how the users will conduct operations overall.
Considering non-material factors early provides sufficient lead-time to address cross-organizational
enablers such as resources, organizational impact, training, life cycle support, personnel multi-role postings
and recruitment focus. Considering impacts or factors from the SoS or its CS helps to avoid the risk that the
solution considered or selected will fail to achieve the desired capabilities, incur added, unexpected costs or
schedule slips, or result in unwanted, negative effects on other capabilities.
— How does the proposed SoI help to address the capability gap in the context of the SoS?
A description of how the proposed SoI addresses the capability gap, in the context of the systems currently
supporting the capability, will provide the basis for understanding key attributes of the SoI and key
relationships to be considered in SoI requirements. Defining the linkage between the proposed SoI and
the other systems supporting the capability helps to avoid the risk that the system can fail to meet user
objectives. At this stage, there should be results of analysis, simulation, prototyping or experimentation
to support an assessment of consistency. If this has not been addressed, using data from simulations,
prototypes or live events, analysis should be conducted on the end-to-end actions based on the description
of how the users will conduct operations, to verify that the SoI will support the capability need in the context
of the SoS currently supporting the capability.
— Have roles of the SoI in different missions or activity threads been identified and prioritized?

© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS 21839:2025(en)
A description of the variety of roles that a system will play, including any concurrent roles in multiple SoS,
will provide a strong foundation for system requirements. If a system has roles in several missions, early
identification of the capability development information requirements will help to ensure availability of
that information and will help to avoid the risk that the system will fail to meet all user objectives. By this
point there should be identification of mission or SoS interfaces, information suppliers, protocols, standards
responsibilities and interoperability requirements. If this has not yet been addressed, the interoperability
requirements and d
...

FINAL DRAFT
International
Standard
ISO/IEC/IEEE
FDIS
ISO/IEC JTC 1/SC 7
Systems and software
Secretariat: BIS
engineering — System of systems
Voting begins on:
(SoS) considerations in life cycle
2026-04-16
stages of a system
Voting terminates on:
2026-06-11
Ingénierie du logiciel et des systèmes — Études du système des
systèmes (SdS) dans les étapes du cycle de vie d'un système
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 — System of systems
Voting begins on:
(SoS) considerations in life cycle
stages of a system
Voting terminates on:
Ingénierie du logiciel et des systèmes — Études du système des
systèmes (SdS) dans les étapes du cycle de vie d'un système
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
4 Concepts . 4
4.1 System of systems .4
4.2 Constituent systems .4
4.3 System life cycle stages .5
4.4 SoS technical base . .8
5 SoS considerations in SoI life cycle stages . 8
5.1 Addressing SoS considerations in the concept stage .8
5.1.1 General .8
5.1.2 Concept stage capability considerations.8
5.1.3 Concept stage technical considerations .10
5.1.4 Concept stage management considerations .11
5.2 Addressing SoS considerations in the development stage . 12
5.2.1 General . 12
5.2.2 Development stage capability considerations . 12
5.2.3 Development stage technical considerations . 13
5.2.4 Development stage management considerations .16
5.3 Addressing SoS considerations during the production stage .18
5.4 Addressing SoS considerations during utilization and support stages .18
5.4.1 General .18
5.4.2 Utilization and support stage capability considerations .18
5.4.3 Utilization and support stage technical considerations .19
5.4.4 Utilization and support stage management considerations .19
5.5 Addressing SoS considerations in retirement stage . 20
Annex A (informative) SoS technical base .21
Annex B (informative) Example SoS considerations in the life cycle stages of a CS .22
Annex C (informative) Relationship to other standards .24
Bibliography .25
IEEE notices and abstract .26

© 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, Software and systems 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 21839:2019), which has been
technically revised.
The main changes are as follows:
— added references for interfacing and interoperating systems and general updates from
ISO/IEC/IEEE 15288:2023 and ISO/IEC/IEEE 24748-2:2024;
— updated content based on updates to ISO/IEC/IEEE 24748-1:2024, including more recent life cycle models
such as DevOps;
— the text has been updated to be aligned with ISO/IEC/IEEE 21840:2026 and ISO/IEC/IEEE 21841:2026.
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 and
www.iec.ch/national-committees.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
iv
Introduction
This document is one of three standards dealing with systems of systems (SoS). The relationship among the
three standards is described in Annex C.
There is a wide variety of systems in terms of their purpose, domain of application, complexity, size, novelty,
adaptability, quantities, locations, life spans and evolution.
This document considers the generic life cycle model defined in ISO/IEC/IEEE 15288 and
ISO/IEC/IEEE 24748-1. Selected subsets of these considerations can be addressed throughout the life
of systems through the involvement of stakeholders. The goal is to achieve customer satisfaction, so that
when delivered, the SoI operates effectively in the operational or business environment which is typically
characterized as one or more SoS.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
v
FINAL DRAFT International Standard ISO/IEC/IEEE FDIS 21839:2026(en)
Systems and software engineering — System of systems (SoS)
considerations in life cycle stages of a system
1 Scope
This document provides a set of critical system of systems (SoS) considerations to be addressed at key
points in the life cycle of the system of interest (SoI) that is a constituent system that forms a part of an SoS.
This document applies to human-made systems that are configured with one or more of the following:
hardware, software, humans, procedures and facilities.
This document also can be productively applied by users of ISO/IEC/IEEE 12207.
This document addresses SoS considerations that apply to systems at each stage of their respective life
cycles. It applies to one-of-a-kind systems, mass-produced systems or customized, adaptable systems.
This document does not elaborate in detail the methods or procedures for addressing SoS considerations.
This document does not detail the described documentation in terms of name, format, explicit content and
recording media of documentation.
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 https:// ieeexplore .ieee .org/ xpls/ dictionary .jsp
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
capability
measure of capacity and the ability of an entity (system (3.9), person or organization (3.7)) 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.2
constituent system
CS
independent system (3.9) that forms part of a system of systems (SoS) (3.12)
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, utilization, goals, and resources, but interacts within the SoS to provide the unique
capability (3.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.10) 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)
[SOURCE: ISO/IEC/IEEE 21840:— , 3.1.2]
3.3
governance
practice of establishing and enforcing strategic goals and objectives, organizational policies, and
performance parameters
[SOURCE: ISO/IEC/IEEE 21840:—, 3.1.4]
3.4
interoperating system
system (3.9) that exchanges information with the system of interest (3.13) and uses the information that has
been exchanged
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.20]
3.5
life cycle
evolution of a system (3.9), product, service, project or other human-made entity from conception through
retirement
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.24]
3.6
management
system (3.9) of controls and processes required to achieve the strategic objectives set by the organization's
(3.7) governing body
Note 1 to entry: Management is subject to the policy guidance and monitoring set through corporate governance (3.3).
[SOURCE: ISO/IEC/IEEE 21840:—, 3.1.6]
3.7
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.]
1) Under preparation. Stage at the time of publication: ISO/IEC/IEEE FDIS 21839.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.8
stage
period within the life cycle (3.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.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.
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.10
system element
discrete part of a system (3.9) 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.11
system of systems
SoS
set of systems (3.9) or system elements (3.10) that interact to provide a unique capability (3.1) that none of the
constituent systems (3.2)can accomplish on its own
Note 1 to entry: System elements can be necessary to facilitate the 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.
[SOURCE: ISO/IEC/IEEE 21840: —, 3.1.11]
3.12
system of systems engineering
SoSE
process of planning, analysing, organizing, developing and integrating the capabilities (3.1) of a mix of
existing and new systems (3.9), including inter-system infrastructure, facilities, and overarching processes
into a system of systems (3.11) capability that is greater than the sum of the capabilities of the constituent
systems (3.2)
Note 1 to entry: SoSE also includes testing, modification, maintenance and other post-integration activities.
[SOURCE: ISO/IEC/IEEE 21840: —, 3.1.12]

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.13
system of interest
SoI
system (3.9) whose life cycle (3.5) is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48]
3.14
systems engineering
transdisciplinary and integrative approach to enable the successful realization, use, and retirement
of engineered systems (3.11) using systems principles and concepts and scientific, technological and
management (3.6) methods
[SOURCE: INCOSE-TP-2020-002-06]
4 Concepts
4.1 System of systems
Both individual systems and SoS conform to the accepted definition of a system in that each consists of
parts, relationships and a whole that is greater than the sum of the parts; however, while all SoS are systems,
not all systems are SoS, even if multiple systems are interacting with each other.
[13]
Maier postulated five key characteristics (not criteria) of SoS: operational independence of constituent
systems (CS), managerial independence of CS, geographical distribution, emergent behaviour and
evolutionary development processes. Maier identified operational independence and managerial
independence as the two principal distinguishing characteristics for applying the term “systems of
systems”. A system that does not exhibit these two characteristics is not an SoS regardless of the complexity
or geographic distribution of its constituents.
An essential characteristic is that each CS within the SoS is operationally independent. 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.
In an SoS, systems are also managerially independent. That is, each CS is likely to be managed by
organizations with a level of independence, with potentially different goals and objectives for the CS.
In some cases, there can be a designated entity with some type of responsibility that spans an SoS. These
managerial arrangements can be loosely defined or more highly structured depending on the particular
situation. In other cases, no such entity exists. CS have their own stakeholders and CS remain managerially
and operationally independent; managers of CS managers or CS projects can be unaware, unable or unwilling
to make adjustments to address SoS-desired capabilities.
4.2 Constituent systems
An essential concept is that the SoS is composed of CS (and can include other system elements) that
operationally interact to provide capabilities that no one system or element in the SoS can provide by
itself. Each CS is an independent system that provides capabilities to meet its specified mission or business
objective and has its own life cycle, management and governance, and technical requirements. CS can include
systems which are considered as infrastructure. A CS can be an entity in more than one SoS. An SoS is often
composed of existing CS along with new CS which are developed and integrated into the SoS. The focus of
this document is a CS as the SoI, as is shown in Figure 1. The considerations provided in this document are
with respect to what is necessary to account for the life cycle of the CS or SoI to enable it to interact in the
anticipated SoS configurations.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Figure 1 — Focus of this document is on the CS in an SoS
SoS and CS can apply to any domain. In a money transfer SoS (see an example in Annex B), CS can include
different banks. In a military SoS, weapons and communication systems can be considered CS. In an air
transportation SoS, CS can include the air traffic management systems, airports and aircraft. This document
addresses the SoS considerations for the life cycle stages of systems (new or evolving) which are constituents
of one or more SoS.
4.3 System life cycle stages
As an SoS evolves, each CS follows representative life cycle stages for its own evolution. A generic system
life cycle model defined in ISO/IEC/IEEE 24748-1 includes the stages: concept, development, production,
utilization, support and retirement. These stages should not be construed to mean a sequence or a linear
progression between stages. Stages can be implemented in different progression with iteration and
recursion possible, one example of which is shown in Figure 2. An alternate system life cycle model with
different stage names is shown in Figure 3. (See ISO/IEC/IEEE 32675 for more information about DevOps.)
Table 1 summarizes the main purpose of each life cycle stage and shows decision options common across all
life cycle stages. ISO/IEC/IEEE 24748-1 includes elaboration on the purpose of each stage.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
NOTE Adapted from ISO/IEC/IEEE 24748-1:2024, Figure 6.
Figure 2 — Possible progress of life
NOTE See ISO/IEC/IEEE 24748-1:2024, Figure 5.
Figure 3 — Development and operations (DevOps) example life cycle stages cycle stages

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Table 1 — Life cycle stages, their purposes and decisions options
Life cycle stages Objective Decision options
Identify stakeholders' needs — Begin subsequent stage or
stages
Concept Explore concepts
Propose viable solutions
— Continue this stage
Refine system requirements
— End this stage
Create solution description
Development
Build system
— Go to or restart a preceding
Verify and validate system
stage
Produce systems
Production
— Hold project activity
Inspect and test
Utilization Operate system to satisfy users' needs — Terminate project
Support Provide sustained system capability
Retirement Store, archive or dispose of system
In this document, SoS considerations are addressed at each of these stages for an SoI that is intended to
interact with other systems (a CS of an SoS). The stages are addressed as follows: concept (5.1), development
(5.2), production (5.3), utilization and support (5.4) and retirement (5.5).
As the focus of this document is the life cycle of the CS as the SoI, SoS considerations to be addressed in each
stage in the life cycle of a system are presented as a list of questions along with the supporting material.
SoS considerations are grouped into three areas: capability, technical and management (including schedule
and cost). This document addresses both the benefit to the SoI of addressing these SoS questions and the
risks of failing to address the questions. It identifies the type of information or artefacts that provide the
information needed to address the questions and potential actions.
In this document, each stage presents three areas to consider:
— Capability considerations: In this document, capability refers to the ability to achieve overall user
objectives in a mission or business context. User capabilities are often based on the collective effects
of multiple physical systems (referred to as “material”) as well as other factors beyond the systems
themselves (training, procedures, etc. which are referred to in this document as “non-material”). Enabling
systems can be either material or non-material as defined in this document. Typically, the development
of an SoI begins with a user need based on an identified gap in capability and a proposed SoI that focuses
on filling that capability gap. From the earliest point in its life cycle, understanding the role of the SoI in
supporting the SoS capability is a key concern, particularly understanding: 1) how the SoI is envisaged
to function in the operational or business context, 2) the constraints that context places on the SoI, and
3) the relationships, interfaces and dependencies between the SoI and other interoperating systems and
enabling systems supporting the SoS capability. Relevant ISO/IEC/IEEE 15288 processes are business or
mission analysis and stakeholder needs and requirements definition.
— Technical considerations: As SoI are evaluated, the technical impact on external stakeholders and external
systems and infrastructure should be considered. This includes both systems/services on which the SoI
depends and systems/services that depend on the SoI. Once these have been identified, the ability to
influence resource changes in interoperating systems and enabling systems should be considered. When
selecting the SoI solution, consider any constraints on the SoI imposed by its SoS. Typically, technical
considerations play an important role in the SoI’s requirements and system architecture definition.
Understanding these early and factoring them into the project planning process can be key to successful
delivery of both the SoI and the capability it enables. Relevant ISO/IEC/IEEE 15288 processes are all the
technical processes.
— Management considerations: Management issues should be considered when dependencies resulting
from interactions are negotiated with organizations providing other systems involved (e.g. interfaces,
new or changed functionality in other systems). If there is an entity with some type of responsibility that
spans an SoS, management arrangements with that entity should be established. SoS-related cost and
schedule considerations should be addressed, including identifying costs and schedules associated with
external systems. Finally, mechanisms should be in place to monitor the progress in the areas of cross-

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
system dependencies for a prompt identification of any changes or delays which can mean added cost
and time. Plans should be formulated to accommodate these if necessary. Relevant ISO/IEC/IEEE 15288
processes are all the technical management processes and all the agreement processes.
In this document, certain considerations should be addressed at multiple stages, so if a question also applies
to more than one stage.
A system can interact as part of one or more SoS in support of multiple capabilities. In this document, when
the interaction of a system with an SoS is discussed, this can include one or more SoS in support of one or
more capabilities. Thus, although the terms SoS, capability and context are used in singular form throughout
this document, each use can be plural if applicable to the situation.
4.4 SoS technical base
Annex A presents what is termed the “SoS technical base”, which reflects the type of SoS-level technical
information that would ideally be available as a reference to an SoI in addressing wider SoS considerations. As
is shown in Figure 1, this document applies to a constituent SoI in an SoS. The SoS technical base information
in Annex A can be available to provide reference information used to address the SoS considerations and
help ensure that organizations responsible for CS in the SoS can address these considerations in a consistent
manner and reduce risks at both the system and the SoS levels. It is recognized that in many cases, this
information is not available, putting an added burden on the SoI to address the SoS considerations across the
multiple organizations.
5 SoS considerations in SoI life cycle stages
5.1 Addressing SoS considerations in the concept stage
5.1.1 General
This subclause describes the SoS considerations for the SoI to be addressed in the concept stage as defined
in ISO/IEC/IEEE 24748-1:2024, 5.2.2: “The concept stage is executed to assess new business opportunities or
mission assignments for feasibility and to discern stakeholder needs and requirements. The concept stage
can be extended into evaluation of conceptual architecture and design solution.”
5.1.2 Concept stage capability considerations
In the concept stage the following capability questions should be addressed:
— Has the operational or business context of the user capability need been described?
— Has the existing user capability been described, including the systems or SoS that currently support that
capability?
— How would a new system which might address the gap fit into current operations or business processes?
— If a new system were to be considered, have interfaces with or required changes to current systems or
systems which are planned or in development been identified?
Identifying and addressing constraints are key to effective solutions. An early description of the SoS
context and its potential impact on requirements and dependencies for the SoI provide a solid basis for the
development of a system that can meet user needs, including quality characteristics.
Potential changes to other systems, interfaces and infrastructure should be identified as early as possible.
This will allow time for multi-lateral SoS trade-off analyses, considering which changes should be
implemented or where they can best be implemented and allow time for negotiations and organizational
agreements to be put in place. Early identification of dependencies between developing or planned systems
provides the opportunity to help ensure that interoperability is maintained despite changes. An early
understanding of these factors can contribute to a sound solution selection for the SoI and an assessment of
SoS risks. This is particularly important for any long-lead items.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Understanding of current operations, business processes and life cycle support is also important to set the
context for the SoI. This includes systems currently supporting the SoS capability, systems in development
or planned and any non-material elements. The full impact of alternatives should be considered in the
assessment of possible approaches for addressing the gap(s), including any required changes to operations,
business processes or life cycle support to avoid unwanted effects on other capabilities.
During the concept stage, there is a set of questions concerning the capability being sought and the context
of that need. These questions build on any capability considerations addressed previously and address the
implications at the next level of detail.
— Have operational or business context constraints on potential solutions been identified? (E.g. business or
operational continuity needs based on the importance of the capability being continuously available.)
— How would the SoI fit into current and future operations?
— Have the relationships between the SoI and other CS been communicated?
— Have interfaces with or required changes to systems in development or planned systems been identified?
— Have the benefits from and for other systems been identified? Have these been communicated to these
systems?
— Have impacts on non-material factors (e.g. personnel, training, description of how the users will conduct
the operation or business process, life cycles support, other) been described?
If there is no description of how users expect to use the new SoI that is coordinated with the overall
description of how the users will conduct operations in an SoS context or environment, the risk is that
requirements and dependencies can be missed. This can lead to an ineffective SoI when placed in an SoS
context or environment, unexpected higher costs or schedule slippage due to necessary rework.
Expected here is a written description, which contains a delineation of how the SoI will work in the context
of other systems and in the operational or business context, which is consistent with the view presented
in the description of how the users will conduct SoS operations. The context also should describe how the
new SoI is expected to be used with other systems to address the user’s capability objectives. If the written
description has not been completed, priority should be given to developing and validating how users expect
to use the new system, which identifies key elements external to the proposed system, including those that
would support the SoI through its life cycle, and their impact on system attributes and functionality – as well
as impacts of the SoI on these external factors – to help ensure compatibility with existing descriptions of
how the users will conduct operations overall.
Considering non-material factors early provides sufficient lead-time to address cross-organizational
enablers such as resources, organizational impact, training, life cycle support, personnel multi-role postings
and recruitment focus. Considering impacts or factors from the SoS or its CS helps to avoid the risk that the
solution considered or selected will fail to achieve the desired capabilities, incur added, unexpected costs or
schedule slips, or result in unwanted, negative effects on other capabilities.
— How does the proposed SoI help to address the capability gap in the context of the SoS?
A description of how the proposed SoI addresses the capability gap, in the context of the systems currently
supporting the capability, will provide the basis for understanding key attributes of the SoI and key
relationships to be considered in SoI requirements. Defining the linkage between the proposed SoI and
the other systems supporting the capability helps to avoid the risk that the system can fail to meet user
objectives. At this stage, there should be results of analysis, simulation, prototyping or experimentation
to support an assessment of consistency. If this has not been addressed, using data from simulations,
prototypes or live events, analysis should be conducted on the end-to-end actions based on the description
of how the users will conduct operations, to verify that the SoI will support the capability need in the context
of the SoS currently supporting the capability.
— Have roles of the SoI in different missions or activity threads been identified and prioritized?
A description of the variety of roles that a system will play, including any concurrent roles in multiple SoS,
will provide a strong foundation for system requirements. If a system has roles in several missions, early

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
identification of the information requirements will help to ensure availability of that information and
will help to avoid the risk that the system will fail to meet all user objectives. By this point there should
be identification of mission or SoS interfaces, information suppliers, protocols, standards responsibilities
and interoperability requirements. If this has not yet been addressed, the interoperability requirements and
driving interfaces should be identified or developed in the order of priority within resource constraints,
along with the applicable protocols and standards.
— How critical are the interoperability requirements to the interdependencies?
Understanding the criticality of SoS interoperability will provide a basis for understanding the impact of
any future trade-offs. Identifying the relative importance of interoperability requirements helps to avoid
the risk that the wrong things can be traded away. If this has not yet been addressed, develop and validate a
“criticality analysis” with stakeholders to understand the criticality and priority of various interdependent
functions.
5.1.3 Concept stage technical considerations
In the concept stage the following technical questions should be addressed:
— Have the external stakeholders and systems affected been identified? This includes both systems and
services on which the new or upgraded system depends and systems or services that depend on the new
or upgraded system.
— Is there an understanding of the ability to influence changes in associated systems or non-material
factors?
Early identification (upon entry into concept stage) of key external parties impacted by the new system
(SoI) and their ability or willingness to affect and provide the resources for the needed changes will provide
a realistic planning basis for the system development, including identification of any potential or current
shared developmental costs and tools. Describing the systems context helps to avoid the risk that the
selected solution can be infeasible due to needs of stakeholders of affected systems or an inability to adjust
associated systems to address capability gaps.
At this stage, there should be lists of external stakeholders and of dependent systems and their proponents
and resource sponsors, including maintainers for in-service systems available along with an early list of
assumptions and dependencies. If this has not been done by this stage, it would be important to explicitly
identify and contact potentially affected stakeholders to avoid risks identified above.
Several technical considerations should be addressed during this stage:
— What are the key drivers for the implementation of the SoI that can be guided by SoS related issues?
— What are the key trade-off factors for the SoI within the larger SoS that can influence constraints,
coherence (including reuse and evolution considerations), systems attributes, interfaces or other design
considerations for the system? What trade factors been considered for improving the adaptability of the
SOI for both SOI and SoS needs?
— Has the analysis been undertaken to resolve these SoS issues, and if not, how can they be resolved to
guide the implementation of this system?
— What constraints on the SoI are imposed by the SoS context for the system?
— Have these been considered in selecting the SoI solution?
Identifying the SoS drivers and constraints and top-level trade-off factors early in the concept stage helps
define the work to be done to help inform the selection of the preferred system approach (e.g. the critical
parameters that should be modelled) and provides the basis for considerations that affect the selection of
the preferred system approach. These drivers and constraints can include: physical requirements (e.g. size,
weight, cooling, power limits), electronic requirements (e.g. signature, interference), information exchange
and management (e.g. network, bandwidth, information needs), and quality characteristics (e.g. safety,
security, reliability and availability).

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
...

ISO/IEC JTC 1/SC 7 N10065
Secretariat: BIS
Date: 2026-04-01-12
Systems and software engineering — System of systems (SoS)
considerations in life cycle stages of a system
Ingénierie du logiciel et des systèmes — Études du système des systèmes (SdS) dans les étapes du cycle de vie
d'un système
FDIS stage
© ISO/IEC/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
E-mail: [e-mail]  Email: [e-mail]
Website: www.iso.org  Website:
Published in Switzerland
© 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
4 Concepts . 4
4.1 System of systems . 4
4.2 Constituent systems . 4
4.3 System life cycle stages . 5
4.4 SoS technical base . 8
5 SoS considerations in SoI life cycle stages . 9
5.1 Addressing SoS considerations in the concept stage . 9
5.2 Addressing SoS considerations in the development stage . 13
5.3 Addressing SoS considerations during the production stage . 19
5.4 Addressing SoS considerations during utilization and support stages . 19
5.5 Addressing SoS considerations in retirement stage . 22
Annex A (informative) SoS technical base . 23
Annex B (informative) Example SoS considerations in the life cycle stages of a CS . 24
Annex C (informative) Relationship to other standards . 27
Bibliography . 29
IEEE notices and abstract . 30

© ISO/IEC/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, Software and systems 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 21839:2019), which has been
technically revised.
The main changes are as follows:
— added references for interfacing and interoperating systems and general updates from
ISO/IEC/IEEE 15288:2023 and ISO/IEC/IEEE 24748-2:2024;
— updated content based on updates to ISO/IEC/IEEE 24748-1:2024, including more recent life cycle models
such as DevOps;
© ISO/IEC/IEEE 2026 – All rights reserved
iv
— the text has been updated to be aligned with ISO/IEC/IEEE 21840:2026 and ISO/IEC/IEEE 21841:2026.
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 and www.iec.ch/national-
committees.
© ISO/IEC/IEEE 2026 – All rights reserved
v
Introduction
This document is one of three standards dealing with systems of systems. (SoS). The relationship among the
three standards is described in Annex C.
There is a wide variety of systems in terms of their purpose, domain of application, complexity, size, novelty,
adaptability, quantities, locations, life spans and evolution.
This document refers to considerations to be addressed for an SoI which is a constituent system (CS) that
interoperates in an SoS. This document considers the generic life cycle model defined in ISO/IEC/IEEE 15288
and ISO/IEC/IEEE 24748-1. Selected subsets of these considerations can be addressed throughout the life of
systems through the involvement of stakeholders. The ultimate goal is to achieve customer satisfaction, so
that when delivered, the SoI will operateoperates effectively in the operational or business environment which
is typically characterized as one or more SoS.
© ISO/IEC/IEEE 2026 – All rights reserved
vi
Systems and software engineering — System of systems (SoS)
considerations in life cycle stages of a system
1 Scope
This document provides a set of critical system of systems (SoS) considerations to be addressed at key points
in the life cycle of the system -of -interest (SoI) that is a constituent system that forms a part of an SoS.
This document applies to human-made systems that are configured with one or more of the following:
hardware, software, humans, procedures and facilities.
This document also can be productively applied by users of ISO/IEC/IEEE 12207.
This document addresses SoS considerations that apply to systems at each stage of their respective life cycles.
It applies to one-of-a-kind systems, mass-produced systems or customized, adaptable systems.
This document does not elaborate in detail the methods or procedures for addressing SoS considerations.
This document does not detail the described documentation in terms of name, format, explicit content and
recording media of documentation.
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 https://ieeexplore.ieee.org/xpls/dictionary.jsp
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
capability
measure of capacity and the ability of an entity (system (3.9(3.9),), person or organization (3.7(3.7)))) to
achieve its objectives
[SOURCE: ISO/IEC 19770-1:2017, 3.10, modified — Note 1 to entry has been removed]
3.2
constituent system
CS
independent system (3.9(3.9)) that forms part of a system of systems (SoS) (3.12(3.12))
© ISO/IEC/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, utilization, goals, and resources, but interacts within the SoS to provide the unique
capability (3.1(3.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.10(3.10)) 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(3.1).)
1)
[SOURCE: ISO/IEC/IEEE 21840:2026,:— , 3.1.2]
3.3
governance
practice of establishing and enforcing strategic goals and objectives, organizational policies, and performance
parameters
[SOURCE: ISO/IEC/IEEE 12207:2026,21840:—, 3.1.284]
3.4
interoperating system
system (3.9(3.1.9)) that exchanges information with the system -of -interest (3.13(3.1.11)) and uses the
information that has been exchanged
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.20]
3.5
life cycle
evolution of a system (3.9(3.9),), product, service, project or other human-made entity from conception
through retirement
[SOURCE: ISO/IEC/IEEE 24748-1:2024, 3.24]
3.6
management
system (3.9(3.9)) of controls and processes required to achieve the strategic objectives set by the
organization's (3.7(3.7)) governing body
Note 1 to entry: Management is subject to the policy guidance and monitoring set through corporate governance
(3.3(3.3).).
[SOURCE: ISO/IEC/IEEE 21840:2026,:—, 3.1.76]
3.7
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.]

1)
Under preparation. Stage at the time of publication: ISO/IEC/IEEE FDIS 21839.

© ISO/IEC/IEEE 2026 – All rights reserved
3.8
stage
period within the life cycle (3.5(3.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.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.
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.10
system element
discrete part of a system (3.9(3.9)) 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.11
system of systems
SoS
set of systems (3.9(3.9)) or system elements (3.10(3.10)) that interact to provide a unique capability (3.1(3.1))
that none of the constituent systems (3.2(3.2))can accomplish on its own
Note 1 to entry: System elements can be necessary to facilitate the 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.
[SOURCE: ISO/IEC/IEEE 21840:2026, —, 3.1.1311]
3.12
system of systems engineering
SoSE
process of planning, analysing, organizing, developing and integrating the capabilities (3.1(3.1)) of a mix of
existing and new systems (3.9(3.9),), including inter-system infrastructure, facilities, and overarching
© ISO/IEC/IEEE 2026 – All rights reserved
processes into a system -of -systems (3.11) capability that is greater than the sum of the capabilities of the
constituent systems (3.2(3.2))
Note 1 to entry: SoSE also includes testing, modification, maintenance and other post-integration activities.
[SOURCE: ISO/IEC/IEEE 21840:2026, —, 3.1.1412]
3.13
system -of -interest
SoI
system (3.9(3.9)) whose life cycle (3.5(3.5)) is under consideration
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.48]
3.14
systems engineering
transdisciplinary and integrative approach to enable the successful realization, use, and retirement of
engineered systems (3.11(3.1.11)) using systems principles and concepts and scientific, technological and
management (3.6(3.6)) methods
[SOURCE: INCOSE-TP-2020-002-06]
4 Concepts
4.1 System of systems
Both individual systems and SoS conform to the accepted definition of a system in that each consists of parts,
relationships and a whole that is greater than the sum of the parts; however, while all SoS are systems, not all
systems are SoS, even if multiple systems are interacting with each other.
[13][]
Maier postulated five key characteristics (not criteria) of SoS: operational independence of constituent
systems (CS), managerial independence of CS, geographical distribution, emergent behaviour and
evolutionary development processes. Maier identified operational independence and managerial
independence as the two principal distinguishing characteristics for applying the term “systems of systems”.
A system that does not exhibit these two characteristics is not an SoS regardless of the complexity or
geographic distribution of its constituents.
An essential characteristic is that each CS within the SoS is operationally independent. 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.
In an SoS, systems are also managerially independent. That is, each CS is likely to be managed by organizations
with a level of independence, with potentially different goals and objectives for the CS.
In some cases, there can be a designated entity with some type of responsibility that spans an SoS. These
managerial arrangements can be loosely defined or more highly structured depending on the particular
situation. In other cases, no such entity exists. CS have their own stakeholders and CS remain managerially
and operationally independent; managers of CS managers or CS projects can be unaware, unable or unwilling
to make adjustments to address SoS-desired capabilities.
4.2 Constituent systems
An essential concept is that the SoS is composed of CS (and can include other system elements) that
operationally interact to provide capabilities that no one system or element in the SoS can provide by itself.
© ISO/IEC/IEEE 2026 – All rights reserved
Each CS is an independent system that provides capabilities to meet its specified mission or business objective
and has its own life cycle, management and governance, and technical requirements. CS can include systems
which are considered as infrastructure. A CS can be an entity in more than one SoS. An SoS is often composed
of existing CS along with new CS which are developed and integrated into the SoS. The focus of this document
is a CS as the SoI, as is shown in Figure 1. The considerations provided in this document are with respect to
what is necessary to account for the life cycle of the CS or SoI to enable it to interact in the anticipated SoS
configurations.
Figure 1— Focus of this document is on the CS in an SoS
SoS and CS can apply to any domain. In a money transfer SoS (see an example in Annex B), CS can include
different banks. In a military SoS, weapons and communication systems can be considered CS. In an air
transportation SoS, CS can include the air traffic management systems, airports and aircraft. This document
addresses the SoS considerations for the life cycle stages of systems (new or evolving) which are constituents
of one or more SoS.
4.3 System life cycle stages
As an SoS evolves, each CS follows representative life cycle stages for its own evolution. A generic system life
cycle model defined in ISO/IEC/IEEE 24748-1 includes the stages: concept, development, production,
utilization, support and retirement. These stages should not be construed to mean a sequence or a linear
© ISO/IEC/IEEE 2026 – All rights reserved
progression between stages. Stages can be implemented in different progression with iteration and recursion
possible, one example of which is shown in Figure 2Figure 2. An alternate system life cycle model with
different stage names is shown in Figure 3Figure 3. (See ISO/IEC/IEEE 32675 for more information about
DevOps.) Table 1Table 1 summarizes the main purpose of each life cycle stage and shows decision options
common across all life cycle stages. ISO/IEC/IEEE 24748-1 includes elaboration on the purpose of each stage.

NOTE Adapted from ISO/IEC/IEEE 24748-1:2024, Figure 6.
Figure 2— Possible progress of life
© ISO/IEC/IEEE 2026 – All rights reserved
NOTE See ISO/IEC/IEEE 24748-1:2024, Figure 5.
Figure 3— Development and operations (DevOps) example life cycle stages cycle stages
Table 1— Life cycle stages, their purposes and decisions options
Life cycle stages Objective Decision options
— Begin subsequent stage or
Identify stakeholders' needs
stages
Concept Explore concepts
Propose viable solutions
— Continue this stage
Refine system requirements
— End this stage
Create solution description
Development
Build system
— Go to or restart a preceding
stage
Verify and validate system
Produce systems
— Hold project activity
Production
Inspect and test
— Terminate project
Utilization Operate system to satisfy users' needs
Support Provide sustained system capability
Retirement Store, archive or dispose of system
In this document, SoS considerations are addressed at each of these stages for an SoI that is intended to
interact with other systems (a CS of an SoS). The stages are addressed as follows: concept (5.1(),), development
(5.2(),), production (5.3(),), utilization and support (5.4()) and retirement (5.5().).
© ISO/IEC/IEEE 2026 – All rights reserved
As the focus of this document is the life cycle of the CS as the SoI, SoS considerations to be addressed in each
stage in the life cycle of a system are presented as a list of questions along with the supporting material. SoS
considerations are grouped into three areas: capability, technical and management (including schedule and
cost). This document addresses both the benefit to the SoI of addressing these SoS questions and the risks of
failing to address the questions. It identifies the type of information or artefacts that provide the information
needed to address the questions and potential actions.
In this document, each stage presents three areas to consider:
— Capability considerations: In this document, capability refers to the ability to achieve overall user
objectives in a mission or business context. User capabilities are often based on the collective effects of
multiple physical systems (referred to as “material”) as well as other factors beyond the systems
themselves (training, procedures, etc. which are referred to in this document as “non-material”). Enabling
systems can be either material or non-material as defined in this document. Typically, the development of
an SoI begins with a user need based on an identified gap in capability and a proposed SoI that focuses on
filling that capability gap. From the earliest point in its life cycle, understanding the role of the SoI in
supporting the SoS capability is a key concern, particularly understanding: 1) how the SoI is envisaged to
function in the operational or business context, 2) the constraints that context places on the SoI, and 3)
the relationships, interfaces and dependencies between the SoI and other interoperating systems and
enabling systems supporting the SoS capability. Relevant ISO/IEC/IEEE 15288 processes are business or
mission analysis and stakeholder needs and requirements definition.
— Technical considerations: As SoI are evaluated, the technical impact on external stakeholders and external
systems and infrastructure should be considered. This includes both systems/services on which the SoI
depends and systems/services that depend on the SoI. Once these have been identified, the ability to
influence resource changes in interoperating systems and enabling systems should be considered. When
selecting the SoI solution, consider any constraints on the SoI imposed by its SoS. Typically, technical
considerations play an important role in the SoI’s requirements and system architecture definition.
Understanding these early and factoring them into the project planning process can be key to successful
delivery of both the SoI and the capability it enables. Relevant ISO/IEC/IEEE 15288 processes are all the
technical processes.
— Management considerations: Management issues should be considered when dependencies resulting from
interactions are negotiated with organizations providing other systems involved (e.g. interfaces, new or
changed functionality in other systems). If there is an entity with some type of responsibility that spans an
SoS, management arrangements with that entity should be established. SoS-related cost and schedule
considerations should be addressed, including identifying costs and schedules associated with external
systems. Finally, mechanisms should be in place to monitor the progress in the areas of cross-system
dependencies for a prompt identification of any changes or delays which can mean added cost and time.
Plans should be formulated to accommodate these if necessary. Relevant ISO/IEC/IEEE 15288 processes
are all the technical management processes and all the agreement processes.
In this document, certain considerations should be addressed at multiple stages, so if a question also applies
to more than one stage.
A system can interact as part of one or more SoS in support of multiple capabilities. In this document, when
the interaction of a system with an SoS is discussed, this can include one or more SoS in support of one or more
capabilities. Thus, although the terms SoS, capability and context are used in singular form throughout this
document, each use can be plural if applicable to the situation.
4.4 SoS technical base
Annex A presents what is termed the “SoS technical base”, which reflects the type of SoS-level technical
information that would ideally be available as a reference to an SoI in addressing wider SoS considerations.
As is shown in Figure 1, this document applies to a constituent SoI in an SoS. The SoS technical base
© ISO/IEC/IEEE 2026 – All rights reserved
information in Annex A can be available to provide reference information used to address the SoS
considerations and help ensure that organizations responsible for CS in the SoS can address these
considerations in a consistent manner and reduce risks at both the system and the SoS levels. It is recognized
that in many cases, this information is not available, putting an added burden on the SoI to address the SoS
considerations across the multiple organizations.
5 SoS considerations in SoI life cycle stages
5.1 Addressing SoS considerations in the concept stage
5.1.1 General
This subclause describes the SoS considerations for the SoI to be addressed in the concept stage as defined in
ISO/IEC/IEEE 24748-1:2024, 5.2.2: “The concept stage is executed to assess new business opportunities or
mission assignments for feasibility and to discern stakeholder needs and requirements. The concept stage can
be extended into evaluation of conceptual architecture and design solution.”
5.1.2 Concept stage capability considerations
In the concept stage the following capability questions should be addressed:
— Has the operational or business context of the user capability need been described?
— Has the existing user capability been described, including the systems or SoS that currently support that
capability?
— How would a new system which might address the gap fit into current operations or business processes?
— If a new system were to be considered, have interfaces with or required changes to current systems or
systems which are planned or in development been identified?
Identifying and addressing constraints are key to effective solutions. An early description of the SoS context
and its potential impact on requirements and dependencies for the SoI provide a solid basis for the
development of a system that can meet user needs, including quality characteristics.
Potential changes to other systems, interfaces and infrastructure should be identified as early as possible. This
will allow time for multi-lateral SoS trade-off analyses, considering which changes should be implemented or
where they can best be implemented and allow time for negotiations and organizational agreements to be put
in place. Early identification of dependencies between developing or planned systems provides the
opportunity to help ensure that interoperability is maintained despite changes. An early understanding of
these factors can contribute to a sound solution selection for the SoI and an assessment of SoS risks. This is
particularly important for any long-lead items.
Understanding of current operations, business processes and life cycle support is also important to set the
context for the SoI. This includes systems currently supporting the SoS capability, systems in development or
planned and any non-material elements. The full impact of alternatives should be considered in the
assessment of possible approaches for addressing the gap(s), including any required changes to operations,
business processes or life cycle support to avoid unwanted effects on other capabilities.
During the concept stage, there is a set of questions concerning the capability being sought and the context of
that need. These questions build on any capability considerations addressed previously and address the
implications at the next level of detail.
— Have operational or business context constraints on potential solutions been identified? (E.g. business or
operational continuity needs based on the importance of the capability being continuously available.)
© ISO/IEC/IEEE 2026 – All rights reserved
— How would the SoI fit into current and future operations?
— Have the relationships between the SoI and other CS been communicated?
— Have interfaces with or required changes to systems in development or planned systems been identified?
— Have the benefits from and for other systems been identified? Have these been communicated to these
systems?
— Have impacts on non-material factors (e.g. personnel, training, description of how the users will conduct
the operation or business process, life cycles support, other) been described?
If there is no description of how users expect to use the new SoI that is coordinated with the overall description
of how the users will conduct operations in an SoS context or environment, the risk is that requirements and
dependencies can be missed. This can lead to an ineffective SoI when placed in an SoS context or environment,
unexpected higher costs or schedule slippage due to necessary rework.
Expected here is a written description, which contains a delineation of how the SoI will work in the context of
other systems and in the operational or business context, which is consistent with the view presented in the
description of how the users will conduct SoS operations. The context also should describe how the new SoI
is expected to be used with other systems to address the user’s capability objectives. If the written description
has not been completed, priority should be given to developing and validating how users expect to use the
new system, which identifies key elements external to the proposed system, including those that would
support the SoI through its life cycle, and their impact on system attributes and functionality – as well as
impacts of the SoI on these external factors – to help ensure compatibility with existing descriptions of how
the users will conduct operations overall.
Considering non-material factors early provides sufficient lead-time to address cross-organizational enablers
such as resources, organizational impact, training, life cycle support, personnel multi-role postings and
recruitment focus. Considering impacts or factors from the SoS or its CS helps to avoid the risk that the solution
considered or selected will fail to achieve the desired capabilities, incur added, unexpected costs or schedule
slips, or result in unwanted, negative effects on other capabilities.
— How does the proposed SoI help to address the capability gap in the context of the SoS?
A description of how the proposed SoI addresses the capability gap, in the context of the systems currently
supporting the capability, will provide the basis for understanding key attributes of the SoI and key
relationships to be considered in SoI requirements. Defining the linkage between the proposed SoI and the
other systems supporting the capability helps to avoid the risk that the system can fail to meet user objectives.
At this stage, there should be results of analysis, simulation, prototyping or experimentation to support an
assessment of consistency. If this has not been addressed, using data from simulations, prototypes or live
events, analysis should be conducted on the end-to-end actions based on the description of how the users will
conduct operations, to verify that the SoI will support the capability need in the context of the SoS currently
supporting the capability.
— Have roles of the SoI in different missions or activity threads been identified and prioritized?
A description of the variety of roles that a system will play, including any concurrent roles in multiple SoS, will
provide a strong foundation for system requirements. If a system has roles in several missions, early
identification of the information requirements will help to ensure availability of that information and will help
to avoid the risk that the system will fail to meet all user objectives. By this point there should be identification
of mission or SoS interfaces, information suppliers, protocols, standards responsibilities and interoperability
requirements. If this has not yet been addressed, the interoperability requirements and driving interfaces
should be identified or developed in the order of priority within resource constraints, along with the
applicable protocols and standards.
© ISO/IEC/IEEE 2026 – All rights reserved
— How critical are the interoperability requirements to the interdependencies?
Understanding the criticality of SoS interoperability will provide a basis for understanding the impact of any
future trade-offs. Identifying the relative importance of interoperability requirements helps to avoid the risk
that the wrong things can be traded away. If this has not yet been addressed, develop and validate a “criticality
analysis” with stakeholders to understand the criticality and priority of various interdependent functions.
5.1.3 Concept stage technical considerations
In the concept stage the following technical questions should be addressed:
— Have the external stakeholders and systems affected been identified? This includes both systems and
services on which the new or upgraded system depends and systems or services that depend on the new
or upgraded system.
— Is there an understanding of the ability to influence changes in associated systems or non-material factors?
Early identification (upon entry into concept stage) of key external parties impacted by the new system (SoI)
and their ability or willingness to affect and provide the resources for the needed changes will provide a
realistic planning basis for the system development, including identification of any potential or current shared
developmental costs and tools. Describing the systems context helps to avoid the risk that the selected solution
can be infeasible due to needs of stakeholders of affected systems or an inability to adjust associated systems
to address capability gaps.
At this stage, there should be lists of external stakeholders and of dependent systems and their proponents
and resource sponsors, including maintainers for in-service systems available along with an early list of
assumptions and dependencies. If this has not been done by this stage, it would be important to explicitly
identify and contact potentially affected stakeholders to avoid risks identified above.
Several technical considerations should be addressed during this stage:
— What are the key drivers for the implementation of the SoI that can be guided by SoS related issues?
— What are the key trade-off factors for the SoI within the larger SoS that can influence constraints,
coherence (including reuse and evolution considerations), systems attributes, interfaces or other design
considerations for the system? What trade factors been considered for improving the adaptability of the
SOI for both SOI and SoS needs?
— Has the analysis been undertaken to resolve these SoS issues, and if not, how can they be resolved to guide
the implementation of this system?
— What constraints on the SoI are imposed by the SoS context for the system?
— Have these been considered in selecting the SoI solution?
Identifying the SoS drivers and constraints and top-level trade-off factors early in the concept stage helps
define the work to be done to help inform the selection of the preferred system approach (e.g. the critical
parameters that should be modelled) and provides the basis for considerations that affect the selection of the
preferred system approach. These drivers and constraints can include: physical requirements (e.g. size,
weight, cooling, power limits), electronic requirements (e.g. signature, interference), information exchange
and management (e.g. network, bandwidth, information needs), and quality characteristics (e.g. safety,
security, reliability and availability).
Identifying drivers, trade-off factors and constraints is key to developing effective solutions. Understanding
these early can contribute to the selection of a sound and feasible solution. Recognizing the SoS drivers and
© ISO/IEC/IEEE 2026 – All rights reserved
constraints and resulting requirements helps to avoid the risk that the resulting SoI can fail to operate as
expected or meet the needs of the SoS environment or can incur unexpected additional time or budget for
rework. This also should consider if the SoS meets its stakeholder needs, as it can operate as expected, but fail
to meet the needs. Results of early engineering analyses would highlight the impacts on the solutions; ideally
these impacts would have been addressed in the analysis of solution options and are considered in the selected
solution, helping to mitigate the risks. If this has not been addressed, document the drivers and constraints of
the SoS context on alternative system solutions and the way the selected system solution addresses these
constraints.
— What are the dependencies and interfaces for the system?
Describe how the system dependencies and interfaces have been identified and are defined and controlled.
Additional questions include how tightly coupled are the interdependent systems and how will the interfaces
be managed across the different systems? Dependencies can be key to an SoI to success in meeting user needs,
so identifying these early in the life cycle provides a sound basis for the selection of the most appropriate
solution. Identifying the dependencies and interfaces when assessing alternatives or identifying preferred
options helps to avoid the risk that the resulting system fails to address these dependencies in the system
requirements or the system design, etc., and hence the SoI can fail to perform as needed in the intended SoS
environment.
During this stage, there should be a representation of the SoS architecture with the identification of interfaces
and dependencies to the solution options and inclusion of these in the analysis of options and in the definition
of the preferred solution. If the representation has not been addressed, utilize the description of how the users
can conduct the end-to-end set of actions supporting the user capability as well as a representation of the SoS
architecture. This description can be employed to define the role of the proposed SoI with respect to other
systems, in terms of interfaces and other physical and logical functions. These factors should be included in
the assessment of system options.
— Are there any other systems critical to the success of the proposed SoI? Who is responsible for these
systems, and do they acknowledge the dependency?
— Are there impacts on these systems that should be addressed to meet the capability needs once the new
system or system upgrade is implemented?
Identifying where other systems are key to the SoS success and making early contact with their management
can provide the basis for successful collaboration throughout the development. Addressing expectations of
other systems (things they should change or things they should continue to do) helps to avoid the risk that the
selected solution option alone will be insufficient to meet user needs. At this stage, identification of the
external systems and recognition of their roles in the mission should be defined. If this identification has not
been addressed, develop a functional allocation across systems to allow the identification of external
dependencies to be addressed during the selection of the preferred solution.
5.1.4 Concept stage management considerations
In the concept stage the following management questions should be addressed:
— What entity (if any) is responsible for each SoS in which the SoI is intended to interact?
— Wh
...