ISO/IEC/IEEE 24748-10

ISO/IEC/IEEE FDIS 24748-10:2025(en)
ISO/IEC /JTC 1/SC 7/WG 7 N9871
Date: 2025-06-30
Secretariat: BIS
First edition
Date:
Systems and software engineering — Life cycle management — —
Part 10:
Guidelines for systems engineering agility
Ingénierie des systèmes — Gestion du cycle de vie — Partie 10: xxx

FDIS stage
ISO/IEC/IEEE FDIS 24748-10:2025(en)
© ISO/IEC/ 2025
© IEEE 20242025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
or IEEE at the respective address below or ISO’s member body in the country of the requester.
ISO copyright office  Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8  3 Park Avenue, New York
CH-1214 Vernier, Geneva  NY 10016-5997, USA
Phone: + 41 22 749 01 11
E-mail: copyright@iso.org  Email: Email: stds.ipr@ieee.org
Website: www.iso.org  Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
iii
ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)
Contents
Foreword . v
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 . 3
4 Concepts . 3
4.1 General . 3
4.2 Context . 3
4.3 Common misunderstandings about agile . 6
5 Strategic aspects and guidelines for SE agility . 7
5.1 General . 7
5.2 Adaptable modular architecture . 8
5.3 Iterative incremental development . 8
5.4 Attentive situational awareness . 9
5.5 Attentive decision making . 9
5.6 Common-mission teaming . 10
5.7 Shared-knowledge management . 10
5.8 Continual integration and test . 11
5.9 Being agile . 11
Annex A (informative) Case story example . 12
Annex B (informative) Industrial DevOps . 16
Bibliography . 19
IEEE notices and abstract . 21

© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
iv © IEEE 2024 – All rights reserved

ISO/IEC/IEEE FDIS 24748-10:2025(en)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA and participate without compensation from IEEE. While IEEE administers the process and establishes
rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test,
or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
A list of all parts in the ISO/IEC/IEEE 24748 series can be found on the ISO and IEC websites.
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 DIS FDIS 24748-10:2024(E2025(en)
Introduction
Systems engineering agility is a strategy-based method for designing, building, sustaining, and evolving
purpose-fulfilling creations when knowledge is uncertain and operational environments are dynamic.
Strategies are abstractions for what needs to be accomplished and why, without constraints or directions on
how to achieve them. Thus, systems engineering agility is a what, not a how; a strategic intent, not a tactical
method. That is, agility provides strategic direction rather than prescribing detailed methods. There are many
different methods that can be adopted, adapted, or crafted to suit project contexts and organizational cultures,
but all share the same goals and strategies.
This document specifies strategic aspects supporting systems engineering agility. It includes guidelines for the
application of the strategic aspects as well as relevant examples. Individually and collectively, the aspects can
improve capability to deal with uncertain knowledge and dynamic environments. These strategic aspects can
complement life cycle models such as those described in ISO/IEC/IEEE 24748-1 and ISO/IEC/IEEE 15288,
enhancing responsiveness without prescribing specific process sequences.
© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
vi © IEEE 2024 – All rights reserved

DRAFT International Standard ISO/IEC/IEEE DIS 24748-10:2025(en)

Systems and software engineering — Life cycle management — Part 4:
Guidelines for systems engineering agility —
Part 10:
Guidelines for systems engineering agility
1 Scope
This document:
— — specifies strategic aspects supporting systems engineering agility;
— — provides guidelines for their selection and application.
This document is applicable to:
— — those who use or plan to use ISO/IEC/IEEE 15288 on projects dealing with human-made systems and
services related to those systems and products;
— — those who are responsible for the technical management of projects concerned with the engineering
of systems;
— — those responsible for executing ISO/IEC/IEEE 15288 system life cycle processes at a project level;
— — organizations and individuals who are seeking to improve their capability to deal with uncertain
knowledge and dynamic environments.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC, and IEEE maintain 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://ieeexplore.ieee.org/xpls/dictionary.jsp
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software Engineering
Vocabulary) database and which is publicly accessible at http://www.computer.org/sevocab.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved

ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)
3.1.1 3.1.1
agile
approach to development, delivery, and maintenance of products and services by enabling rapid response to
feedback
[SOURCE: ISO/IEC/IEEE 33202:2024, 3.2]
3., modified — Note 1.2 to entry has been removed.]
3.1.2
DevOps
development and operations
set of principles and practices which enable better communication and collaboration between relevant
stakeholders for the purpose of specifying, developing, and operating software and systems (3.1.6(3.1.6),),
products and services, and continuous improvements in all aspects of the life cycle
Note 1 to entry: Extensions include DevSecOps which addresses concerns related to security throughout development
and operations, and DevStar or Dev*Ops an evolving set of principles and practices that consider multiple factors (e.g.
security, safety, automation) for building better systems faster to achieve business outcomes.
[SOURCE: ISO/IEC/IEEE 32675:2022, 3.1, modified — Note 1 to entry has been added.]
3.1.3 3.1.3
increment
tested, deliverable version of a product that provides new or modified capabilities
[SOURCE: ISO/IEC 33202:2024, 3.17, modified — “software” has been removed.]
3.1.4 3.1.4
iteration
repeating the application of the same process or set of processes on the same level of the system (3.1.6(3.1.6))
structure
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.28]
3.1.5 3.1.5
modular
composed of discrete parts
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2504]
3.1.6 3.1.6
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g.
aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym, e.g. aircraft,
though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services and personnel required for operations and support to the degree necessary
for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]
© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
2 © IEEE 2024 – All rights reserved

