ISO/IEC TS 24748-1:2016

TECHNICAL ISO/IEC TS
SPECIFICATION 24748-1
First edition
2016-05-01
Systems and software engineering —
Life cycle management —
Part 1:
Guidelines for life cycle management
Ingénierie des systèmes et du logiciel — Gestion du cycle de vie —
Partie 1: Lignes directrices pour la gestion du cycle de vie
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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Terms and definitions . 1
3 Life cycle-related concepts .10
3.1 System concepts .10
3.1.1 General.10
3.1.2 Systems .10
3.1.3 System structure .12
3.1.4 Structure in systems and projects.13
3.1.5 Enabling systems .14
3.2 Life cycle concepts .15
3.2.1 System life cycle model.15
3.2.2 System life cycle stages . .16
3.2.3 Stages in a system-of-interest and its enabling systems .17
3.3 Process concepts .18
3.3.1 Life cycle processes .18
3.3.2 Process responsibility .21
3.4 Process application .22
3.5 Processes under key views .24
4 Life cycle stages .26
4.1 General .26
4.2 Concept Stage .27
4.2.1 Overview .27
4.2.2 Purpose .28
4.2.3 Outcomes .28
4.3 Development Stage .28
4.3.1 Overview .28
4.3.2 Purpose .29
4.3.3 Outcomes .29
4.4 Production Stage .30
4.4.1 Overview .30
4.4.2 Purpose .30
4.4.3 Outcomes .30
4.5 Utilization Stage .31
4.5.1 Overview .31
4.5.2 Purpose .31
4.5.3 Outcomes .31
4.6 Support Stage .31
4.6.1 Overview .31
4.6.2 Purpose .32
4.6.3 Outcomes .32
4.7 Retirement Stage .32
4.7.1 Overview .32
4.7.2 Purpose .33
4.7.3 Outcomes .33
5 Life cycle adaptation .33
5.1 General .33
5.2 Adaptation sequence .34
5.2.1 General.34
5.2.2 Identify the project environment and characteristics .35
5.2.3 Solicit inputs .35
© ISO/IEC 2016 – All rights reserved iii

5.2.4 Select the appropriate standards .35
5.2.5 Select life cycle model .36
5.2.6 Select stages and processes .36
5.2.7 Document the adaptation decisions and rationale .36
5.3 Adaptation guidance .37
5.4 Scope adaptation .38
5.5 Stage adaptation .39
5.6 Process adaptation .39
5.7 Life cycle model adaptation for domains, disciplines and specialties .39
5.7.1 Adaptation for domains .39
5.7.2 Adaptation for disciplines .41
5.7.3 Adaptation for specialties .41
5.8 Adapting evaluation-related activities .43
6 Relationship with detailed process standards .44
Annex A (informative) Process views .46
Annex B (informative) Guidance on development strategies and build planning .56
Annex C (informative) Candidate joint management reviews .59
Annex D (informative) Problem reporting capability .62
Bibliography .64
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, SC 7, Software
and systems engineering.
This first edition of ISO/IEC/TS 24748-1 cancels and replaces ISO/IEC/TR 24748-1, which has been
technically revised.
ISO/IEC 24748 consists of the following parts, under the general title Systems and software engineering —
Life cycle management:
— Part 1: Guidelines for life cycle management [Technical Specification]
— Part 2: Guide to the application of ISO/IEC 15288 (System life cycle processes)
— Part 3: Guide to the application of ISO/IEC 12207 (Software life cycle processes)
— Part 4: Systems engineering planning [ISO/IEC/IEEE]
— Part 5: Software development planning [ISO/IEC/IEEE]
The following parts are under preparation:
— Part 6: Guide to system integration engineering
© ISO/IEC 2016 – All rights reserved v

