ISO/IEC/IEEE FDIS 12207

ISO/IEC JTC 1/SC 7/WG 7 N9907
Secretariat: BIS
Date: 2025-07-28
Systems and software engineering — Software life cycle processes
Ingénierie des systèmes et du logiciel — Processus du cycle de vie du logiciel
FDIS stage
ISO/IEC/IEEE CDFDIS 12207:20242025(en)
© ISO/IEC 2025
© /IEEE 2025
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 8CP 401  3 Park Avenue8
CH1214CH-1214 Vernier, Geneva, Switzerland New York, NY 100165997, USA
Tel. +Phone: + 41 22 749 01 11
Fax +41 22 749 09 47
E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO #### /IEC/IEEE 2025 – All rights reserved
ii
Contents
Foreword . iv
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Abbreviated terms . 14
4 Conformance . 15
4.1 General. 15
4.2 Full conformance . 16
4.3 Tailored conformance . 16
5 Key concepts and application . 16
5.1 General. 16
5.2 Software system concepts . 17
5.3 Organization and project concepts . 24
5.4 Life cycle concepts . 26
5.5 Process concepts . 28
5.6 Process groups . 30
5.7 Process application . 35
5.8 Process reference model . 37
6 Software life cycle processes . 40
6.1 Agreement processes . 40
6.2 Organizational project-enabling processes . 46
6.3 Technical management processes . 59
6.4 Technical processes . 83
Annex A (normative) Tailoring process . 147
Annex B (informative) Examples of process information items . 150
Annex C (informative) Process reference model for assessment purposes . 157
Annex D (informative) Model-based systems and software engineering (MBSSE) . 159
Annex E (informative) Assurance and assurance cases . 167
Bibliography . 168
IEEE notices and abstract . 174

© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
iii
ISO/IEC/IEEE CDFDIS 12207:20242025(en)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA and participate without compensation from IEEE. While IEEE administers the process and establishes
rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test,
or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/JTC 1, Information technology, Subcommittee
SC 7, Software and systems engineering, in cooperation with the Systems and Software Engineering Standards
Committee of the IEEE Computer Society, under the Partner Standards Development Organization
cooperation agreement between ISO and IEEE.
This second edition cancels and replaces the first edition (ISO/IEC/IEEE 12207:2017), which has been
technically revised.
The main changes are as follows:
— — clarifications and updates to reflect current practices in selected technical processes, including
business or mission analysis, system architecture definition, implementation, integration, operations, and
maintenance;
— — improvements to selected technical management processes, including risk management and
configuration management;
© ISO #### /IEC/IEEE 2025 – All rights reserved
iv
— — updates to Clause 5Clause 5,, key concepts, including a more precise description of iteration, recursion,
system-of-systems, and quality characteristics;
— — new content in Clause 5Clause 5 on concept and system definition, and expanded content on agile
methods, process application, and system concepts.
— revised Annex DAnnex D on model-based systems and software engineering (MBSSE)
This document is related to ISO/IEC/IEEE 15288, which covers system engineering processes. The choice of
whether to apply this document for the software life cycle processes, or ISO/IEC/IEEE 15288:2023, depends
on the system-of-interest (SoI). Processes in both documents have the same process purpose and process
outcomes, but differ in activities and tasks to perform software engineering or systems engineering,
respectively.
The requirements in this document are intended to be compatible with the requirements of the quality
management system provided by ISO 9001, the service management system provided by ISO/IEC 20000-1,
the IT asset management system provided by ISO/IEC 19770-1, and the information security management
system provided by ISO/IEC 27001.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
v
ISO/IEC/IEEE CDFDIS 12207:20242025(en)
Introduction
The complexity of software systems continues to increase to unprecedented levels. Technology change has led
to new opportunities, but also to increased challenges for the organizations that create and utilise systems.
There is a continuum of human-made systems from those that use little or no software to those in which
software is the primary interest. It is rare to encounter a complex system without software, and all software
systems require physical system elements (hardware) to operate, either as part of the software system-of-
interest (SoI) or as an enabling system or infrastructure. These challenges exist throughout the life cycle of a
system and at all levels of architectural detail.
The purpose of this document is to provide a defined set of software life cycle processes. This document
provides a common process framework for engineering the life cycle of systems created by humans, adopting
a software engineering approach. Software engineering is an interdisciplinary approach and means to enable
software. This document concerns software systems that are configured with software elements and with one
or more of the following: hardware elements, data, humans, processes, services, procedures, and facilities.
This document provides processes for use by acquirers, suppliers, and other stakeholders in the life cycle of a
software system, such as developers, integrators, operators, maintainers, managers, quality managers, and
users of software services and products. It covers defining stakeholder needs, concerns, priorities, and
constraints for the required functionality and non-functional characteristics early in the life cycle, establishing
requirements, and concurrent design synthesis and system validation while considering the complete
problem. It integrates disciplines and specialties into a team effort, forming a structured set of process that
proceeds from concept through production operation and maintenance and sustainment to disposal. It
considers both the business and the technical needs of stakeholders with the goal of providing a quality
product that meets the needs of users and other applicable stakeholders. It provides the processes for
acquiring and supplying systems. It helps to improve communication and cooperation among the parties that
create, utilise, and manage modern software systems so they can work in an integrated, coherent fashion.
Finally, this document provides the framework for assessment and improvement of the life cycle processes.
There is a wide variety of software systems in terms of their purpose, domain, complexity, size, novelty,
adaptability, quantity, location, life span, and evolution. The processes in this document form a comprehensive
set from which an organization can construct software life cycle models appropriate to its products and
services. An organization can select and apply an appropriate subset of these processes to fulfil its specific
objectives.
This document can be used in one or more of the following situations:
— — By an organization — to help establish an environment of desired processes. These processes can be
supported by an infrastructure of methods, procedures, techniques, tools, and trained personnel. The
organization can then employ this environment to perform and manage its projects and progress systems
through their life cycle stages. In this mode, this document can be used to assess conformance of a declared,
established environment to its provisions. It can be used by a single organization in a self-imposed mode
or in a multi-party situation. Parties can be from the same organization or from different organizations,
and the situation can range from an informal agreement to a formal contract.
— — By a project: to help select, structure, and employ the elements of an established environment to
provide products and services. In this mode this document is used in the assessment of conformance of
the project to the declared and established environment.
— — By an acquirer and a supplier: to help develop an agreement concerning processes and activities. Via
the agreement, the processes and activities in this document are selected, negotiated, agreed to, and
performed. In this mode this document is used for guidance in developing the agreement.
© ISO #### /IEC/IEEE 2025 – All rights reserved
vi
— — By process assessors: to serve as a process reference model for use in the performance of process
assessments that can be used to support organizational process improvement.
This document is related to ISO/IEC/IEEE 15288, which covers system engineering processes. The choice of
whether to apply this document for the software life cycle processes, or ISO/IEC/IEEE 15288:2023, depends
on the system-of-interest (SoI). Processes in both documents have the same process purpose and process
outcomes, but differ in activities and tasks to perform software engineering or systems engineering,
respectively.
The requirements in this document are intended to be compatible with the requirements of the quality
management system provided by ISO 9001, the service management system provided by ISO/IEC 20000-1,
the IT asset management system provided by ISO/IEC 19770-1, and the information security management
system provided by ISO/IEC 27001.
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
vii
FINAL DRAFT International Standard ISO/IEC/IEEE FDIS 12207:2025(en)

Systems and software engineering — Software life cycle processes
1 Scope
1.1 Overview
This document establishes a common framework for software life cycle processes. Its terminology can be
referenced and applied across the software industry. It contains processes, activities and tasks that can be
applied during the acquisition of a software system, product, or service and during the supply, development,
operation, maintenance, and disposal of software products and services. This is accomplished through the
involvement of stakeholders, with the goal of achieving customer satisfaction. This document includes those
aspects of system definition needed to provide the context for software systems and services. This document
also provides processes that can be employed for defining, controlling, and improving software life cycle
processes within an organization or a project.
1.2 Applicability
This document is applicable to one-of-a-kind software systems, software systems for wide commercial or
public distribution, and customised, adaptable software systems. Software includes the software portion of
firmware. It applies to a complete stand-alone software system and to software systems that are embedded
and integrated into larger more complex and complete systems of systems (SoS). The processes, activities, and
tasks of this document can also be applied during the acquisition of a system that contains software.
This document applies to the full life cycle of software systems, products, and services, including conception,
development, operations, support, and retirement, and to their acquisition and supply, whether performed
internally or externally to an organization. The life cycle processes of this document can be applied
concurrently, iteratively, and recursively to a software system and incrementally to its elements.
This document can be applied in organizations and software projects using a variety of formal engineering
approaches. It is applicable for agile approaches and methods, which are the most widely used for software
development, sustainment, and maintenance, and which are believed to be more affordable and to deliver
usable products more quickly.
This document does not identify or require any specific software life cycle model, development methodology,
method, modelling approach, or techniques for selecting a life cycle model for the organization or project and
mapping the processes, activities, and tasks in this document into that model. Using engineering judgment to
help achieve the desired level of quality is also outside the scope of this document.
This document does not detail information items in terms of name, format, explicit content, and recording
media. ISO/IEC/IEEE 15289 identifies the content for life cycle process information items (documentation).
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved

