ISO/IEC TS 24748-6:2016

Systems and software engineering - Life cycle management - Part 6: System integration engineering

ISO/IEC TS 24748-6:2016 - specifies activities and processes to be implemented for engineering the integration of systems-of-interest throughout the life cycle (systems made of products and/or services; see Note 1), - provides guidance for the integration process and its relationships to other system life cycle processes as described in ISO/IEC/IEEE 15288, - specifies the information items to be produced through the implementation of the integration engineering (integration process and its relationships to other system life cycle processes), - specifies the contents of the information items, and - provides guidelines for the format of the information items. ISO/IEC TS 24748-6:2016 can be applied to - those who use or plan to use ISO/IEC/IEEE 15288 on projects dealing with man-made systems, software-intensive systems, products and services related to those systems, regardless of project scope, methodology, size or complexity, and - anyone performing integration engineering activities to aid in ensuring that the application of the integration process and its relationships to other system life cycle processes conform to ISO/IEC/IEEE 15288.

Ingénierie des systèmes et du logiciel — Gestion du cycle de vie — Partie 6: Ingénierie de l'intégration du système

General Information

• Status: Withdrawn
• Publication Date: 20-Nov-2016
• 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: 9599 - Withdrawal of International Standard
• Start Date: 18-Jul-2023
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC/IEEE 24748-6:2023 - Systems and software engineering - Life cycle management - Part 6: System and software integration
• Effective Date: 06-Jun-2022

Standards Content (Sample)

TECHNICAL ISO/IEC TS
SPECIFICATION 24748-6
First edition
2016-12-01
Systems and software engineering —
Life cycle management —
Part 6:
System integration engineering
Ingénierie des systèmes et du logiciel — Gestion du cycle de vie —
Partie 6: Ingénierie de l’intégration du système
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviatied terms . 4
4 Conformance . 4
4.1 Intended usage . 4
4.2 Conformance to processes . 4
4.3 Conformance to information item content . 4
4.4 Full conformance. 5
4.5 Tailored conformance . 5
4.5.1 Processes . 5
4.5.2 Information items . 5
5 Concepts and principles . 5
5.1 General . 5
5.2 Integration fundamentals . 5
5.2.1 Terms and approaches . 5
5.2.2 Notions of aggregate and of interface . 7
5.2.3 Integration based on architecture and design . 8
5.2.4 Integration by layers of systems . 9
5.2.5 Environmental context .10
5.2.6 Integration strategy .11
5.2.7 Verification principles related to integration engineering .17
5.2.8 Validation principles related to integration engineering .18
5.2.9 Efficiency of the integration strategy .18
5.3 Practical considerations .19
5.3.1 Iteration and recursion of processes .19
5.3.2 Integration Enabling System .19
6 Processes .22
6.1 Integration engineering activities .22
6.2 Integration Process .22
6.2.1 Purpose .22
6.2.2 Outcomes .23
6.2.3 Activities and tasks .24
6.3 Other technical processes related to integration engineering .28
6.3.1 Business or mission analysis process .28
6.3.2 Stakeholder needs and requirements definition process .28
6.3.3 System requirements definition process .28
6.3.4 Architecture definition process .29
6.3.5 Design definition process .29
6.3.6 System analysis process.30
6.3.7 Verification process .30
6.3.8 Validation process . . .30
6.4 Integration management .30
6.4.1 Management overview .30
6.4.2 Composition of integration teams and skills .30
6.4.3 Integration planning, assessment and control .31
6.4.4 Relationship to Project assessment and control .31
6.4.5 Relationship to Configuration management .31
6.4.6 Relationship to Agreement processes .32
© ISO/IEC 2016 – All rights reserved iii

7 Information items outlines .32
7.1 Integration Plan .32
7.2 System Integration Aggregate Definition Information .33
7.3 System Integration Procedure and Report .33
Bibliography .35
iv © ISO/IEC 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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).
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).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 7, Systems and software engineering.
A list of all parts of the ISO/IEC 24748 series can be found on the ISO website.
© ISO/IEC 2016 – All rights reserved v