ISO/IEC/IEEE DISFDIS 24748-10:2025(en)
3.1.7 3.1.7
systems engineering
transdisciplinary and integrative approach to enable the successful realization, use, and retirement of
engineered systems (3.1.6(3.1.6)) using systems principles and concepts and scientific, technological and
management methods
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.50]
3.1.8 3.1.8
systems engineering agility
strategy-based method for designing, building, sustaining, and evolving purpose-fulfilling creations when
knowledge is uncertain and operational environments are dynamic.
Note 1 to entry: Strategies are abstractions for what needs to be accomplished and why, without constraints or directions
on how to achieve them.
3.1.9 3.1.9
technical debt
deferred cost of work not performed at an earlier point in the product life cycle
3.2 Abbreviated terms
CIE continuous integration environment
DARPA Defense Advanced Research Project Agency
INCOSE International Council on Systems Engineering
IPT integrated product team
MRAP mine-resistant ambush protected (vehicle)
NATO North Atlantic Treaty Organization
PLM product life cycle management
SoI system of interest
4 Concepts
4.1 General
Systems engineering (SE) agility is a strategy-based method for designing, building, sustaining, and evolving
purpose-fulfilling creations when knowledge is uncertain and operational environments are dynamic.
NOTE An example case story can be found in Annex AAnnex A.
4.2 Context
The concept of successive repetitions of the process of interlaced testing and design of the system ultimately
[21 [21]]
becoming the system was introduced at the 1968 NATO conference on Software Engineering . . In 1991,
[21[21]]
the US Department of Defense funded a project to investigate what could drive competition in
[19[19] ]
manufacturing enterprises after Lean manufacturing (a term related to the Toyota Production System ) )
had stabilized. That project introduced the concept of agility to describe how organizations can deal with the
rapid pace of change in markets and technologies. The words agile and agility were intended in that and
related subsequent work, as in this document, to simply mean what is meant when they are applied in
everyday conversation to characterize anything – quick and nimble interaction and response – agility being
the noun form and agile being the adjectival form.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)
Over the next four years the Agility Forum, funded by DARPA at Lehigh University, led 12001 200 participants
from 125 organizations through a collaborative discovery process across a broad base of business and
[11 [11]]
engineering areas . . The initial focus on agile manufacturing evolved quickly into agile system, agile
enterprise, and agile command and control.
In 2001, the word agile was adopted as an adjective to describe a variety of new ways to develop software (e.g.
[15 [15]]
agile software development) ). . INCOSE established agile systems engineering as one of its top priorities
[14 [14]]
in 2014 . . INCOSE instigated case studies and refinement of agile systems engineering life cycle
[12[12] ]
concepts . .
In this document, and in common usage, agile and agility refer to the ability to move quickly and easily. These
two points of view are the look and feel of SE agility that this guide elaborates. Ideally, agility in SE manifests
as an appropriate response to an immediate need in pursuit of a goal. Rather than attempting to dominate the
environment, agile SE is a thoughtful engagement with opportunities and threats in the environment. This
enables timely adjustments across the system life cycle, reinforcing adaptability at both strategic and
operational levels.
SE agility is best understood when contrasted to the sequential life cycle approach and in how the two relate
Figure 1 shows extreme forms of these two life cycle approaches in
to the system life cycle spectrum. Figure 1
terms of their stages and data flows. All life cycle approaches for SoI fall somewhere between the two ends of
the spectrum, depending upon the process-encoded degree of attentiveness and responsiveness to dynamics
[10[10] ]
in knowledge and environment. . SE agility shifts lifecyclelife cycle execution toward more concurrent,
feedback-driven practices, enabling better alignment with dynamic environments. Asynchronous and
concurrent life-cycle activity, as recognized in ISO/IEC/IEEE 24748-1, is a hallmark of agile SE processes. As
shown in Figure 2Figure 2,, situational awareness attends to external and internal situational awareness –
engaging all other activities as appropriate.

