ISO/IEC/IEEE 21839:2019

INTERNATIONAL ISO/IEC/
STANDARD IEEE
First edition
2019-07
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
Reference number
©
ISO/IEC 2019
©
IEEE 2019
© ISO/IEC 2019
© IEEE 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the 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
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org stds.ipr@ieee.org
www.iso.org www.ieee.org
Published in Switzerland
© ISO/IEC 2019 – All rights reserved
ii © IEEE 2019 – All rights reserved

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 . 2
4 Concepts . 3
4.1 System of systems. 3
4.2 Constituent systems . 3
4.3 System life cycle stages . 4
4.4 SoS technical base . 6
5 System of systems considerations in SoI life cycle stages . 6
5.1 SoS considerations in the Concept Stage . 6
5.1.1 General. 6
5.1.2 Concept stage capability considerations . 6
5.1.3 Concept Stage technical considerations . 9
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 . .15
5.2.4 Development stage management considerations .17
5.3 Addressing SoS considerations during the production stage .19
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.20
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) System of systems technical base .27
Annex B (informative) Example SoS considerations in the life cycle stages of a constituent
system .28
Annex C (informative) Relationship to other standards .30
Bibliography .31
IEEE notices and abstract .32
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – 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 ISO documents should be noted. This document was drafted in accordance with the
rules given in the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of
the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents) or the IEC
list of patent declarations received (see http: //patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
ISO/IEC/IEEE 21839 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.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
© ISO/IEC 2019 – All rights reserved
iv © IEEE 2019 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC/IEEE 21839:2019(E)
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 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.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC/IEEE 24765, Systems and software engineering — Vocabulary
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions in ISO/IEC/IEEE 24765 and the
following apply.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 1

ISO, IEC and IEEE maintain terminological databases for use in standardization at the following
addresses:
— ISO Online browsing platform: available at https: //www .iso .org/
— IEC Electropedia: available at https: //www .electropedia .org/
— IEEE Standards Dictionary Online: available at https: //ieeexplore .ieee .org/xpls/dictionary .jsp
3.1.1
constituent system
independent system that forms part of a system of systems (SoS) (3.1.4)
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 of the SoS.
3.1.2
life cycle
evolution of a system, product, service, project or other human-made entity from conception through
retirement
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.23]
3.1.3
system of interest
SoI
system whose life cycle is under consideration in the context of this document
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.48, modified — the abbreviated term "SoI" has been added;
“this International Standard” has been replaced with “this document”.]
3.1.4
system of systems
SoS
set of systems or system elements that interact to provide a unique capability that none of the constituent
systems (3.1.1) 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.
3.1.5
stage
period within the life cycle of an entity that relates to the state of its description or realization
Note 1 to entry: As used in this document, stages relate to major progress and achievement milestones of the
entity through its life cycle.
Note 2 to entry: Stages often overlap.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.43, modified — “this International Standard” has been
replaced with “this document”.]
3.2 Abbreviated terms
SoI system of interest
SoS system of systems
SoSE system of systems engineering
© ISO/IEC 2019 – All rights reserved
2 © IEEE 2019 – All rights reserved

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, although an SoS is a
system, not all systems are SoS.
Maier (1998) postulated five key characteristics (not criteria) of SoS: operational independence of
component systems, managerial independence of component systems, geographical distribution,
emergent behavior 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 considered a
[5]
system-of-systems regardless of the complexity or geographic distribution of its components .
An essential characteristic is that each constituent system within the SoS is operationally independent.
That is, each constituent system can operate independently to fulfil some number of purposes on its own.
In an SoS, systems are also managerially independent. That is, each constituent system is likely to be
managed by organizations with a level of independence, with potentially different goals and objectives
for the constituent systems.
In some cases, there may be a designated entity with some type of responsibility that spans an SoS.
These managerial arrangements may be loosely defined or more highly structured depending on the
particular situation. In other cases, no such entity may exist.
4.2 Constituent systems
An essential concept is that the system of systems is comprised of constituent systems (and may
include other elements) that interact to provide capabilities that no one system or element in the SoS
can provide by itself. Each constituent system 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. Constituent systems include systems which are often considered as
infrastructure, such as communications systems. A constituent system can be an entity in more than
one SoS. An SoS is often comprised of existing constituent systems along with new constituent systems
which are developed and integrated into the SoS. The focus of this document is a constituent system 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 constituent system or SoI to enable it to interact in the
anticipated SoS configurations.
Figure 1 — Focus of the document is on the constituent system in an SoS
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 3