Introduction
This document was developed in response to a need for consistent terminology, definitions and
guidance that elaborates the area of system integration, taking into account the context of use and the
proven practices for the development of systems.
ISO/IEC/IEEE 15288 includes an integration process that focuses on physically assembling the
implemented system elements composing a system to obtain an “integrated system”. This process
interfaces directly to other technical processes and indirectly to activities and tasks of other technical
processes, in particular, the processes that define the system requirements, architecture and design.
The purpose of this document is to facilitate the usage of the integration process of the latest revision of
ISO/IEC/IEEE 15288 by providing guidance on system integration.
This document describes the integration engineering activities dealing with planning, performing and
managing the integration of a system, including the related activities of other technical processes, in
particular, verification and validation processes. These are real practices in industry, i.e. the integration
of a system is technically engineered and managed as a project (included in the system development
project). Although these practices are performed, they were not formalized in a standard or a guide
when this document was written.
vi © ISO/IEC 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 24748-6:2016(E)
Systems and software engineering — Life cycle
management —
Part 6:
System integration engineering
1 Scope
This document
— specifies activities and processes to be implemented for engineering the integration of systems-of-
interest throughout the life cycle (systems made of products and/or services; see Note 1),
— provides guidance for the integration process and its relationships to other system life cycle
processes as described in ISO/IEC/IEEE 15288,
— specifies the information items to be produced through the implementation of the integration
engineering (integration process and its relationships to other system life cycle processes),
— specifies the contents of the information items, and
— provides guidelines for the format of the information items.
This document can be applied to
— those who use or plan to use ISO/IEC/IEEE 15288 on projects dealing with man-made systems,
software-intensive systems, products and services related to those systems, regardless of project
scope, methodology, size or complexity, and
— anyone performing integration engineering activities to aid in ensuring that the application of the
integration process and its relationships to other system life cycle processes conform to ISO/IEC/
IEEE 15288.
NOTE 1 Systems concerned within this document are those as defined in ISO/IEC/IEEE 15288, i.e. systems
that are man-made and can be configured with one or more of the following: hardware, software, data, humans,
processes (e.g. processes for providing service to users), procedures (e.g. operator instructions), facilities,
materials and naturally occurring entities.
NOTE 2 This document is intended to be consistent with the other parts of ISO/IEC 24748.
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 15288:2015, Systems and software engineering — System life cycle processes
© ISO/IEC 2016 – All rights reserved 1

3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE 15288 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp/
3.1.1
acquirer
stakeholder that acquires or procures a product or service from a supplier (3.1.9)
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.1]
3.1.2
aggregate
composition of several implemented system elements (3.1.11) that are assembled (3.1.3), on which a set
of verification actions (3.1.17) and/or validation actions (3.1.15) is applied
3.1.3
assemble
activities for combining and connecting implemented system elements (3.1.11) or aggregates (3.1.2) to
support specific goals, i.e. integration (3.1.5), verification (3.1.16), validation (3.1.14), manufacturing
and production.
3.1.4
enabling system
system (3.1.10) that supports a system-of-interest (3.1.12) during its life cycle stages, but does not
necessarily contribute directly to its function during operation
EXAMPLE When a system-of-interest enters the production stage, a production enabling system is required.
Note 1 to entry: Each enabling system has a life cycle of its own. ISO/IEC/IEEE 15288 is applicable to each
enabling system when, in its own right, it is treated as a system-of-interest.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.18]
3.1.5
integration
activities of combining several implemented system elements (3.1.11) and activating the interfaces
(3.1.8) to form a realized system (product or service) that enables interoperation between the system
elements and with other systems (3.1.10) to satisfy system requirements, architecture characteristics
and design properties
Note 1 to entry: In this document, the term “integration” is limited to the integration of the implemented system
elements which compose a system and the necessary life cycle related activities. Integration may occur to
connect a system-of-interest (3.1.12) with external interoperating systems and/or enabling systems (3.1.4).
Note 2 to entry: The process of combining software components, hardware components or both into an overall
system (ISO/IEC/IEEE 24765).
2 © ISO/IEC 2016 – All rights reserved