Introduction
The purpose of this Technical Specification is to facilitate the joint usage of the process content of the
latest revisions of ISO/IEC/IEEE 15288 and ISO/IEC 12207, by providing unified and consolidated
guidance on life cycle management of systems and software. This is to help ensure consistency in system
concepts and life cycle concepts, models, stages, processes, process application, key points of view,
adaptation and use in various domains as the two International Standards are used in combination.
That will in turn help a project team design a life cycle model for managing the progress of their project.
This Technical Specification will also aid in identifying and planning use of life cycle processes described
in ISO/IEC/IEEE 15288 and ISO/IEC 12207 that will enable the project to be completed successfully,
meeting its objectives/requirements for each stage and for the overall project.
Besides the above, there is also increasing recognition of the importance of ensuring that all life cycle
stages and all aspects within each stage are supported with thorough guidance to enable alignment
with any process documents that might subsequently be created that focus on areas besides systems
and software, including hardware, humans, data, processes (e.g. review process), procedures (e.g.
operator instructions), facilities and naturally occurring entities (e.g. water, organisms, minerals).
By addressing these needs specifically in this Technical Specification, the users of the process-
focused ISO/IEC 12207 and ISO/IEC/IEEE 15288 will not only benefit from having one document
complementarily addressing the aspect of product or service life cycle: they will also benefit from a
framework that links life cycle management aspects to more than just the systems or software aspects
of products or services.
ISO/IEC/IEEE 15288 and ISO/IEC 12207 also have published guidelines (ISO/IEC/TR 24748-2 and
ISO/IEC/TR 24748-3), respectively, to support use of the two revised International Standards
individually.
vi © ISO/IEC 2016 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 24748-1:2016(E)
Systems and software engineering — Life cycle
management —
Part 1:
Guidelines for life cycle management
1 Scope
This Technical Specification provides guidelines for the life cycle management of systems and software,
complementing the processes described in ISO/IEC/IEEE 15288 and ISO/IEC 12207. This Technical
Specification:
— addresses systems concepts and life cycle concepts, models, stages, processes, process application,
key points of view, adaptation and use in various domains and by various disciplines;
— establishes a common framework for describing life cycles, including their individual stages, for the
management of projects to provide, or acquire either products or services;
— defines the concept and terminology of a life cycle;
— supports the use of the life cycle processes within an organization or a project. Organizations and
projects can use these life cycle concepts when acquiring and supplying either products or services;
— provides guidance on adapting a life cycle model and the content associated with a life cycle or a
part of a life cycle;
— describes the relationship between life cycles and their use in applying the processes in ISO/IEC/
IEEE 15288 (systems aspects) and ISO/IEC 12207 (software aspects);
— shows the relationships of life cycle concepts to the hardware, human, services, process, procedure,
facility and naturally occurring entity aspects of projects; and
— describes how its concepts relate to detailed process standards, for example, in the areas of
measurement, project management and risk management.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
acquirer
stakeholder that acquires or procures a product or service from a supplier
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer, owner, purchaser, or
internal/organizational sponsor.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.2
acquisition
process of obtaining a system, product or service
[SOURCE: ISO/IEC/IEEE 15288:2015]
© ISO/IEC 2016 – All rights reserved 1

2.3
activity
set of cohesive tasks of a process
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.4
agile development
software development approach based on iterative development, frequent inspection and adaptation,
and incremental deliveries, in which requirements and solutions evolve through collaboration in cross-
functional teams and through continual stakeholder feedback
[SOURCE: ISO/IEC/IEEE 26515:2011]
2.5
agreement
mutual acknowledgement of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.6
architecture
fundamental concepts or properties of a system in its environment embodied in its elements,
relationships, and in the principles of its design and evolution
Note 1 to entry: ISO/IEC 12207 and ISO/IEC/IEEE 15288 use the word “elements” instead of “components” and
this Technical Specification follows that usage.
[SOURCE: ISO/IEC/IEEE 42010:2011]
2.7
architecture framework
conventions, principles and practices for the description of architectures established within a specific
domain of application and/or community of stakeholders
EXAMPLE 1 Generalized Enterprise Reference Architecture and Methodologies (GERAM) (ISO 15704) is an
architecture framework.
EXAMPLE 2 Reference Model of Open Distributed Processing (RM-ODP) (ISO/IEC 10746) is an architecture
framework.
[SOURCE: ISO/IEC/IEEE 42010:2011]
2.8
architecture view
work product expressing the architecture of a system from the perspective of specific system concerns
[SOURCE: ISO/IEC/IEEE 42010:2011]
2.9
architecture viewpoint
work product establishing the conventions for the construction, interpretation and use of architecture
views to frame specific system concerns
[SOURCE: ISO/IEC/IEEE 42010:2011]
2 © ISO/IEC 2016 – All rights reserved