SoS and constituent systems can apply to any domain. For example, in an air transportation SoS,
constituent systems may include the air traffic management systems, airports and aircraft. In a
money transfer SoS (see an example in Annex B), constituent systems may include different banks. In
a military SoS, weapons, sensors and communication systems may be considered constituent systems.
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 a system of systems evolves, each constituent system follows the representative life cycle stages
for its own evolution. The representative life cycle stages are shown in Figure 2. These stages may 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:2018, Figure 6.
Figure 2 — Life cycle stages
NOTE See ISO/IEC/IEEE 24748-1:2018, Figure 7.
Figure 3 — Possible progress of life cycle stages
© ISO/IEC 2019 – All rights reserved
4 © IEEE 2019 – All rights reserved

Table 1 — Life cycle stages, their purposes and decisions options
Life cycle
Purpose Decision options
stages
Identify stakeholders' needs
Concept Explore concepts
Propose viable solutions
— Begin subsequent
Refine system requirements
stage or stages
Create solution description
Development — Continue this
Build system
stage
Verify and validate system
— Go to or restart a
Produce systems
preceding stage
Production
Inspect and test
— Hold project
Operate system to satisfy
activity
Utilization
users' needs
— Terminate project
Provide sustained system
Support
capability
Store, archive or dispose of
Retirement
system
NOTE  See ISO/IEC/IEEE 24748-1:2018, Table 1.
In this document, system of systems considerations are addressed at each of these stages for a system
of interest that is intended to interact with other systems (a constituent system of an SoS) as shown
in Figure 3. The stages are addressed as follows: Concept (5.1), Development (5.2), Production (5.3),
Utilisation and Support (5.4) and Retirement (5.5).
As the focus of this document is the life cycle of the constituent system as the system of interest,
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). The document addresses both the
benefit to the system of addressing these SoS questions and the risks of failing to address the questions.
It identifies the type of information or artifacts 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”).
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 needed 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 systems supporting the capability. Relevant ISO/IEC/IEEE 15288
processes are Business or Mission Analysis and Stakeholder Needs and Requirements Definition.
— Technical considerations: As alternative approaches to the SoI are evaluated, consider the
technical impact on external stakeholders and external systems and infrastructure. This includes
both systems/services on which the SoI depends and systems/services that depend on the SoI. Once
these have been identified, assess the ability to influence resource changes in associated systems,
infrastructure or nonmaterial factors. Consider any constraints on the SoI imposed by its SoS
context in selecting the system solution. As the SoI life cycle moves into requirements definition
and design, the technical considerations play a larger role. Understanding these early and factoring
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 5

them into the technical 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: Consider management issues when dependencies resulting from
interactions need to be negotiated with 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, establish management arrangements with that entity. SoS-related cost and schedule
considerations need to 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 could mean
added cost and time. Plans need to 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 need to be addressed at multiple stages, so if a question also
applies to more than one stage, this is noted.
A system may 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 may 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 may be available to provide reference information used to
address the SoS considerations and help ensure that organizations responsible for constituent systems
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 may not be available, putting an
added burden on the SoI to address the SoS considerations across the multiple organizations.
5 System of systems considerations in SoI life cycle stages
5.1 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:2018, 5.2. Details of the Concept Stage from ISO/IEC/IEEE 24748-1 are
shown in Box 1.
5.1.2 Concept stage capability considerations
Upon entry into the Concept Stage, evaluate all available information that is relevant to help understand
the user capability needs and identify information gaps. In particular, address questions concerning the
understanding of the capability being sought, and the context of that user capability need, including,
but not limited to:
— 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?
© ISO/IEC 2019 – All rights reserved
6 © IEEE 2019 – All rights reserved