3.1.6
integration engineering
set of activities that defines, analyzes and executes integration (3.1.5) across the life cycle, including
interactions with other life cycle processes
Note 1 to entry: The application of the system life cycle processes and knowledge of the system-of-interest (3.1.12)
are necessary in order to integrate a set of system elements (3.1.11) into a system (3.1.10).
3.1.7
integration management
set of activities that plans, assesses and controls the integration activities and all related activities
Note 1 to entry: It helps ensure that the process outcomes are achieved and that the integration related
information items are identified, documented, maintained, communicated and traced throughout the life cycle of
the concerned system (3.1.10).
3.1.8
interface
set of logical and/or physical characteristics required to exist at a common boundary or connection
between system elements (3.1.11)
Note 1 to entry: As examples of interface definition, refer to ISO/IEC/IEEE 24765.
3.1.9
supplier
organization or individual that enters into an agreement with the acquirer (3.1.1) for the supply of a
product or service
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.45]
3.1.10
system
combination of interacting elements organized to achieve one or more stated purposes
Note 1 to entry: A system may be considered as a product or as the services it provides.
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.46]
3.1.11
system element
member of a set of elements that constitute a system (3.1.10)
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.47]
3.1.12
system-of-interest
system (3.1.10) whose life cycle is under consideration in the context of this document
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.48]
3.1.13
user
individual or a group that benefits from a system (3.1.10) during its utilization
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.52, modified]
3.1.14
validation
confirmation, through the provision of objective evidence, that the requirements for a specific intended
use or application have been fulfilled
Note 1 to entry: A system (3.1.10) is able to accomplish its intended use, goals and objectives (i.e. meet stakeholder
requirements) in the intended operational environment. The right system was built.
© ISO/IEC 2016 – All rights reserved 3

[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.53]
3.1.15
validation action
action that describes what is to be validated (the element as reference), on which item the action is
performed, the expected result from the performance of the action, the validation technique to apply
and at which level of decomposition of the system-of-interest (3.1.12)
3.1.16
verification
confirmation, through the provision of objective evidence, that specified requirements have been
fulfilled
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.54]
3.1.17
verification action
action that describes what is to be verified (the element as reference), on which item the action is
performed, the expected result from the performance of the action, the verification technique to apply
and at which level of decomposition of the system-of-interest (3.1.12)
3.2 Abbreviatied terms
IES Integration Enabling System
NDI Non-Developmental Item
SEI Software Engineering Institute
SoI System-of-Interest
4 Conformance
4.1 Intended usage
This document provides requirements and guidance for the execution of ISO/IEC/IEEE 15288 processes
and activities that deal with integration engineering. This document also provides definition of the
content and recommendations for the format of the information items or documentation that result
from the implementation of the related processes.
4.2 Conformance to processes
This document provides requirements and recommendations for a number of integration engineering
processes and related activities suitable for usage during the life cycle of a system (made of products
and/or services).
The requirements and recommendations for processes in this document are contained in Clause 6.
4.3 Conformance to information item content
This document provides requirements and recommendations for a number of integration engineering
information items to be produced during the life cycle of a system (made of products and/or services).
4 © ISO/IEC 2016 – All rights reserved

The requirements and recommendations for information items in this document are contained in
Clause 7.
NOTE In this document, for simplicity of reference, each information item is described as if it were published
as a separate document. However, information items are considered as conforming if they are unpublished, but
available in a repository for reference, divided into separate documents or volumes or combined with other
information items into one document. It is not required to treat every topic in this document in the same order,
using the same wording as its title or with the same level of detail. This will depend on the nature of the system,
implementation methods, life cycle model and scope of the project; for example, test and Integration plan, a
system engineering management plan containing integration plan information.
4.4 Full conformance
A claim of full conformance to this document is equivalent to claiming conformance
— to the provisions contained in 6.2 and 6.3, and
— to the information items cited in Clause 7.
4.5 Tailored conformance
4.5.1 Processes
This document does not make provision for tailoring processes. ISO/IEC/IEEE 15288:2015, Annex A
provides normative direction regarding the tailoring of system life cycle process.
4.5.2 Information items
Information items described in this document are requirements and recommendations that can be
adapted depending on the type of system, implementation methods, life cycle model and scope of the
project.
5 Concepts and principles
5.1 General
This clause presents concepts and principles that apply to integration engineering and to the information
items generated at all levels of the system-of-interest during the execution of the concerned processes.
They also apply to the processes used in the integration itself and to management of the integration of
a system.
5.2 Integration fundamentals
5.2.1 Terms and approaches
5.2.1.1 Fundamental concept behind the term “integration”
As stated in 3.1.5, the term “integration” is defined as activities of combining several implemented
system elements and activating the interfaces to form a realized system (product or service) that
enables interoperation between the system elements and with other systems to satisfy system
requirements, architecture characteristics and design properties. The execution of these activities
provides something integrated that becomes a whole. Integration of the system involves its functions.
EXAMPLES
—  The engine is integrated with chassis and suspension to form the vehicle.
© ISO/IEC 2016 – All rights reserved 5