2.10
audit
independent examination of a work product or set of work products to assess compliance with
specifications, standards, contractual agreements, or other criteria
[SOURCE: ISO/IEC/IEEE 24765:2010]
2.11
baseline
approved version of a configuration item, regardless of media, formally designated and fixed at a
specific time during the configuration item’s life cycle
[SOURCE: IEEE 828:2012]
2.12
concept of operations
verbal and/or graphic statement, in broad outline, of an organization’s assumptions or intent in regard
to an operation or series of operations
Note 1 to entry: The concept of operations frequently is embodied in long-range strategic plans and annual
operational plans. In the latter case, the concept of operations in the plan covers a series of connected operations
to be carried out simultaneously or in succession. The concept is designed to give an overall picture of the
organization operations. See also operational concept (2.25).
Note 2 to entry: It provides the basis for bounding the operating space, system capabilities, interfaces and
operating environment.
[SOURCE: ANSI/AIAA G-043A-2012e]
2.13
concern
interest in a system relevant to one or more of its stakeholders
Note 1 to entry: A concern pertains to any influence on a system in its environment, including developmental,
technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social
influences.
[SOURCE: ISO/IEC/IEEE 42010:2011]
2.14
configuration item
item or aggregation of hardware, software, or both, that is designated for configuration management
and treated as a single entity in the configuration management process
[SOURCE: ISO/IEC/IEEE 24765:2010, modified — added “item or”.]
2.15
customer
organization or person that receives a product or service
EXAMPLE Consumer, client, user, acquirer, buyer, or purchaser.
Note 1 to entry: A customer can be internal or external to the organization.
[SOURCE: ISO 9000:2015, modified — added “service”.]
2.16
design
to define the architecture, system elements, interfaces, and other characteristics of a system
or system element
[SOURCE: ISO/IEC/IEEE 24765:2010, modified – changed “components” to “system elements”.]
© ISO/IEC 2016 – All rights reserved 3

2.17
design
result of the process in 2.15
Note 1 to entry: Information, including specification of system elements and their relationships, that is sufficiently
complete to support a compliant implementation of the architecture.
Note 2 to entry: Design provides the detailed implementation-level physical structure, behavior, temporal
relationships and other attributes of system elements.
[SOURCE: ISO/IEC/IEEE 24765:2010]
2.18
design characteristic
design attributes or distinguishing features that pertain to a measurable description of a product
or service
[SOURCE: ISO/IEC/IEEE 24765:2010]
2.19
enabling system
system that supports a system-of-interest 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. This Technical Specification 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]
2.20
environment
context determining the setting and circumstances of all influences upon a system
[SOURCE: ISO/IEC/IEEE 42010:2011]
2.21
facility
physical means or equipment for facilitating the performance of an action, e.g. buildings,
instruments, tools
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.22
incident
anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of
a project, product, service, or system
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.23
information item
separately identifiable body of information that is produced, stored, and delivered for human use
[SOURCE: ISO/IEC/IEEE 15289:2015]
2.24
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 © ISO/IEC 2016 – All rights reserved