SOURCE: Dove, R. et al (2023), reproduced with the permission of the authors.
© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
4 © IEEE 2024 – All rights reserved

ISO/IEC/IEEE DISFDIS 24748-10:2025(en)

SOURCE: Dove, R. et al (2023), reproduced with the permission of the authors.
Figure 1 — SE life cycle spectrum

SOURCE: Dove, R. et al (2023), reproduced with the permission of the authors.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)

SOURCE: Dove, R. et al (2023), reproduced with the permission of the authors.
Figure 2 — Agile SE life cycle model
NOTE 1 ISO/IEC/IEEE 24748-1 provides more information about life cycle models and ISO/IEC/IEEE 32675 provides
information about DevOps. Information about Industrial DevOps, a principle-based, tactical application of SE agility, can
be found in Annex BAnnex B.
NOTE 2 ISO/IEC TR 24587 provides more information about Agile and DevOps principles and practices.
ISO/IEC 33202 provides information for core agile practices related to software.
4.3 Common misunderstandings about agile
[8] [9 ]
Table 1Table 1 shows some common misunderstandings associated with agile , [8],[9] that often influence
concerns about agile SE and their respective counterpoints.
Table 1 — Common misunderstandings about agile
Misunderstanding Effective use of agile
Paperwork is not required The emphasis in agile approaches is to develop a working product with only the
necessary documentation required for understanding to aid in sustainability and
future development.
There are no checks and Checks and balances are achieved through the demonstration of working
balances products that meet customer needs and through project governance, including
cadence of reviews and frequent customer feedback.
The speed of development is Agile approaches deliver working product sooner to the customer, but that
faster doesn’t necessarily mean that the overall project will be completed faster. Unlike
traditional sequential efforts where all capabilities are delivered once and at the
end of a project, agile approaches deliver capabilities to the customer throughout
© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
6 © IEEE 2024 – All rights reserved