—  Integrated repository: a repository for storing all information pertinent to the System Engineering Plan
(SEP) to include all data, schema, models, tools, technical management decisions, process analysis information,
requirement changes, process and product metrics and trade-offs (IEEE 1220-2005, 3.1.18).
—  Integrated team: group of people with complementary skills and expertise who are committed to delivering
specified work products in timely collaboration (ISO/IEC/IEEE 24765).
—  Integrated circuit: a small piece of semiconductive material that contains interconnected electronic elements
(ISO/IEC 2382)
The opposite of the verb “to integrate” is “to segregate” which means to take apart (synonyms:
disassemble, separate).
To make the link with the term “system”, it is notable that a system deals with a whole, without using
explicitly the term whole in its ISO/IEC/IEEE 15288 definition (combination of interacting elements
organized to achieve one or more stated purposes; see 3.1.10).
5.2.1.2 Integration engineering approach
The concept of wholeness is key to integration engineering. Holistically, a system is more than the sum
of its parts. So too, integration is more than mere assembly.
Integration engineering encompasses all activities throughout the life cycle of a system-of-interest that
are linked to the integration of the implemented system elements to form the system-of-interest. This
includes the following:
— the definition, preparation and performance of the assembly of the implemented system elements
to form aggregates until obtaining the defined system-of-interest;
— the definition and performance of actions applied to aggregates in order to check the assembly
focusing in particular on interfaces;
— the definition and performance of verification and validation actions applied to aggregates in order
to check conformance of the assembly to the system requirements, architecture and design;
— the integration of the formed system into its context of use (environmental context); integration is
recursive and so applies to the integration of the system-of-interest into the next level of the system
structure.
It also includes the activities of other technical processes that influence and/or constrain, guide, serve
and enable these previous activities.
It also includes the integration of the system-of-interest with interoperating systems and enabling
systems. It is related to the engineering of enabling systems (set of enabling products and/or services)
that support the integration of the system-of-interest (see 5.3.2).
The management of all these activities is part of the overall project management of the system-of-
interest.
NOTE The system-of-interest can be composed of layers of system elements. A system element can be
considered as a system or as a non-decomposable element. The system-of-interest is the highest abstraction in
the decomposition into levels of systems.
While the system-of-interest is the highest level of abstraction in the decomposition of a particular
system structure, systems can be abstracted up with respect to their interactions as part of one or
more systems-of-systems. This perspective is necessary to aid the integration of the system-of-interest
with the interoperating systems and enabling systems of its environment.
A system element is a discrete part of a system that can be implemented to fulfil specified requirements
(for example, hardware, software, data, humans, processes, procedures, facilities, materials or any
combination thereof).
6 © ISO/IEC 2016 – All rights reserved