— 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 need to 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. Consider the full impact of alternatives 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.
Box 1 Concept Stage
(From ISO/IEC/IEEE 24748-1:2018)
Concept Stage (5.2)
Overview (5.2.1)
The Concept Stage begins with initial recognition of a need or a requirement for a new system-of-in-
terest or for the modification to an existing system-of-interest. This is an initial exploration, fact find-
ing, 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 feedback to the concept is obtained.
One or more alternative concepts to meet the identified need or requirement are developed through
analysis, feasibility evaluations, estimations (such as cost, schedule, market intelligence and logis-
tics), trade-off studies, and experimental or prototype development and demonstration. The need for
one or more enabling systems for development, production, utilization, support and retirement of the
system-of-interest is identified and candidate solutions are included in the evaluation of alternatives
in order to arrive at a balanced, life cycle solution. Typical outputs are stakeholder requirements, con-
cepts of operation, assessment of feasibility, 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 cost and human resource requirements estimates and preliminary pro-
ject schedules. Decisions are made whether to continue 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.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 7

Purpose (5.2.2)
The Concept Stage is executed to assess new business opportunities or mission assignments and to
develop preliminary system requirements and a feasible architecture and design solution.

Outcomes (5.2.3)
The outcomes of the Concept Stage are listed below.
a) Plans and exit criteria for the Concept Stage;
b) The identification of new concepts that offer such things as new capabilities, enhanced overall
performance, or reduced stakeholders' total ownership costs over the system life cycle;
c) An assessment of feasible system-of-interest concepts, with initial architectural and other
solutions, including enabling systems throughout the life cycle, for closure against both technical
and business or mission stakeholder objectives;
d) The preparation and baselining of stakeholder requirements and preliminary system requirements
(technical specifications for he selected system-of-interest and usability specifications for the
envisaged human-machine interaction);
e) Refinement of the outcomes and cost estimates for stages of the system life cycle model;
f) Risk identification, assessment and mitigation plans for this and subsequent stages of system life
cycle model;
g) Identification and initial specification of the services needed from enabling systems throughout
the life of the system;
h) Concepts for execution of all succeeding stages;
i) Definition of the enabling system services required in subsequent stages;
j) Plans and exit criteria for the Development Stage;
k) Satisfaction of stage exit criteria;
l) Approval to proceed to the appropriate stage or stages, based on the specific life cycle model in
use by the project.
— 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 constituent systems 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
© ISO/IEC 2019 – All rights reserved
8 © IEEE 2019 – All rights reserved

requirements and dependencies may 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 will also need
to 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 constituent
systems 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 may fail
to meet user objectives. At this stage, there should be results of analysis, simulation, prototyping or
experimentation to support an assessment of consistency or change from the previous stage. 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 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 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 may 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
Upon entry to 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.
© ISO/IEC 2019 – All rights reserved
© IEEE 2019 – All rights reserved 9

— 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 may 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 (cost, schedule, performance) that may
be guided by SoS related issues?
— What are the key trade-off factors for the SoI within the larger SoS that may influence constraints,
coherence (including reuse and evolution considerations), systems attributes, interfaces or other
design considerations for the system?
— 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 may need to be modelled) and provides the basis for considerations that
affect the selection of the preferred system approach. These drivers and constraints may include:
physical requirements (e.g., size, weight, cooling, power limits), electronic requirements (e.g., signature,
interference, etc.), information exchange and management (e.g., network, bandwidth, information
needs, etc.), safety, system assurance (e.g., security, information assurance, system integrity), and
reliability and availability (e.g., to maintain business and operational continuity).
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 constraints and resulting requirements helps to avoid the risk that the resulting
SoI may fail to operate as expected or meet the needs of the SoS environment or may incur unexpected
additional time or budget for rework. This also needs to consider if the SoS meets its stakeholder needs,
as it could 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
may fail to perform as needed in the intended SoS environment.
© ISO/IEC 2019 – All rights reserved
10 © IEEE 2019 – All rights reserved

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
...