ISO/IEC/IEEE DISFDIS 24748-10:2025(en)
Misunderstanding Effective use of agile
the project as smaller batches of work. There is the potential (not guarantee) that
the overall project will finish faster.
Agile approaches are only for Although there are many codified processes in practice for software development
software and fewer, more proprietary for other engineering domains, see Annex AAnnex A
for a case story describing a military radio system that employs agile approaches
for hardware development.
Agile approaches aren’t for With sufficient contextual flexibility, a principle-based agile methodology that
highly regulated industries addresses regulations as functional requirements can support highly regulated
industries. For example, agile approaches have successfully been implemented in
[22[22] ]
US Department of Defense applications . .
There is less planning involved Arguably there is more planning and replanning in an agile approach, with an
in agile approaches emphasis on just-in-time dynamic planning based on evolving knowledge rather
than conjectured expectations (i.e. plan, act, observe, feedback, replan, act,
observe, etc.).
Agile approaches favour In agile the teams (often composed of systems engineers, developers, testers,
developers integrators, customer representatives and others) are given the authority to
implement their scope. That is, teams, not the developers, self-organize and make
decisions to implement their allocated features/stories. The focus here is on
teams, not developers.
An agile approach is hampered No big design up front. Throughout the course of engineering a system, one can
by architecture discover through modelling the underlying critical factors or influence points
determining the system’s behaviour and other characteristics. These critical
factors inform and shape the evolving and growing architecture and design of the
system.
An agile approach doesn’t scale Scaling isn’t always straightforward. However, cross-team collaborations and
coordination, governed by a minimal set of situated process principles and
working with an easy-to-communicate, initially bare-minimum system
architecture, have been successfully used to scale agile development.
Regular customer feedback Validation of the final system solution in its intended operating environment is
through development necessary; however, it may be streamlined based on the previous levels of testing
minimizes/removes the need and the risk profile of the project.
for formal validation
ISO/IEC/IEEE 15288 is only for ISO/IEC/IEEE 15288 “does not prescribe a specific system life cycle model,
waterfall development methodology, method, modelling approach or technique”
(ISO/IEC/IEEE 15288:2023, Clause 1). The processes, activities and tasks in
ISO/IEC/IEEE 15288 can be used with agile techniques with or without tailoring.
“Playing by ear” is more Life cycle processes form a basis for adaptation that avoids unintended omission,
important than following unnecessary activities and indiscipline. For example, the project assessment and
processes control process and decision management process provide for iterative
incremental development that is at once responsive and disciplined.
Treating immediate risk is more Effective agile development integrates agile’s short feedback cycles with
valuable than longer-term risk identification, monitoring and treatment of long-term, strategic risks that
considerations. continue throughout the life cycle by adapting, e.g. the risk management process
in ISO/IEC/IEEE 15288.
5 Strategic aspects and guidelines for SE agility
5.1 General
Strategies, or strategic aspects, are abstractions for what needs to be accomplished and why, without
constraints or directions on how to achieve them. Individually and collectively, the aspects can improve
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)
[10[10]]
capability to deal with uncertain knowledge and dynamic environments. The strategic aspects of SE
agility are:
— — adaptable modular architecture;
— — iterative incremental development;
— — attentive situational awareness;
— — attentive decision making;
— — common-mission teaming;
— — shared-knowledge management;
— — continual integration and test;
— — being agile.
Individual aspects can tactically manifest over a range of intensity. Thus, the degree of SE agility is a product
of how many of these aspects are operational as well as how effectively each one contributes to the SE agility
required by the operating environment. Concurrent implementation of all aspects is not necessary to gain SE
agility benefits. Incremental adoption can accommodate incremental appetites. Prioritization of aspects
should be informed by system characteristics, mission needs, and organizational context. The order of
presentation does not imply priority or dependency.
5.2 Adaptable modular architecture
The goal is to facilitate product and process experimentation, modification and evolution through composable
and reconfigurable product and process designs from variations of reusable assets. One fixed process
approach won’t fit all projects, so an appropriate process should be easy to compose and evolve according to
context and usage experience. Variations of reusable process modules should be built over time as features
are modified for different contextual usage, potentially informing multiple reference architectures. The agility
of the process is dependent upon the ease and speed in which the product can be reconfigured and modified
as development and feedback yield new knowledge, so both process and product should have adaptable
modular architectures. Modularity also supports concurrent engineering by enabling distributed work on
different modules.
Examples of the adaptable modular architecture’s strategic aspect include:
— — product: automobile design employs reusable modules for new model market entry and aftermarket
modification;
[14[14]]
— — process: an uncrewed vehicle development depicts assembly of IPT working groups, validation
test activities, and frequent integration activities from reusable (modular) resources appropriate for the
activity.
5.3 Iterative incremental development
The goal is to minimise rework, maximize quality and facilitate innovation through incremental loops of
building, correcting and improving capabilities. Iterative development performs a “plan-do-check-adjust”
cycle repeatedly, usually with a short and consistent cycle length. Incremental development produces value
(capabilities) as small units of work, each unit being applied to any work previously completed. Increment
production should be beneficially timed to coordinate events such as integrated testing and evaluation,
capability deployment, experimental deployment, or release to production. Increments can have constant or
© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
8 © IEEE 2024 – All rights reserved