2.25
life cycle model
framework of processes and activities concerned with the life cycle that may be organized into stages,
which also acts as a common reference for communication and understanding
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.26
operational concept
verbal and graphic statement of an organization’s assumptions or intent in regard to an operation or
series of operations of a system or a related set of systems
Note 1 to entry: The operational concept is designed to give an overall picture of the operations using one or
more specific systems, or set of related systems, in the organization’s operational environment from the users’
and operators’ perspective. See also concept of operations (2.11).
[SOURCE: ANSI/AIAA G-043A-2012e]
2.27
operator
individual or organization that performs the operations of a system
Note 1 to entry: The role of operator and the role of user may be vested, simultaneously, or sequentially, in the
same individual or organization.
Note 2 to entry: An individual operator combined with knowledge, skills and procedures may be considered as
an element of the system.
Note 3 to entry: An operator may perform operations on a system that is operated, or of a system that is operated,
depending on whether or not operating instructions are placed within the system boundary.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.28
organization
group of people and facilities with an arrangement of responsibilities, authorities and relationships
EXAMPLE Company, corporation, firm, enterprise, institution, charity, sole trader, association, or parts or
combination thereof.
Note 1 to entry: An identified part of an organization (even as small as a single individual) or an identified group
of organizations can be regarded as an organization if it has responsibilities, authorities and relationships. A body
of persons organized for some specific purpose, such as a club, union, corporation, or society, is an organization.
[SOURCE: ISO 9000:2015, modified — Note 1 to entry has been added.]
2.29
party
organization entering into an agreement
Note 1 to entry: In this Technical Specification, the agreeing parties are called the acquirer and the supplier.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.30
problem
difficulty, uncertainty, or otherwise realized and undesirable event, set of events, condition, or situation
that requires investigation and corrective action
[SOURCE: ISO/IEC/IEEE 15288:2015]
© ISO/IEC 2016 – All rights reserved 5

2.31
process
set of interrelated or interacting activities that transforms inputs into outputs
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.32
process outcome
observable result of the successful achievement of the process purpose
[SOURCE: ISO/IEC 12207:2008]
2.33
process purpose
high level objective of performing the process and the likely outcomes of effective implementation of
the process
Note 1 to entry: The purpose of implementing the process is to provide benefits to the stakeholders.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.34
product
result of a process
Note 1 to entry: There are four agreed generic product categories: hardware (e.g. engine mechanical part),
software (e.g. computer program), services (e.g. transport), and processed materials (e.g. lubricant). Hardware
and processed materials are generally tangible products, while software or services are generally intangible.
[SOURCE: ISO 9000:2015]
2.35
project
endeavour with defined start and finish criteria undertaken to create a product or service in accordance
with specified resources and requirements
Note 1 to entry: A project is sometimes viewed as a unique process comprising co-coordinated and controlled
activities and composed of activities from the Project Processes and Technical Processes defined in the
referenced International Standards.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.36
qualification
process of demonstrating whether an entity is capable of fulfilling specified requirements
[SOURCE: ISO/IEC 12207:2008]
2.37
quality assurance
part of quality management focused on providing confidence that quality requirements will be fulfilled
[SOURCE: ISO 9000:2015]
2.38
quality characteristic
inherent characteristic of a product, process, or system related to a requirement
Note 1 to entry: Critical quality characteristics commonly include those related to health, safety, security,
assurance, reliability, availability and supportability.
[SOURCE: ISO 9000:2015, modified — Note 1 to entry added.]
6 © ISO/IEC 2016 – All rights reserved