5.2.1.3 Integration versus mass production
System integration is a part of the effort related to the realization of prototypes or one-shot-systems. The
integration activity is different from the mounting of end products on a production or manufacturing line.
For mass/series production, an assembly line does not necessarily use the same assembly order of
implemented system elements as it is done for prototypes within the integration process. Integration of
prototypes composes systems, through aggregates (see 5.2.2.1), in order to verify and possibly validate
those aggregates and their interfaces, almost separately (see 5.2.4).
Mass/series production is not interested in systems, but rather in sets of components (implemented
system elements) to optimize the time and production effort. Nevertheless, the integration of a
prototype often provides pertinent lessons to engineer a production line that repeats the prototype, in
particular, about the order of assembly of the implemented system elements.
5.2.2 Notions of aggregate and of interface
5.2.2.1 Aggregate
The integration of a system is based on the notion of “aggregate”. An aggregate is an assembled set of two or
several implemented system elements and their interfaces as they are defined in the system architecture
and design. An aggregate has a functional consistency that allows the performance of verification actions
and possibly validation actions. Each aggregate is characterized by a configuration that specifies the
implemented system elements that are physically assembled and their configuration status.
NOTE An aggregate, in the context of integration, does not necessarily represent a system as defined in the
physical view of architecture or in the hierarchy decomposition of the system-of-interest. For the purpose of
efficient integration and validation of the system, different sets of aggregates may be temporarily considered
depending on the integration techniques or methods (see 5.2.6.1) that have been selected to define the
integration, verification and validation strategies (see 5.2.9). The validation strategy is of concern because the
validation of the implementation of certain requirements is not possible using the complete system due to, for
example, security, physical or economical constraints. This is addressed by forming temporary aggregates in
order to exercise the concerned requirements.
5.2.2.2 Interface
An “interface” is a concept, in the sense that any system element that binds two system elements may
be considered to be an interface from an architectural perspective. An interface generally includes two
aspects:
— a logical aspect, i.e. the input-output flow and the function that carries it;
— a physical aspect, i.e. the physical link, made of technology, that transports the input-output flow.
A logical interface consists of an input flow, an output flow or a bi-directional flow (transactional flow)
between two functions of the system so that they may exchange material, energy and/or information.
A physical interface is a physical link or port that binds two system elements within the system-of-
interest or one system element of the system-of-interest with an element external to the system-of-
interest. A physical interface may be considered a system element.
The definition of interfaces is an intrinsic part of the system architecture and design definition and is
critical to the success of integration. Interfaces are common failure points in complex systems. They
are the points where independent systems or system elements (not necessarily made of the same
technology) meet and communicate with each other. This is the reason why architecture and design
definition activities and decisions have to consider how the integration (assembly of system elements
and verification of the assembly) will be performed.
© ISO/IEC 2016 – All rights reserved 7

5.2.3 Integration based on architecture and design
5.2.3.1 Integration versus architecture
The term “system integration” is used to describe the activities related to assembling the implemented
system elements of a system to obtain the corresponding final product or service.
The integration of a system pre-supposes that architecture and design activities have been performed
upstream defining these system elements and their interfaces. They may pre-exist, be re-used or may
be specifically developed.
Based on stakeholder and system requirements, the definition of the architecture of the system deals
with the structure and composition of the system elements and of their interfaces. The design of
system elements deals with the detailed description of characteristics and enablers of the necessary
technologies for their implementation and interfacing.
Scalability, interoperability, availability, portability, etc. are stakeholder concerns that are addressed
during architecture definition to equip the architecture with related architectural characteristics such
as modularity, standardized interfaces, encapsulation, etc.
So, the integration activities first consist of defining the order of assembling the system elements to
the extent that the order is relevant and the verification actions based on architecture and design
characteristics; then, performing the assembly of the implemented system elements and executing
the verification and/or validation actions. However, note that particularly in software, it is common to
develop, expand or refactor software units without defining their order of integration into the software
product. The order of assembling the system elements may be flexible. Even for hardware items,
different subassemblies (aggregates) can be integrated in various sequences, though there may be a
critical path for supply and production of system elements. This critical path consideration for supply
and production often identifies integration constraints that influence requirements, architecture or
design, including interfaces. These identified constraints are incorporated in the system requirements,
architecture or design.
Nevertheless, as indicated in 5.2.2.2, architecture and design definition activities and decisions have
to consider how the integration (assembly of system elements and verification of the assembly) will be
performed.
In any case, the integration of implemented system elements is based on the architecture and design
definition, whatever the life cycle scenario.
5.2.3.2 Integration scenarios
Sometimes, the term “integration” is interpreted based on a restrictive definition consisting of
integrating existing elements. This may be the case, for example, when dealing with industrial practices
that consist of using existing products or NDI (non developmental items; that have not necessarily been
initially defined to run with others) to be incorporated into a given system at a particular life cycle stage.
Three example cases are given below that demonstrate the importance of the system architecture
definition, beyond considerations of physical integration.
— Planned integration. This is the classic approach used in the development stage of a system in
which the system elements are defined up front to be physically integrated. Those system elements
have been defined, or identified as NDI during architecture definition, to perform functions that
are allocated to them to satisfy system requirements. These system elements may be developed
specifically for the system-of-interest. They may be existing and re-used as is or they may be
modified. They may also be NDI evolved by external parties. The selection of the system elements
is an architectural and development management decision. Planned integration may be achieved at
design and build-time and may also be achieved through self-configuration during operation.
— Evolutionary integration (evolution/extension/adaptation). This is the approach used when
an existing in-service system (i.e. in its utilisation stage) needs to interoperate with another
8 © ISO/IEC 2016 – All rights reserved