ISO/IEC/IEEE DISFDIS 24748-10:2025(en)
variable cadence to accommodate management standards or operational dynamics. Iteration cycles should be
beneficially timed to minimize rework cost as a project learns experimentally and empirically. Based on the
characteristics of the project, determine the baseline for the project's iteration cycle.
NOTE ISO/IEC/IEEE 24748-1 provides elaboration on life cycles and life cycle models.
Examples of the iterative incremental development strategic aspect include:
[7[7] ]
— — incremental commitment spiral model ; ;
— — rapid cycles of build-test-learn iterations;
— — overlapping stages of subcontracted device development and government-led architecture,
integration, and validation increments;
— — asynchronous or unaligned integrated domain engineering (software, field programmable gate arrays,
[13[13] ]
electronic circuit boards, mechanical) testable increments . .
5.4 Attentive situational awareness
The goal is timely knowledge of emergent risks and opportunities through active monitoring and evaluation
of relevant internal and external environmental factors. Awareness to the changing internal (doing things
right) and external (doing the right things) situation should be maintained attentively. The capability for
timely and cost-effective change should be active and should include evaluation of when that ability should be
exercised. Situational awareness can be enhanced with systemic methods and mechanisms.
Examples of the attentive situational awareness strategic aspect include:
— — work in process demonstrations and reviews for stakeholder feedback;
— — use of automated and frequently-executed methods to provide awareness of current requirements
conformance (e.g. test suites, model analyses);
— — periodic SE process-participant collaborative evaluations;
[13[13] ]
— — continual market and technology evolution monitoring and evaluation ; ;
— — systematic internet search for pending security threats and in-use commercial off-the-shelf (COTS)
obsolescence;
— — constant internet search and rapid evaluation acquisition.
— These practices can enhance early risk identification and improve system resilience.
5.5 Attentive decision making
The goal is timely corrective and improvement actions through systemic linkage of situational awareness to
decisive action. Decision making should be empowered at the point of where knowledge is sufficient and
relevant, coupled with a governance structure that puts decisions at the appropriate level. For example,
acknowledged technical debt can support informed decision making to determine whether prompt action or
continued monitoring is preferable.
Examples of the attentive decision-making strategic aspect include:
— — satisficing – making a timely good-enough decision rather than an optimal time-consuming decision;
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)
— — systemic refactoring of development planning to shuffle resources needed to address real-time
security-threat evolution.
5.6 Common-mission teaming
The goal is coherent, collective pursuit of the common mission, facilitating engaged collaboration, cooperation
and teaming among all relevant stakeholders. Collaboration, cooperation, and teaming are not synonymous,
and should receive individual support attention. Collaboration is an act of relevant information exchange
among individuals, cooperation is an act of optimal give-and-take among individuals, and teaming is an act of
collective endeavour toward a common purpose. Common-mission teaming can be encouraged by shared
objectives, regular coordination, and co-located or virtually connected teams.
Examples of the common-mission teaming strategic aspect include:
— — integrated product teams – multidisciplinary groups of people who are collectively responsible for
delivering a defined product or process;
— — high-performance teams – groups of people with complementary skills, committed to a shared vision,
working towards a common objective;
— — the SE process included the successful objectives and abilities to integrate outside contractors as full
[14[14] ]
team members, forming a family-like relationship of all-for-one and one-for-all ; ;
— — a program was plagued with discordant relationships among a variety of service agencies, contractors,
and manufacturers. Paul Mann credits the eventual acclaimed success of the mine-resistant ambush
protected (vehicle) (MRAP) program to the many people who pulled together in a process that enveloped
them all in the mission of program success, rather than local optimization of individual needs or contract
[14[14] ]
performance independent of the effect on all others in the program . .
5.7 Shared-knowledge management
The goal is accelerating mutual learning and authoritative sources of truth for internal and external
stakeholders facilitating communication, collaboration and knowledge curation. Knowledge from both short
and long time frames should be considered. Short time frame operational knowledge addresses what
happened in the past, what’s happening now, what’s planned to happen in the future. Long time frame curated
knowledge address what is known of reusable relevance, e.g. digital artefacts, lessons learned, and proven
practices.
Examples of the shared-knowledge management strategic aspect include:
— — periodic status meetings and information radiators, e.g. war room status displays;
— — collaboration tools;
— — model-based SE (MBSE) tools;
— — product life cycle management (PLM) tools.
— — the use of artificial intelligence (AI) for acquiring and sharing knowledge simplifies and also
complicates work; in many agile applications, maintaining knowledge is not overly burdensome.
— — the continuous integration environment (CIE) is a data-driven repository of knowledge, with
customized viewing templates for different needs and viewers; the intent is to facilitate a real-time
collective consciousness, where all team members are plugged in to all information associated with full
[14[14] ]
project success, as well as to the information of relevance to their specific responsibilities and tasks . .
© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
10 © IEEE 2024 – All rights reserved