2.39
quality management
coordinated activities to direct and control an organization with regard to quality
[SOURCE: ISO 9000:2015]
2.41
requirement
statement that translates or expresses a need and its associated constraints and conditions
[SOURCE: ISO/IEC/IEEE 29148:2011]
2.42
resource
asset that is utilized or consumed during the execution of a process
Note 1 to entry: Includes diverse entities, such as funding, personnel, facilities, capital equipment, tools and
utilities, such as power, water, fuel and communication infrastructures.
Note 2 to entry: Resources include those that are reusable, renewable, or consumable.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.43
retirement
withdrawal of active support by the operation and maintenance organization, partial or total
replacement by a new system, or installation of an upgraded system
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.44
risk
effect of uncertainty on objectives
Note 1 to entry: An effect is a deviation from the expected, positive or negative. A positive effect is also known as
an opportunity.
Note 2 to entry: Objectives can have different aspects (such as financial, health and safety, and environmental
goals) and can apply at different levels (such as strategic, organization-wide, project, product and process).
Note 3 to entry: Risk is often characterized by reference to potential events and consequences, or a combination
of these.
Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including
changes in circumstances) and the associated likelihood of occurrence.
Note 5 to entry: Uncertainty is the state, even partial, of deficiency of information related to understanding or
knowledge of an event, its consequence, or likelihood.
[SOURCE: ISO Guide 73:2009, 1.1]
2.45
security
protection against intentional subversion or forced failure, containing a composite of four attributes:
confidentiality, integrity, availability and accountability, plus aspects of a fifth, usability, all of which
have the related issue of their assurance
[SOURCE: NATO AEP-67]
© ISO/IEC 2016 – All rights reserved 7

2.46
service
performance of activities, work, or duties
Note 1 to entry: A service is self-contained, coherent, discrete and can be composed of other services.
Note 2 to entry: A service is generally an intangible product.
[SOURCE: ISO/IEC 12207:2008]
2.47
software item
source code, object code, control code, control data, or a collection of these items
Note 1 to entry: A software item can be viewed as a system element of the referenced International Standard and
of ISO/IEC/IEEE 15288:2015.
[SOURCE: ISO/IEC 12207:2008]
2.48
software product
set of computer programs, procedures, and possibly associated documentation and data
[SOURCE: ISO/IEC 12207:2008]
2.49
software unit
atomic level software component of the software architecture that can be subjected to stand-alone testing
[SOURCE: ISO 26262-1:2011]
2.50
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 Technical Specification, 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]
2.51
stakeholder
individual or organization having a right, share, claim, or interest in a system or in its possession of
characteristics that meet their needs and expectations
EXAMPLE End users, end user organizations, supporters, developers, producers, trainers, maintainers,
disposers, acquirers, supplier organizations and regulatory bodies.
Note 1 to entry: Some stakeholders can have interests that oppose each other or oppose the system.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.52
supplier
organization or an individual that enters into an agreement with the acquirer for the supply of a product
or service
Note 1 to entry: Other terms commonly used for supplier are contractor, producer, seller, or vendor.
Note 2 to entry: The acquirer and the supplier sometimes are part of the same organization.
[SOURCE: ISO/IEC/IEEE 15288:2015]
8 © ISO/IEC 2016 – All rights reserved

2.53
system
combination of interacting elements organized to achieve one or more stated purposes
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:2015]
2.54
system element
member of a set of elements that constitutes a system
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.
Note 1 to entry: A system element is a discrete part of a system that can be implemented to fulfill specified
requirements.
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.55
system-of-interest
system whose life cycle is under consideration in the context of this document
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.56
systems engineering
interdisciplinary approach governing the total technical and managerial effort required to transform
a set of stakeholder needs, expectations, and constraints into a solution and to support that solution
throughout its life
[SOURCE: ISO/IEC/IEEE 24765:2010]
2.57
task
required, recommended, or permissible action, intended to contribute to the achievement of one or
more outcomes of a process
[SOURCE: ISO/IEC/IEEE 15288:2015]
2.58
technical management
application of technical and administrative resources to plan, organize and control engineering
functions
[SOURCE: ISO/IEC 12207:2008]
2.59
trade-off
decision-making actions that select from various requirements and alternative solutions on the basis of
net benefit to the stakeholders
[SOURCE: ISO/IEC/IEEE 15288:2015]
© ISO/IEC 2016 – All rights reserved 9