one, existing or not. The integration cannot occur without performing upstream definition
tasks because this case may be considered as a request that includes specific requirements. In
particular, some architecture and evaluation studies are performed including interoperability
analysis (compatibility of protocols, interfacing capability), integratability analysis (feasibility of
the functional exchanges and of the physical connection) and verification and validation feasibility.
These analyses are necessary inputs to the architecture definition/modification in order to either
do nothing, modify the interfacing system elements or add new system elements. Nevertheless, to
perform these analyses, it is assumed that the engineering information items (documentation) of
the concerned systems or system elements exist. Otherwise, a reverse engineering step has to be
performed to characterize the interfacing systems or system elements.
— Capability extension integrating existing system elements or NDI. This case often corresponds
to a decision to develop a new capability of an in-service system (i.e. in its utilisation stage)
incorporating an existing system element or an NDI. This case is generally highly constrained by a
fast, low effort and low cost implementation with a limited set of available options. As well, these
system elements can be significantly complex. This case can be considered as an extension request
that includes specific requirements. Architecture and evaluation studies need to be performed
upstream taking into account these requirements. This would include, in particular, interfacing
feasibility, interoperability analysis, integratability analysis (feasibility of the functional exchanges
and of the physical connection) and verification and validation feasibility. An architecture based
on a kind of “plug-in” technology principle, a strong modularity property or a service-oriented
architecture may be able to partially or totally address this situation. With such architectural
characteristics, the integration is facilitated, although this may not be immediately apparent.
NOTE 1 Adoption of NDI is driven by the time-to-market constraints and the higher level of technology
readiness of the NDI products. The use of NDI constrains the architecture of a system. Architecture decisions
about NDI have a significant impact on integration. Deciding early on in the system development to use NDI vs. a
“built-in house” solution aids identification of the appropriate interface and performance of adequate verification
and validation actions.
NOTE 2 A system-of-interest is not necessarily static in its environment. The environment, or context of use,
can change over time, so the system-of-interest has to adapt to new operating conditions by adding or modifying
capabilities. Any type of system is considered in this document, including evolving systems having dynamic self-
[16] [7]
configuration capability (refer to ISO 15704 , ISO/IEC/IEEE 15288 and ISO/IEC/TS 24748-1 ) explain that a
system may evolve over time and that every life cycle process can be applied at any time during the system life
cycle. This is the case, in particular, with the integration process and related processes.
5.2.4 Integration by layers of systems
The definition of a system (left side of Figure 1) is performed on successive layers of abstraction; each
layer corresponds to a physical architecture of systems and non-decomposable system elements. The
integration (right side of Figure 1) consists in following the opposite way of composition layer by layer.
On a given layer, integration of implemented system elements is generally done on the basis of the
physical architecture as defined during the system definition. The logical architecture is also used as
the basis on which to select the system elements to be integrated that together perform a function of
the system.
The goal is to progressively validate the system-of-interest per specified system layer, by forming
aggregates (see 5.2.2.1), such that certain critical system elements or specific characteristics requiring
to be integrated are verified and validated early. In that case, the integration method called “criterion
driven integration” or any other integration method may be used (see 5.2.6.1). Mixing these two ways
(per layer using integration methods) makes the global integration and validation of a system-of
interest efficient, not to say optimized.
© ISO/IEC 2016 – All rights reserved 9

Figure 1 — Integration by layer of systems
NOTE Many integrated systems are systems-of-systems, and the integration starts with combination of
existing validated (possibly NDI) systems. In this case, the system-of-systems is the system-of-interest, and each
existing system is a system element within the system-of-interest.
5.2.5 Environmental context
Integration engineering also includes the integration of the system-of-interest in its environmental
context which may include physical, organizational, social and legal environmental conditions. When
the system-of-interest has been formed and functionally verified, it has to be integrated with the
operational environment and transitioned into use.
The context of use (operational environment) can be seen as an upper level system in which the system-
of-interest is nothing more than a system element. This incorporation follows the same approach as an
integration step that consists of connecting the implemented system elements of the system-of-interest
to the elements of the context and checking that the system-of-interest can operate under specified
conditions.
The physical, organizational, social and legal environmental conditions, in which the system-
...