ISO/IEC/IEEE DISFDIS 24748-10:2025(en)
5.8 Continual integration and test
The goal is early revelation of system integration issues prior to deployment through integrated
demonstration and test of work in progress. Discovering integration issues late in development or in operation
can impact cost and schedule with major rework. Multiple domain engineering activities should be
synchronized via continual integration and test, providing faster and clearer insight into potential system
integration issues.
Examples of the continual integration and test strategic aspect include:
— — digital engineering;
— — physical system mock-up for prototyping and integrating systems during development;
— — ANTE (agile non-target environment) is used to compose integrated systems consisting of simulated
devices, real devices, software simulations and work-in-process, and temporary low fidelity proxy devices;
[10[10] ]
subcontractors are required to provide device simulations to ANTE specs . .
5.9 Being agile
The goal is to provide attentive operational response to evolving knowledge and dynamic environments
through active sensing, responding and evolving internal and external environments. SE agility is about being
agile as a behaviour, not a procedure – a behaviour that dynamically aligns actions with evolving conditions,
sensitive to threats and opportunities in the environment, decisive when faced with threat or opportunity, and
driven to improve these capabilities. Deciding how to implement any of the core aspects, even this one, should
be done with sense-respond-evolve principles in mind as aspect objectives.
Examples of the being agile strategic aspect include:
— — Some approaches provide introspective sense-respond-evolve examples in agile engineering with its
frequent product review and process retrospective ceremonies. These concepts are independent of the
engineering domain.
— — Extrospective (outwardly focused) sense-respond-evolve examples include cycling through
instrumented in-the-environment operational testing for rapid design evolution and actively searching
the internet for innovative technology solutions with rapid acquisition capability for decisive evaluation.
— — Both introspective and extrospective examples are combined in their external market and technology
evolution monitoring and evaluation compared against internal skills and competency needs.
— Annex A— Annex A elaborates an operationally focused case story about agile development and evolution
of an uncrewed, off-road vehicle.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)
Annex A
(informative)
Case story example
A.1 General
The project was the agile development and evolution of an uncrewed, off-road vehicle.
In 2015, a team from INCOSE studied the project’s six-month overlapping-increment wave-model process and
[14 [14]]
published it as a case study . . Examples in this case story focus solely on the project’s employment of the
eight strategic aspects of systems engineering (SE) agility. Most notably, the process put a prime emphasis on
enabling and facilitating team effectiveness: creating an embraced culture of engagement, a collective
consciousness emerging from comprehensive real-time information support, and a team conscience on a
mission for the end users.
The project ran multiple sub-projects with multiple sponsors simultaneously. At study time, the project
employed 6 subcontractors with 4 to 5 engineers each for device development and 60 government employees
for continuous process and product SE and project support.
A.2 Summary
— — Adaptable modular architectures
— — Program management designed, evolved, owned, and enforced modular architecture and
interface standards.
— — Process task composability was facilitated by common interactive interfaces for contractors
and internal resources.
— — Iterative incremental development
— — Six-month increments balanced sufficient development time with sponsor-demanded progress
evidence.
— — Minimum of two iterations within increments demonstrated non-conflicting progress with
integrated.
— — Attentive situational awareness
— — Full-day table-top exercises with the user at each increment verified and revealed appropriate
needs.
— — Full and constant engagement by internal and external personnel was actively monitored for
sufficiency.
— — Attentive decision making
— — The shared culture expected and demanded timely attention to open issues.
— — Clarity of vision and objective provided common coherent criteria for rapid resolution and
appreciation.
© ISO/IEC 2024 2025, © IEEE 2025 – All rights reserved
12 © IEEE 2024 – All rights reserved