2.60
user
individual or group that interacts with a system or benefits from a system during its utilization
Note 1 to entry: The role of user and the role of operator are sometimes vested, simultaneously or sequentially, in
the same individual or organization.
[SOURCE: ISO/IEC 25010:2011]
2.61
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 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.
Note 2 to entry: In a life cycle context, validation involves the set of activities for ensuring and gaining confidence
that a system is able to accomplish its intended use, goals and objectives in an environment like the operational
environment.
[SOURCE: ISO 9000:2015, modified — Note 1 to entry and Note 2 to entry have been added.]
2.62
verification
confirmation, through the provision of objective evidence, that specified requirements have been
fulfilled
Note 1 to entry: Verification is a set of activities that compares a system or system element against the required
characteristics. This includes, but is not limited to, specified requirements, design description and the system
itself. The system was built right.
[SOURCE: ISO 9000:2015 modified — Note 1 to entry has been added.]
3 Life cycle-related concepts
3.1 System concepts
3.1.1 General
This subclause is included to highlight and explain essential concepts on which this Technical
Specification is based. These concepts are directly applicable to software, as addressed in ISO/IEC 12207,
systems, as addressed in ISO/IEC/IEEE 15288, and to hardware, facilities, services, humans, processes
and procedures, data and naturally occurring entities.
3.1.2 Systems
The systems considered in this Technical Specification are man-made and utilized to provide services
in defined environments for the benefit of users and other stakeholders. These systems may be
configured with one or more of the following: hardware, software, services, humans, data, processes
(e.g. processes for providing services to users), procedures (e.g. operator instructions), facilities and
naturally occurring entities (e.g. water, organisms, minerals).
The perception and definition of a particular system, its architecture and its system elements depend
on an observer’s interests and responsibilities. One person’s system-of-interest can be viewed as a
system element in another person’s system-of-interest. Conversely, it can be viewed as being part of the
environment of operation for yet another person’s system-of-interest.
Figure 1 exemplifies the multitude of perceivable systems-of-interest in an aircraft and its environment
of operation. First, Figure 1 in its entirety comprises a transportation system with air, ground and
10 © ISO/IEC 2016 – All rights reserved

water elements, which can be a system-of-interest. Next, any one element of the transportation system
can be viewed as a system-of-interest, such as the Air Transport System. The example can be continued
through the levels so that, for example, the display can be an element of the navigation system, which
is in turn an element of the aircraft system within the air transport system. However, from an equally
valid perspective, such as that of display manufacturers, the display will be their system-of-interest
and they will then determine the elements within their display system. On a deeper level, Figure 1 also
illustrates the following:
— the importance of defined boundaries that encapsulate meaningful needs and practical solutions;
— the perception of system structure (in this case, the physical structure, hierarchical in this instance);
— that an entity at any level in a system structure can be viewed as a system;
— that a system is comprised of a fully integrated, defined set of subordinate systems;
— that characteristic properties at a system’s boundary arise from the interactions between
subordinate systems;
— that humans can be viewed as users external to a system (e.g. air crew and navigation system) and
as system elements within a system (e.g. air crew and aircraft);
— that a system can be viewed as an isolated entity (that is, a product), or as an ordered collection of
functions capable of interacting with its surrounding environment, (i.e. a set of services);
— that a system can be viewed as part of a larger system of systems and that a system of systems can
be viewed as a system.
Ground
Transportation
AirTransportSystem
System
Ticketing
Airtrafic
system
controlsystem
Fuel
Airport
distribution
system
system
AircraftSystem
Life
Airframe
support
system
system
AirCrew
Propulsion
system
Display
Navigation
system
system
Flight
control
system
Globalpositioning
Maritime
receiversystem
Transport
System
Figure 1 — Typical system view of an aircraft in its environment of use
Whatever the boundaries chosen to define the system, the concepts and models in this Technical
Specification are generic and permit a practitioner to correlate or adapt individual
...