ISO, IEC, and IEEE maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
— — IEEE Standards Dictionary Online: available at: https://dictionary.ieee.org/
NOTE Definitions for other system and software engineering terms can be found in ISO/IEC/IEEE 24765, available
at www.computer.org/sevocab.
3.1.1
acquirer
stakeholder (3.1.76(3.1.76)) that acquires or procures a system (3.1.78(3.1.78),), product (3.1.49(3.1.49),), or
service (3.1.65(3.1.65)) from a supplier (3.1.77(3.1.77))
Note 1 to entry: Other terms commonly used for an acquirer are buyer, customer (3.1.19(3.1.19),), owner, purchaser, or
internal organizational sponsor.
3.1.2
acquisition
process (3.1.45(3.1.45)) of obtaining a system (3.1.78(3.1.78),), product (3.1.49(3.1.49)) or service
(3.1.65(3.1.65))
3.1.3
activity
set of cohesive tasks (3.1.83(3.1.83)) of a process (3.1.45(3.1.45))
3.1.4
agile development
development approach based on iterative development, frequent inspection and adaptation, and incremental
deliveries, in which requirements (3.1.56(3.1.56)) and solutions evolve through collaboration in cross-
functional teams and through continual stakeholder (3.1.76(3.1.76)) feedback
3.1.5
agreement
mutual acknowledgement of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
3.1.6
architecture
fundamental concepts or properties of an entity in its environment (3.1.25(3.1.25)) and governing principles
for the realization and evolution of this entity and its related life cycle (3.1.34(3.1.34) )processes
(3.1.45(3.1.45))
[SOURCE: ISO/IEC/IEEE 42010:2022, 3.2]
3.1.7
architecture description framework
conventions, principles and practices for the description of architectures (3.1.6(3.1.6)) established within a
specific domain of application or community of stakeholders (3.1.76(3.1.76))
EXAMPLE Generalized Enterprise Reference Architecture and Methodologies (GERAM) (ISO 15704:2019, Annex B),
Reference Model of Open Distributed Processing (RM-ODP) (ISO/IEC 10746-1), Reference Model of Open Distributed
Processing (RM-ODP), Unified Architecture Framework (UAF), and NATO Architecture Framework (NAF).
© ISO/IEC/IEEE 2025 – All rights reserved
[SOURCE: ISO/IEC/IEEE 42010:2022, 3.5, modified — The abbreviated term and note 1 to entry have been
removed.]
3.1.8
architecture view
information part comprising portion of an architecture (3.1.6(3.1.6)) description
[SOURCE: ISO/IEC/IEEE 42010:2022, 3.7, modified — EXAMPLE has been removed.]
3.1.9
architecture viewpoint
set of conventions for the creation, interpretation and use of an architecture view (3.1.8(3.1.8)) to frame one
or more concerns (3.1.16(3.1.16))
[SOURCE: ISO/IEC/IEEE 42010:2022, 3.8, modified — Notes to entry have been removed.]
3.1.10
artefact
work product (3.1.49(3.1.49)) that is produced and used during a project (3.1.50(3.1.50)) to capture and
convey information
EXAMPLE Models, stakeholder (3.1.76(3.1.76) )requirements (3.1.56(3.1.56),), system (3.1.78(3.1.78))
requirements, architecture (3.1.6(3.1.6)) descriptions, design (3.1.20(3.1.20)) descriptions, source code, implemented
system elements (3.1.79(3.1.79),), verified or validated system.
3.1.11
audit
independent examination of a work product (3.1.49(3.1.49)) or set of work products to assess compliance
with contractual agreements (3.1.5(3.1.5)) or conformance to specifications, standards, or other criteria
3.1.12
baseline
formally approved version of a configuration item (3.1.17(3.1.17),), regardless of media, formally designated
and fixed at a specific time during the configuration item’s life cycle (3.1.34(3.1.34))
[SOURCE: IEEE Std 828-2012]
3.1.13
business process
partially ordered set of enterprise activities (3.1.3(3.1.3)) that can be executed to achieve some desired end-
result in pursuit of a given objective of an organization (3.1.41(3.1.41))
3.1.14
capability
ability to do something useful under a particular set of conditions
[SOURCE: ISO/IEC/IEEE 24641:2023, 3.1.3, modified — Note 1 to entry has been removed.]
3.1.15
concept of operations
verbal and graphic statement, in broad outline, of an organization’s (3.1.41(3.1.41)) assumptions or intent
regarding an operation or series of operations of new, modified, or existing organizational systems
(3.1.78(3.1.78))
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
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
simultaneously or in succession to achieve an organizational performance objective. See also operational concept
(3.1.39(3.1.39).).
Note 2 to entry: The concept of operations provides the basis for bounding the operating space, system capabilities
(3.1.14(3.1.14),), interfaces (3.1.33(3.1.33)) and operating environment (3.1.25(3.1.25).).
[SOURCE: ANSI/AIAA G-043B-2018, 5.2, modified — The second definition has been used; the last two
sentences of Note 1 to entry have been removed; Note 2 to entry has been added.]
3.1.16
concern
matter of interest or importance to a stakeholder (3.1.76(3.1.76))
Note 1 to entry: A concern pertains to any influence on a system (3.1.78(3.1.78)) in its environment (3.1.25(3.1.25),),
including developmental, technological, business, operational, organizational, political, economic, legal, regulatory,
ethical, ecological, and social influences.
[SOURCE: ISO/IEC/IEEE 42020:2019, 3.8, modified — EXAMPLE has been removed; Note 1 to entry has been
added.]
3.1.17
configuration item
item or aggregation of hardware (3.1.29(3.1.29)) or software (3.1.66(3.1.66)) with associated information and
data
Note 1 to entry: Information items (3.1.31(3.1.31)) can be considered as part of the software and managed as part of the
configuration item, or can be managed using the information management process (3.1.45(3.1.45).).
3.1.18
constituent system
independent system (3.1.78(3.1.78)) that forms part of a system of systems (SoS) (3.1.81(3.1.81))
Note 1 to entry: Constituent systems can be part of one or more SoS. Each constituent system is a useful system by itself,
having its own development, management (3.1.38(3.1.38),), utilization, goals, and resources (3.1.60(3.1.60),), but
interacts within the SoS to provide the unique capability (3.1.14(3.1.14)) of the SoS.
[SOURCE: ISO/IEC/IEEE 21839:2019, 3.1.1]
3.1.19
customer
organization (3.1.41(3.1.41)) or person that receives a product (3.1.49(3.1.49)) or service (3.1.65(3.1.65))
EXAMPLE Consumer, client, user (3.1.88(3.1.88),), acquirer (3.1.1(3.1.1),), buyer or purchaser.
Note 1 to entry: A customer can be internal or external to the organization.
3.1.20
design
specification of system elements (3.1.79(3.1.79)) and their relationships, that is sufficiently complete to
support a compliant implementation of the architecture (3.1.6(3.1.6))
Note 1 to entry: Design provides the detailed implementation-level physical structure, behaviour, temporal
relationships, and other attributes of system elements.
© ISO/IEC/IEEE 2025 – All rights reserved
3.1.21
design characteristic
design (3.1.20(3.1.20)) attribute or distinguishing feature that pertains to a measurable description of a
product (3.1.49(3.1.49),), or service (3.1.65(3.1.65))
3.1.22
digital engineering
software engineering (3.1.69(3.1.69)) discipline that uses the underlying data, modelling, simulation, and
analytical functions for physical or logical systems (3.1.78(3.1.78)) conceptualization, development, test and
evaluation, and integrated control of operational performance
3.1.23
enabling system
system (3.1.78(3.1.78)) that supports a system-of-interest (3.1.80(3.1.80)) during its life cycle (3.1.36(3.1.36)
)stages (3.1.75(3.1.75)) but does not necessarily contribute directly to its function during operation
EXAMPLE A configuration management system used to control software elements (3.1.68(3.1.68)) during software
(3.1.66(3.1.66)) development.
Note 1 to entry: Each enabling system has a life cycle of its own.
3.1.24
engineering
application of a systematic, disciplined, quantifiable approach to structures, machines, products
(3.1.49(3.1.49),), systems, or processes (3.1.45(3.1.45))
3.1.25
environment
context determining the setting and circumstances of all influences upon a system (3.1.78(3.1.78))
3.1.26
facility
physical means or equipment for facilitating the performance of an action, e.g.,. buildings, instruments, tools
3.1.27
firmware
ordered set of instructions and associated data stored in a way that is functionally independent of main
storage, usually in read-only memory
3.1.28
governance
practice of establishing and enforcing strategic goals and objectives, organizational policies and performance
parameters
3.1.29
hardware
physical equipment used to process (3.1.45(3.1.45),), store, or transmit computer programs or data
[SOURCE: ISO/IEC 19770-1:2017, 3.21]
3.1.30
incident
anomalous or unexpected event or set of events at any time during the life cycle (3.1.36(3.1.36)) of a project
(3.1.50(3.1.50),), product (3.1.49(3.1.49),), service (3.1.65(3.1.65),), or system (3.1.78(3.1.78))
Note 1 to entry: An incident is elevated and treated as a problem (3.1.44(3.1.44)) when the cause of the incident is
analysed and corrected to prevent recurrence, or to avoid or minimise loss of life, or damage to property or natural
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
resources (3.1.60(3.1.60).). Some incidents do not involve further analysis, as they result from known errors where
workarounds or solutions are already known.
3.1.31
information item
information product
separately identifiable body of information that is produced, stored, and delivered for human use
Note 1 to entry: A document produced to meet information requirements (3.1.59(3.1.59)) can be an information item,
part of an information item, or a combination of several information items.
Note 2 to entry: An information item can be produced in several versions during a project (3.1.50(3.1.50)) or system
(3.1.78(3.1.78) )life cycle (3.1.36(3.1.36).).
[SOURCE: ISO/IEC/IEEE 15289:2019, 3.1.12, modified — The preferred term "information product" has been
changed to an admitted term.]
3.1.32
infrastructure
hardware (3.1.29(3.1.29)) and software (3.1.66(3.1.66) )environment (3.1.25(3.1.25)) to support system
(3.1.78(3.1.78)) and software design (3.1.20(3.1.20),), development, operation and modification
3.1.33
interface
point at which two or more logical or physical system elements (3.1.79(3.1.79)) meet to act on or communicate
with each other
3.1.34
interoperating system
system (3.1.78(3.1.78)) that exchanges information with the system-of-interest (3.1.80(3.1.80)) and uses the
information that has been exchanged
3.1.35
iteration
repeating the application of the same process (3.1.45(3.1.45)) or set of processes at the same level of
abstraction on the same system (3.1.78(3.1.78)) or system element (3.1.79(3.1.79))
3.1.36
life cycle
evolution of a system (3.1.78(3.1.78),), product (3.1.49(3.1.49),), service (3.1.65(3.1.65),), project
(3.1.50(3.1.50)) or other human-made entity from conception through retirement (3.1.61(3.1.61))
3.1.37
life cycle model
framework of processes (3.1.45(3.1.45)) and activities (3.1.3(3.1.3)) concerned with the life cycle
(3.1.36(3.1.36)) which can be organized into stages (3.1.75(3.1.75),), acting as a common reference for
communication and understanding
3.1.38
management
oversight and direction of activities (3.1.3(3.1.3)) and controls to achieve the strategic objectives set by the
organization's (3.1.41(3.1.41)) governing body
© ISO/IEC/IEEE 2025 – All rights reserved
3.1.39
operational concept
verbal and graphic statement of an organization’s (3.1.41(3.1.41)) assumptions or intent in regard to an
operation or series of operations of a specific system (3.1.78(3.1.78)) or a related set of specific new, existing
or modified 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 (3.1.25(3.1.25)) from the users’
(3.1.88(3.1.88)) and operators’ (3.1.40(3.1.40)) perspectives.
Note 2 to entry: The operational concept is about systems, while a concept of operations (3.1.15(3.1.15)) typically refers
to organizations.
[SOURCE: ANSI/AIAA G-043B-2018, 5.2, modified — The third definition has been used; the first sentence in
Note 1 to entry has been removed; Note 2 to entry has been added.]
3.1.40
operator
individual or organization (3.1.41(3.1.41)) that performs the operations of a system (3.1.78(3.1.78))
Note 1 to entry: The role of operator and the role of user (3.1.88(3.1.88)) can be vested, simultaneously or sequentially,
in the same individual or organization.
Note 2 to entry: An individual operator combined with knowledge, skills and procedures can 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 operating instructions are placed within the system boundary.
3.1.41
organization
person or group of people that has its own functions with responsibilities, authorities, and relationships to
achieve its objectives
EXAMPLE Company, corporation, firm, enterprise, manufacturer, institution, charity, sole trader, association, or
parts or combination thereof.
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.
3.1.42
party
organization (3.1.41(3.1.41)) entering into an agreement (3.1.5(3.1.5))
Note 1 to entry: The agreeing parties are called the acquirer (3.1.1(3.1.1)) and the supplier (3.1.77(3.1.77).).
3.1.43
portfolio
collection of projects (3.1.50(3.1.50)) or systems (3.1.78(3.1.78)) that address the strategic or business
objectives of the organization (3.1.41(3.1.41))
3.1.44
problem
difficulty, uncertainty, or otherwise realised and undesirable condition or situation that is investigated and
can receive corrective action
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
3.1.45
process
set of interrelated or interacting activities (3.1.3(3.1.3)) that transform inputs into outputs
3.1.46
process outcome
observable result of the successful achievement of the process purpose (3.1.47(3.1.47))
3.1.47
process purpose
high level objective of performing the process (3.1.45(3.1.45)) 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 (3.1.76(3.1.76))
3.1.48
process reference model
PRM
model comprising definitions of processes (3.1.45(3.1.45)) in a domain of application described in terms of
process purpose (3.1.47(3.1.47)) and outcomes, together with an architecture (3.1.6(3.1.6)) describing the
relationships between the processes
[SOURCE: ISO/IEC 33001:2015, 3.3.16], modified — The abbreviated term "PRM" has been added.]
3.1.49
product
result of a process (3.1.45(3.1.45))
Note 1 to entry: ISO/IEC/IEEE 15288 defines a product as "output of an organization (3.1.41(3.1.41)) that can be
produced without any transaction taking place between the organization and the customer (3.1.19(3.1.19)".)".
Note 2 to entry: There are four generic product categories: hardware (3.1.29(3.1.29),), e.g. engine mechanical part;
software (3.1.66(3.1.66),), e.g. computer program procedures, and possibly associated documentation and data; services
(3.1.65(3.1.65),), e.g. transport; and processed materials, e.g. lubricant. Hardware and processed materials are generally
tangible products, while software or services are generally intangible.
3.1.50
project
endeavour with defined start and finish criteria undertaken to create a product (3.1.49(3.1.49)) or service
(3.1.65(3.1.65)) in accordance with specified resources (3.1.60(3.1.60)) and requirements (3.1.59(3.1.59))
Note 1 to entry: A project is sometimes viewed as a unique process (3.1.45(3.1.45)) comprising coordinated and
controlled technical management (3.1.85(3.1.85)) and technical activities (3.1.3(3.1.3).).
Note 2 to entry: Continuous development approaches such as agile and DevOps can create products and services without
the defined start and finish criteria of projects.
3.1.51
qualification
process (3.1.45(3.1.45)) of determining whether an entity is capable of fulfilling specified requirements
(3.1.59(3.1.59))
3.1.52
quality assurance
QA
process (3.1.45(3.1.45)) that is focused on providing confidence that quality requirements (3.1.56(3.1.56)) are
fulfilled
© ISO/IEC/IEEE 2025 – All rights reserved
3.1.53
quality characteristic
inherent characteristic of a product (3.1.46(3.1.46),), service (3.1.65(3.1.65),), process (3.1.45(3.1.45)) or
system (3.1.78(3.1.78)) related to a requirement (3.1.59(3.1.59))
Note 1 to entry: Critical quality characteristics commonly include those related to health, safety (3.1.63(3.1.63),), security
(3.1.64(3.1.64)) assurance, reliability, availability, and supportability.
[SOURCE: ISO 9000:—, 3.11.2, modified — ‘object’ has been replaced with ‘product, service, process or
system’; notes to entry have been replaced by a new one.]
3.1.54
quality control
QC
tasks (3.1.83(3.1.83)) to evaluate the quality of services (3.1.65(3.1.65)) as delivered or the quality of
developed or manufactured products (3.1.46(3.1.46))
3.1.55
quality management
QM
coordinated activities (3.1.3(3.1.3)) to direct and control an organization (3.1.41(3.1.41)) with regard to
quality
3.1.56
quality requirement
requirement (3.1.59(3.1.59)) for quality properties or attributes of a product (3.1.46(3.1.46),), data, or service
(3.1.65(3.1.65)) that satisfy needs associated with its the purpose
3.1.57
recursion
repeating the application of the same process (3.1.45(3.1.45)) or set of processes to progressively more
detailed system elements (3.1.79(3.1.79))
3.1.58
release
version of a configuration item (3.1.17(3.1.17)) that is made available for a specific purpose
EXAMPLE Test release.
3.1.59
requirement
statement which translates or expresses a need and its associated constraints and conditions
[SOURCE: ISO/IEC/IEEE 29148:2018, 3.1.19, modified — Notes to entry have been removed.]
3.1.60
resource
asset that is utilised or consumed during the execution of a process (3.1.45(3.1.45))
Note 1 to entry: Resources include those that are reusable, renewable, or consumable.
Note 2 to entry: Resource includes diverse entities such as funding, personnel, facilities (3.1.26(3.1.26),), capital
equipment, tools and utilities such as power, water, fuel and communication infrastructures (3.1.32(3.1.32).).
© ISO/IEC 2025, © /IEEE 2025 – All rights reserved
3.1.61
retirement
withdrawal of active support by the operation and maintenance organization (3.1.41(3.1.41),), partial or total
replacement by a new system (3.1.78(3.1.78),), installation of an upgraded system, or final decommissioning
and disposal
3.1.62
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 (3.1.63(3.1.63),), and
environmental goals] and can apply at different levels, such as strategic, organization-wide, project (3.1.50(3.1.50),),
product (3.1.46(3.1.46)) and process (3.1.45(3.1.45).).
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.
3.1.63
safety
expectation that a system (3.1.78(3.1.78)) does not, under defined conditions, lead to a state in which human
life, health, property, or the environment (3.1.25(3.1.25)) is endangered
3.1.64
security
protection against intentional subversion or forced failure
Note 1 to entry: Security includes authenticity, accountability, confidentiality, integrity, availability, non- repudiation,
and reliability, all of which have the related issue of their assurance.
[SOURCE: NATO AEP-67, modified — Note 1 to entry has been updated.]
3.1.65
service
performance of activities (3.1.3(3.1.3),), work, or duties
Note 1 to entry: The dominant elements of a service are generally intangible.
Note 2 to entry: A service is coherent, discrete, and can be composed of other services.
Note 3 to entry: In ISO/IEC/IEEE 15288, service is defined as "output of an organization (3.1.41(3.1.41)) with at least one
activity (3.1.3(3.1.3)) necessarily performed between the organization and the customer (3.1.19(3.1.19).).
3.1.66
software
computer programs, procedures and possibly associated documentation and data pertaining to the operation
of a computer system (3.1.78(3.1.78))
© ISO/IEC/IEEE 2025 – All rights reserved
3.1.67
software bill of materials
SBOM
list of uniquely identified software (3.1.66(3.1.66)) items, including their sources in the supply chain, version,
license and copyright data, and possibly security (3.1.64(3.1.64)-)-related data
Note 1 to entry: Each SBOM item can have its own SBOM.
3.1.68
software element
system element (3.1.79(3.1.79)) that is software (3.1.66(3.1.66))
Note 1 to entry: A software element can be part of a software system (3.1.72(3.1.72)) or a system (3.1.78(3.1.78)) that is
not predominantly software.
3.1.69
software engineering
application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance
of software (3.1.66(3.1.66))
Note 1 to entry: Software engineering is the application of engineering (3.1.24(3.1.24)) to software.
3.1.70
software item
source code, object code, control code, control data or collection of these items
Note 1 to entry: A software (3.1.66(3.1.66)) item can be viewed as a system element (3.1.79(3.1.79).). Software items are
typically configuration items (3.1.17(3.1.17).).
3.1.71
software product
set of computer programs, procedures, and possibly associated documentation and data
...