ISO/IEC/IEEE DISFDIS 24748-10:2025(en)
— — Common-mission teaming
— — Contract and program personnel were on equal footing as team members and expected to
interact family-like.
— — Team meetings were open with taxpayer and user stories of empathetic needs.
— — Shared-knowledge management
— — An interactive real-time knowledge base orchestrated the interaction of all project
participants.
— — A collective consciousness emerged, sensitive to in-the-moment activity coherence and
conflict.
— — Continual integration and test
— — Fully operational integrated test platforms were fitted with evolving on-board, data gathering.
— — Work-in-process and finished work was installed on operational vehicles to reveal integration
challenges.
— — Being agile
— — Leadership and culture placed highest value on full team, in-the-moment, situational
awareness.
— — Engagement culture, collective consciousness, and a customer or user conscience
choreographed the team.
A.3 Adaptable modular architectures
A modular open architecture was developed as a key enabler for sustaining the agile process capability, which
depended upon the ability to easily replace and upgrade individual system components in successive
evolutionary waves. The architecture was planned and evolved before each SE wave began, under the
principle that architectural refactoring incurs time and cost that should be avoided.
Project objectives included modular, reconfigurable executable mission modules, with the government
retaining design, control, and ownership of the product architecture to ensure that developed components
conformed to this architectural standard.
The wave-model process used a modular task architecture, providing structure and flexibility to accommodate
multiple-sponsor diverse organizational and programmatic issues, and lower costs to all sponsors allowing
re-use of product modules across projects.
A.4 Iterative incremental development
The wave-model process offered meaningful progress feedback in project-appropriate six-month cycles. This
was long enough to accommodate new-capability development time, and short enough to demonstrate
frequent progress to sponsors, allow learning, affordable re-planning and corrective action.
Within the six-month increments, development contractors were encouraged and expected to bring work-in-
progress iterations in for occasional and informal integrated testing.
© ISO/IEC 2025, © IEEE 2025 – All rights reserved
ISO/IEC/IEEE DIS FDIS 24748-10:2024(E2025(en)
A.5 Attentive situational awareness
A formal experimentation and test plan was structured to accumulate evidentiary information for feedback
into the development cycle, and ensured critical capability objectives and functional requirements were being
met.
User workshops were held at the end of every wave that included project engineers, contract developers, and
marines from different units with different needs. These workshops explained the technology, responded to
survey questions, and conducted table-top exercises on different types of missions that revealed tactical
operational procedures not anticipated by the SE team.
Quality of process-engagement was actively monitored for both internal personnel and external developers,
which triggered inquiry if insufficient, and mitigation by removing causes, or personnel replacement. This was
subjectively measured by frequency and quality of communications, wiki-contributions, and meeting
contributions.
A risk burndown approach was used to focus on progressive and continuous timely reduction of project risk.
Burndown of risks was monitored in a series of technical reviews and test events analysing evidentiary
information.
A.6 Attentive decision
...