ISO/IEC/IEEE 15288: ISO/IEC/IEEE 15288 – Tutorial (about 60 minutes)

ISO/IEC/IEEE 15288 is the international standard that describes the processes an organisation uses to conceive, develop, produce, operate, support and finally retire a system: anything from a medical device or a train control system to a satellite, a factory line or a city's payment network. Systems engineers, project and programme managers, acquirers and suppliers, quality and safety specialists and process improvement teams use it as a shared vocabulary and a reference set of 30 processes. After this tutorial you will be able to explain what the standard covers and why it exists, find your way around its four process groups, tailor it for a real project, describe how conformance is claimed and assessed, and relate it to neighbouring standards such as ISO/IEC/IEEE 12207 and ISO 26262.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current edition is ISO/IEC/IEEE 15288:2023, Systems and software engineering – System life cycle processes, published in May 2023 as the second edition under the joint ISO/IEC/IEEE designation. It was prepared by ISO/IEC JTC 1/SC 7 (Software and systems engineering) together with the IEEE Computer Society's Systems and Software Engineering Standards Committee; IEEE approved it on 2023-03-30 and lists it as an active standard (IEEE/ISO/IEC 15288-2023). It cancels and replaces ISO/IEC/IEEE 15288:2015, which itself followed the ISO/IEC editions of 2002 and 2008. We found no newer edition, amendment or published revision of 15288. Several national bodies have adopted the 2023 text under their own numbers (some carry later years, such as a 2026 national adoption in Slovenia, but they reproduce the 2023 content). Be aware that the companion software standard ISO/IEC/IEEE 12207 was revised in 2026, so small wording differences between the two may appear until 15288 is next revised. Verified 2026-10-29 against the ISO catalogue entry, the IEEE SA record for 15288-2023 and the publisher's preview of the 2023 front matter.

Who it is for: engineers who are moving into systems engineering roles, project and programme managers on complex technical projects, people who write or evaluate contracts for engineered systems, quality, safety and process improvement staff, and anyone in automotive, rail, aerospace, defence, energy or medical technology who keeps hearing "our process is based on 15288" and wants to know what that really means.

Prerequisites: none. It helps if you have worked on, or near, a project that builds something with hardware, software and people in it, but every term is explained when it first appears.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why ISO/IEC/IEEE 15288 exists, what it covers and what it deliberately leaves out.
You will be able to define the core vocabulary: system of interest, system element, enabling system, stakeholder, life cycle stage, process, outcome, activity and task.
You will be able to name the four process groups and place each of the 30 processes in the right group.
You will be able to describe how processes are applied across life cycle stages, including iteration, recursion and concurrency.
You will be able to tailor the process set for a project and record the reasons in a way an assessor or customer would accept.
You will be able to distinguish the three ways of claiming conformance and explain how process assessment relates to the standard.
You will be able to relate 15288 to ISO/IEC/IEEE 12207, the 24748 guidance series, ISO/IEC TS 33060 and domain safety standards.

Lesson 1 – Origins, purpose and scope

Why a systems life cycle standard?

Modern products are rarely just hardware or just software. An electric bus contains batteries, power electronics, embedded software, a cloud connection, a driver, a maintenance crew, a depot and a timetable. When dozens of companies and hundreds of engineers work on something like that, they need a common way of describing the work: who defines the needs, who turns them into requirements, how the parts are integrated, how anyone knows the result is right, and what happens when the thing is finally scrapped. Without a common description, each company invents its own words, contracts become arguments about vocabulary, and important work (often verification, transition into service or disposal) falls into the gaps between organisations.

ISO/IEC/IEEE 15288 answers that need. It does not tell you how to design a bus or a radar. Instead, it gives a catalogue of processes that any organisation building or acquiring a system can draw on, with a clear statement of what each process is for and what it should achieve. Because the catalogue is international and widely adopted, an acquirer in one country and a supplier in another can agree "we will perform the verification process as described in 15288, tailored as follows" and both sides know what is meant.

A short history

Work on the standard started in the mid-1990s inside ISO/IEC JTC 1/SC 7, the committee that also looks after software engineering standards. The International Council on Systems Engineering (INCOSE), the main professional body for systems engineers, has followed the standard closely ever since; its Systems Engineering Handbook is aligned with it. The first edition, ISO/IEC 15288, appeared in 2002. The 2008 revision aligned it closely with the software life cycle standard ISO/IEC 12207, so that the two shared a common process model. In 2015 the standard became a joint publication of ISO, IEC and IEEE, which is why its name now carries all three acronyms; because of the change of designation, the 2015 text counts as the first edition of ISO/IEC/IEEE 15288 and the 2023 text as the second.

The 2023 revision kept the same four groups and 30 processes but improved several of them. The publisher's foreword lists improvements to business or mission analysis, system architecture definition, system analysis, implementation, integration, operation and maintenance; better risk management and configuration management; a much expanded Clause 5 on key concepts (iteration, recursion, systems of systems, quality characteristics, and new material on concept and system definition); updated terms and definitions; and a new informative annex on model-based systems and software engineering. The wording also changed from "man-made systems" to "systems created by humans".

What the standard covers

In its own words, it establishes "a common framework of process descriptions for describing the life cycle of systems created by humans" (ISO/IEC/IEEE 15288:2023, Clause 1). Several points about the scope deserve attention:

It covers the full life cycle: conception, development, production, utilisation, support and retirement, plus the acquisition and supply of systems, whether inside one organisation or between organisations.
A system may be made of hardware, software, data, people, processes, services, procedures, facilities, materials and naturally occurring entities. The standard is not limited to physical products.
It applies to one-of-a-kind systems, mass-produced systems and configurable systems, and to stand-alone systems as well as systems embedded in larger ones.
Processes can be applied iteratively, concurrently and recursively down the system structure.

What it deliberately leaves out

Equally important is what 15288 does not do. It does not prescribe a life cycle model (waterfall, V-model, spiral, incremental or agile), a development method, a modelling language or a tool. It also does not specify document names, formats or content: that job belongs to ISO/IEC/IEEE 15289, which describes the content of life cycle information items. Finally, it is not a management system standard like ISO 9001; the introduction explains that it is designed to be compatible with quality, service, IT asset and information security management systems, but it does not itself set up such a system.

Four ways to use it

The standard describes four intended ways of using it, and recognising which one you are in clarifies most discussions:

By an organisation, to set up a standard set of processes, supported by methods, tools and trained staff, that its projects then use.
By a project, to select and apply the parts of that organisational environment it needs to deliver a product or service.
By an acquirer and a supplier, to agree which processes and activities will be performed under a contract.
By process assessors, as a process reference model against which an assessment of process capability can be carried out.

Lesson 2 – Key concepts and vocabulary

Most confusion about 15288 comes from words that sound ordinary but have a precise meaning. The terms below are explained in our own words; the standard's formal definitions live in its Clause 3 and in the ISO/IEC/IEEE 24765 vocabulary.

System – a set of parts that work together, in an organised way, to serve one or more declared purposes. The point is interaction: a pile of parts is not a system until they work together.
System of interest – the system whose life cycle you are currently considering. Saying "system of interest" makes it clear which level you mean, because every system is part of something bigger and contains something smaller.
System element – a member of the set of parts that make up a system. An element may itself be treated as a system of interest one level down, which is how the standard handles very large systems.
Enabling system – a system that supports the system of interest during a stage of its life but is not part of it while it operates: a test rig, a production line, a training simulator, a software build pipeline, a disposal facility.
Interfacing and interoperating systems – systems outside the system of interest that exchange information, energy or material with it, or work with it to deliver a capability (for example, the power grid that a charging station connects to).
System of systems (SoS) – a set of systems that together deliver a capability none could deliver alone, where the constituent systems keep their own managerial and operational independence. An air traffic network is a classic example.
Stakeholder – any person, group or organisation that has a legitimate stake in the system or is affected by it: users, operators, owners, maintainers, regulators, neighbours, investors.
Life cycle – the whole story of a system as it changes over time, from the first idea until it is taken out of service. A life cycle model is a framework of stages and their relationships that an organisation or project adopts.
Stage – a period within the life cycle with its own purpose and exit criteria, such as concept, development or production. A decision gate is a point at which the stakeholders decide whether to move to the next stage.
Process – a collection of related activities that take something in (information, materials, requests) and turn it into a result. In 15288 every process is described by its purpose (why it exists), its outcomes (observable results of performing it successfully), its activities (groups of related work) and its tasks (the individual actions).
Information item – a separately identifiable body of information produced or used by a process, such as a plan, a specification or a report. The 2023 edition speaks of artefacts and information items together; their content is the subject of ISO/IEC/IEEE 15289.
Acquirer and supplier – the party that obtains a product or service and the party that provides it. The same company can be an acquirer for one element and a supplier for the overall system.
Verification – confirmation, with objective evidence, that a system or element meets its specified requirements ("did we build it right?").
Validation – confirmation, with objective evidence, that the system fulfils its intended use in its intended environment and satisfies stakeholder needs ("did we build the right thing?").
Tailoring – adapting the processes of the standard to the circumstances of an organisation or project, by deleting or modifying outcomes, activities or tasks and recording why.
Baseline – a formally agreed version of a configuration item (requirements, design, software, hardware) that can only be changed through controlled change procedures.

The system structure

Figure 1 shows how these words fit together. The system of interest is broken down into elements, some of which are big enough to be treated as subsystems with their own elements. Around it sit the enabling systems needed during its life and the interfacing systems it works with in operation. Applying the same processes at each level of the breakdown is called recursion, and you will meet it again in Lesson 4.

Figure 1 – A system of interest is decomposed into subsystems and elements, supported by enabling systems and connected to interfacing systems.

Why the vocabulary matters

Two habits help beginners. First, always name the system of interest before discussing requirements or tests; many disagreements disappear when people realise one is talking about the whole train and the other about the door controller. Second, distinguish carefully between stages (periods of the system's life) and processes (kinds of work). Requirements work does not happen only in a "requirements stage"; it continues whenever a change arrives, even during operation. Keeping stages and processes separate is one of the main ideas of the standard.

Lesson 3 – Structure of the standard

The clauses

The 2023 edition is organised as follows (titles paraphrased where helpful):

Clause 1 Scope and Clause 2 Normative references (there are none).
Clause 3 Terms, definitions and abbreviated terms.
Clause 4 Conformance: intended usage, full conformance (to outcomes or to tasks) and tailored conformance. This clause is the subject of Lesson 5.
Clause 5 Key concepts and their application: system concepts (structure, enabling and interfacing systems, solution context, product line engineering), organisational concepts, system of systems concepts, life cycle concepts, process concepts, an overview of the processes, process application (iteration, recursion, concurrency, process views), concept and system definition, assurance and quality characteristics, and the process reference model.
Clause 6 System life cycle processes: the detailed descriptions of all 30 processes, arranged in four groups (6.1 to 6.4).
Annex A (normative): the tailoring process.
Annex B (informative): example process artefacts and information items.
Annex C (informative): the process reference model for assessment purposes.
Annex D (informative): model-based systems and software engineering (MBSSE), new in 2023.

Clause 5 is the part beginners most often skip and most need. It explains the thinking behind the process set; Clause 6 is closer to a reference manual that you consult process by process.

The four process groups

The 30 processes fall into four groups, shown in Figure 2. The grouping is about the kind of concern each process addresses, not about time.

Figure 2 – The 30 processes of ISO/IEC/IEEE 15288 fall into four groups according to the kind of concern they address.

Group	What it is about	Processes (Clause 6)
Agreement (6.1)	Establishing and running agreements between an acquirer and a supplier, inside or between organisations.	Acquisition; Supply
Organizational project-enabling (6.2)	Giving projects the capability they need: defined life cycle models, infrastructure, funded and prioritised projects, skilled people, quality policy and reusable knowledge.	Life cycle model management; Infrastructure management; Portfolio management; Human resource management; Quality management; Knowledge management
Technical management (6.3)	Managing the technical effort of a project: plans, progress, decisions, risks, configurations, information, measures and assurance of conformance.	Project planning; Project assessment and control; Decision management; Risk management; Configuration management; Information management; Measurement; Quality assurance
Technical (6.4)	Defining, realising, using, sustaining and retiring the system itself.	Business or mission analysis; Stakeholder needs and requirements definition; System requirements definition; System architecture definition; Design definition; System analysis; Implementation; Integration; Verification; Transition; Validation; Operation; Maintenance; Disposal

Two points often surprise newcomers. Quality appears twice: quality management is an organisation-level process that sets quality policy and objectives, while quality assurance is a project-level process that checks that the project's processes and products conform. And there is no separate "test" process: testing is one method used inside verification and validation, alongside inspection, analysis and demonstration.

How each process is written

Every process description in Clause 6 follows the same pattern, which makes the standard easy to navigate once you know it:

A purpose statement: one or two sentences saying why the process exists.
A list of outcomes: the observable results that show the process has achieved its purpose. For example, a risk process has achieved its purpose when, among other things, risks are identified and analysed, treatments are selected and the risks are monitored.
A set of activities, each broken down into tasks, with notes giving guidance.

The separation between outcomes and tasks is the key to conformance (Lesson 5). Outcomes say what must be true; tasks say what work is normally done. An organisation can achieve the outcomes in its own way, or commit to performing the tasks as written.

A shared model with 12207

The introduction explains that there is a continuum from systems with little or no software to systems where software is the main interest. 15288 and ISO/IEC/IEEE 12207 (software life cycle processes) share the same process model, most activities and tasks, and differ mainly in the notes. When software is the predominant element, 12207 is the better fit; when the system mixes many kinds of elements, 15288 is. Many organisations use 15288 at system level and 12207 for each software element.

Lesson 4 – How it works in practice

Stages and gates

A life cycle model divides the life of a system into stages. The standard does not impose a particular set, but its companion guidance ISO/IEC/IEEE 24748-1 describes a widely used example: concept, development, production, utilisation, support and retirement. Each stage has a purpose and exit criteria, and at the end of each one a decision gate decides whether to proceed, to repeat work, to hold, or to stop. Figure 3 shows the idea. Utilisation and support usually run in parallel: while the system is in service it is also maintained.

Figure 3 – An example life cycle model: stages separated by decision gates, with paths for rework, upgrade and retirement.

The crucial idea is that processes are not stages. In the concept stage you already perform risk management, decision management, stakeholder needs definition, early architecture work and even some verification planning. During utilisation you still perform configuration management, maintenance, measurement and, when changes are requested, requirements and design work. A useful way to picture this is a grid: stages across the top, processes down the side, and in each cell the intensity with which that process is used in that stage.

The technical processes as a chain of reasoning

The 14 technical processes form a logical chain from problem to retirement, shown in Figure 4. It is a chain of dependencies, not a strict sequence in time.

Figure 4 – The technical processes form a chain from defining the problem to realising, delivering, using and disposing of the system, with system analysis feeding decisions throughout.

Business or mission analysis defines the problem or opportunity, the business or mission context and the solution space, before anyone writes a requirement.
Stakeholder needs and requirements definition finds the stakeholders, captures their needs, concerns and constraints, and expresses them as stakeholder requirements, often through operational scenarios.
System requirements definition turns those into a technical, verifiable description of what the system must do and how well, without fixing the design.
System architecture definition creates and evaluates alternative architectures, selects one and describes it with views that address stakeholders' concerns.
Design definition provides enough detail about each element for it to be implemented or bought.
System analysis supplies the quantitative and qualitative analysis (performance, cost, reliability, safety, trade-offs) that the other processes need to make decisions.
Implementation realises an element: building hardware, coding software, buying a commercial component, training an operator.
Integration assembles elements step by step into the system, managing interfaces.
Verification provides objective evidence that the system or element meets its specified requirements and characteristics.
Transition moves the system into its operational environment: installation, commissioning, training and handover.
Validation provides objective evidence that the system meets its intended use and stakeholders' needs in the real environment.
Operation uses the system to deliver its services, and maintenance keeps it able to do so, including corrective, preventive and adaptive work and logistics.
Disposal ends the system's existence or removes an element, dealing with materials, data and environmental and safety obligations.

Iteration, recursion and concurrency

Clause 5 describes three ways processes interact in real projects. Iteration means repeating a process, or a group of processes, on the same system to refine the result, for example cycling between requirements and architecture until they are consistent. Recursion means applying the same processes at successive levels of the system structure: the outcome of architecture at one level becomes the requirements input for each element at the next level down. Concurrency means that several processes run at the same time, such as verification planning in parallel with requirements definition. A project that only runs each process once, in sequence, is not following the spirit of the standard.

Roles and artefacts

15288 assigns processes, not job titles. In practice the technical processes are led by systems engineers and architects, the technical management processes by project managers, configuration and quality staff, and the organisational processes by functions such as engineering process groups, human resources and portfolio boards. Agreement processes involve procurement, contracts and the engineering leads on both sides. Typical information items include a systems engineering management plan, a concept of operations, stakeholder and system requirements specifications, architecture descriptions, interface definitions, verification and validation plans and reports, a configuration management plan, a risk register and a disposal plan. Annex B gives examples; ISO/IEC/IEEE 15289 describes their content. Teams that work in model-based tools may hold much of this information as a model rather than documents, which is what the new Annex D on MBSSE addresses.

Implementation steps for an organisation

Organisations that adopt the standard usually follow a sequence like this:

Decide the mode of use and the scope: which business units, product lines and system types.
Map current processes to the 30 processes and their outcomes to find gaps and overlaps.
Define one or more organisational life cycle models (for example, a gated model for safety-related products and a lighter incremental model for services).
Write or adapt organisational procedures, templates and tools so that each selected process has an owner, guidance and records.
Train people, starting with project managers and systems engineers.
Pilot on real projects, tailor, and collect lessons learned through the knowledge management process.
Measure and improve, possibly using a formal process assessment.

Tailoring

No project should run all 30 processes at full depth. Annex A, which is normative, describes a tailoring process: identify the circumstances that influence tailoring (such as stability of the environment, risks, novelty, size, safety and security criticality, contractual and regulatory demands); take account of life cycle structures required by other standards or regulations; get input from the parties affected; decide which processes, outcomes, activities or tasks to adapt or delete; and record the decisions and the rationale. The rationale is what turns tailoring from "skipping work" into an engineering decision that an assessor or customer can examine.

Agile and model-based work

Because the standard is method-neutral, it can be applied with agile delivery. Iteration and concurrency are built into the process concepts; the life cycle model can define short increments; and outcomes such as "the system is verified against its requirements" can be achieved through automated tests in each iteration rather than a single test phase at the end. What agile teams must still show is that the outcomes are achieved, for example that requirements, configurations and decisions are traceable, even if the evidence lives in a backlog tool and a pipeline rather than in documents.

Lesson 5 – Assessment, certification and compliance

No certificate for 15288 itself

Unlike ISO 9001 or ISO/IEC 27001, ISO/IEC/IEEE 15288 is not a management system standard and has no accredited certification scheme for organisations. You will not find a "15288 certified company" in the sense of an accredited certificate on the wall. Instead, an organisation or project claims conformance, and that claim may be checked by a customer, a regulator, an internal audit or a process assessment. Some professional bodies certify individual systems engineers (INCOSE's certification programme is the best known), but that certifies a person's knowledge and experience, not an organisation's processes.

The three conformance options

Clause 4 sets out how a claim is made. It starts from intended usage: a claim always refers to a declared set of processes, because few organisations perform all 30. Then there are three kinds of claim, shown in Figure 5:

Full conformance to outcomes: you show that all the outcomes of each declared process are achieved. You are free to use your own activities and methods. This suits organisations with mature processes of their own and is the usual basis for process assessment.
Full conformance to tasks: you show that all the required tasks of each declared process are performed. This is more prescriptive and suits contracts where the acquirer wants visibility of the work itself.
Tailored conformance: when the processes have been tailored using Annex A, you show that the outcomes or tasks as tailored are achieved, and you make the tailoring decisions and their rationale available.

Figure 5 – Choosing a conformance claim: declare the process set, then claim full conformance to outcomes or tasks, or tailored conformance backed by recorded rationale.

Who checks the claim

In practice conformance is checked in three settings. First-party checks are internal audits or quality assurance reviews of the organisation's own projects. Second-party checks happen when an acquirer audits a supplier against what the contract requires; the contract will typically reference 15288 processes and may attach a tailoring. Third-party evaluation comes from an independent process assessment or from a regulator in a domain whose safety standard expects a defined life cycle.

Process assessment

Annex C presents the 15288 processes as a process reference model: a set of processes defined by purpose and outcomes that can be used for assessment. A full assessment also needs a process assessment model, which adds indicators such as base practices and work products, and a measurement framework. For system life cycle processes this role is filled by ISO/IEC TS 33060 (first published in 2020, succeeding the earlier technical report ISO/IEC TR 15504-6). Assessments are carried out according to the requirements of ISO/IEC 33002, and capability is typically rated with the ISO/IEC 33020 framework on six levels: 0 incomplete, 1 performed, 2 managed, 3 established, 4 predictable and 5 innovating. The result is a capability profile per process, not a pass or fail certificate.

What evidence looks like

Whoever checks a claim will want to see records, not intentions. Typical evidence includes the organisation's documented life cycle models and procedures; the project's tailoring record; plans and their approval; requirements with traceability to architecture, design and verification; configuration baselines and change records; risk registers with treatment history; review and decision records at gates; verification and validation reports; and measurement data. A useful rule of thumb is that each outcome you claim should be backed by something an outsider can read.

Regulated domains

In safety-critical and regulated industries, 15288 is rarely the only requirement. Automotive suppliers work under ISO 26262 (functional safety) and are assessed with Automotive SPICE; rail follows the EN 5012x series; aerospace follows its own guidance for airborne systems. These documents prescribe specific work for safety or quality. 15288 provides the overall process framework into which those specific requirements are inserted, and many organisations use it to structure their process handbook so that one set of processes satisfies several domain standards at once.

Lesson 6 – Worked example

To tie the lessons together, follow a fictional mid-sized company, Voltara Systems, which designs and installs depot charging systems for electric buses. A city transit operator has invited bids for a turnkey system to charge 120 buses overnight at a new depot, with a 15-year service contract. Voltara decides to base its project process on ISO/IEC/IEEE 15288:2023.

Step 1 – Agreement

The operator is the acquirer and runs the acquisition process: it prepares the request, evaluates bids and selects a supplier. Voltara runs the supply process: it reviews the request, prepares a response and, once selected, negotiates the agreement. Both sides agree in the contract which 15288 processes Voltara will perform, which information items it will deliver (for example a systems engineering management plan, an architecture description, and verification and validation reports), and the decision gates at which the operator will take part. Voltara also acts as an acquirer for some elements: it buys power transformers and charging dispensers from suppliers, and flows down matching agreement terms.

Step 2 – Organisational foundations

Voltara's engineering process group owns life cycle model management. It offers two models: a gated model for products with safety-related functions, and an incremental model for software services. This project uses the gated model, with stages for concept, development, production and installation, utilisation and support, and retirement. Infrastructure management provides the requirements tool, a hardware test bay and a software pipeline; human resource management confirms there are enough high-voltage engineers; portfolio management approves the project and its funding; knowledge management supplies lessons learned from an earlier depot project.

Step 3 – Planning and tailoring

The project manager runs project planning and applies the Annex A tailoring process. Circumstances that influence the tailoring include high-voltage safety risks, grid connection rules, a fixed deadline before the operator's new bus fleet arrives, and moderate novelty (the dispenser is new, the rest is familiar). The team keeps all 14 technical processes, strengthens risk management and verification because of the safety risks, and reduces disposal at this stage to a disposal concept, with a full disposal plan to be produced during utilisation. Each decision is recorded with its reason in the tailoring record attached to the systems engineering management plan.

Step 4 – Defining the problem and the solution

Business or mission analysis confirms the real problem: buses must leave the depot fully charged at 05:00 every day without overloading the local grid. Stakeholder needs and requirements definition identifies stakeholders beyond the obvious ones: depot staff who plug in buses, maintenance technicians, the grid operator, the fire service, neighbours worried about noise, and the city's sustainability office. Operational scenarios are written for a normal night, a night with three dispensers out of service and a grid emergency. System requirements definition turns these into measurable requirements, such as maximum depot peak demand, charging completion times and alarm response times.

System architecture definition compares three alternatives: one large central charger with distributed dispensers, standalone chargers per bay, and a hybrid with battery storage. System analysis models the grid load, lifetime cost and availability for each, and decision management records the choice of the hybrid architecture with the analysis that supports it. The architecture is described in views for the operator (operations), the grid operator (electrical connection) and the maintainers (access and replaceable units).

Step 5 – Recursion down the structure

The system of interest is the whole depot charging system. Its elements include the grid connection, the battery storage subsystem, 60 dispensers, a charge management software platform and the operating procedures. Voltara applies the same processes again to the charge management software: the system architecture provides its requirements, and the software team, following ISO/IEC/IEEE 12207 practices, defines its own architecture, implementation and verification. The dispensers come from a supplier, so for that element "implementation" means acquiring and accepting a commercial product against a specification.

Step 6 – Managing the technical effort

Throughout, project assessment and control compares progress with the plan at monthly reviews. Risk management tracks risks such as late grid connection approval and transformer lead times, with treatments and owners. Configuration management establishes baselines for the requirements, architecture and software, and every change goes through a change board that includes the operator for changes affecting the contract. Information management decides where each information item lives and who may see it. Measurement tracks requirements volatility, defect trends and test coverage. Quality assurance runs independent checks that the project actually follows its tailored processes.

Step 7 – Realisation, verification and handover

Integration proceeds in steps: dispensers with the charge management software in the test bay, then a single bay on site, then the full depot. Verification uses inspection (cable routing), analysis (thermal calculations), demonstration (operator screens) and testing (charging profiles), and every system requirement is traced to at least one verification result. Transition covers installation, commissioning with the grid operator, training of depot staff and the handover documentation. Validation then runs the system for four weeks with real buses and shifts, showing that buses are ready at 05:00 and that staff can handle the scenario with dispensers out of service.

Step 8 – Operation, maintenance and retirement

Under the service contract Voltara supports the operator's operation process and performs maintenance: remote monitoring, preventive inspections, spare parts and software updates, each controlled by configuration management. In year three it produces the full disposal plan, covering recycling of battery modules, secure erasure of operational data and removal of high-voltage equipment, so that disposal is ready long before it is needed.

Step 9 – Claiming conformance

Voltara declares in the contract that it performs the agreed set of processes with tailored conformance, and provides the tailoring record. The operator's quality team performs a second-party audit at the development gate, sampling traceability from stakeholder needs to verification results and checking the risk and change records. Later, Voltara commissions an internal process assessment against ISO/IEC TS 33060 to find where its organisational processes should improve before the next bid. No certificate is issued; what Voltara gains is evidence it can show to future customers and a clear improvement plan.

Lesson 7 – Relationship to other standards and frameworks

15288 sits at the centre of a family of systems and software engineering standards, and it is often combined with domain-specific requirements. The table summarises the most important relationships.

Standard or framework	Focus	Relationship to 15288
ISO/IEC/IEEE 12207 (software life cycle processes; revised 2026)	Processes for software systems and software elements	Same process model and largely shared activities; used when software is the main interest or for software elements inside a 15288 system.
ISO/IEC/IEEE 24748-1 (life cycle management guidelines, 2024 edition)	Life cycle concepts, stages and adaptation of life cycle models	Explains how to build life cycle models from the processes; the source of the commonly used stage set.
ISO/IEC/IEEE 24748-2 (guidelines for applying 15288)	Practical guidance on using 15288	A companion guide; it adds explanation but no new requirements.
ISO/IEC/IEEE 15289	Content of life cycle information items (documentation)	Fills the gap 15288 leaves on document content and format.
ISO/IEC/IEEE 29148 and ISO/IEC/IEEE 42010	Requirements engineering; architecture description	Give detailed practices for the requirements and architecture processes of 15288.
ISO/IEC TS 33060 with ISO/IEC 33002 and 33020	Process assessment model and assessment requirements	Turn the 15288 process reference model into an assessable model with capability levels.
ISO 26262, IEC 61508 and other domain safety standards	Functional safety requirements for specific domains	Prescribe safety work that is inserted into, and tailored with, the 15288 processes.
ISO 9001	Quality management system requirements, certifiable	15288 is designed to be compatible with it; its quality management and quality assurance processes help meet ISO 9001 at project level.
INCOSE Systems Engineering Handbook (5th edition, 2023)	Practitioner guide to systems engineering	Elaborates the 15288:2023 processes with methods and examples; not a standard itself.

How to read these relationships

Think of three layers. At the top, 15288 and 12207 define what processes exist and what they should achieve. In the middle, guidance standards (24748, 29148, 42010, 15289) and handbooks explain how to perform particular processes well. Alongside, domain standards such as ISO 26262 add extra obligations for safety, security or regulatory reasons, and assessment standards such as ISO/IEC TS 33060 measure how capable the processes are. A good process handbook uses 15288 as its spine and attaches the other requirements to the relevant processes, so that people do not maintain several parallel process descriptions.

There is also a specialised companion for systems of systems, ISO/IEC/IEEE 21840, which gives guidance on using 15288 when the system of interest is a set of independent systems. And in the defence sector, IEEE has published standards that apply 15288 to defence programmes, illustrating how sectors build on the general framework rather than replacing it.

Common pitfalls and best practices

Pitfalls seen in real adoptions:

Treating processes as stages. Teams draw a waterfall with 14 boxes and assume each technical process happens once, in order. The standard expects iteration, recursion and concurrency; requirements, risk and configuration work continue for the whole life of the system.
Tailoring without rationale. Deleting processes because they seem expensive, without recording why, turns tailoring into omission and fails any serious review.
Producing documents instead of outcomes. Organisations write templates for every information item and measure success by document count. Assessors and customers look for evidence that outcomes are achieved, such as working traceability and acted-on risks.
Forgetting the organisational processes. Projects try to conform on their own, but without life cycle model management, infrastructure and competent people provided by the organisation, each project reinvents its process.
Ignoring transition and disposal. Handover, training and end-of-life obligations are left to the end, causing late surprises, environmental liabilities and unhappy operators.
Claiming "certified to 15288". There is no accredited organisational certification; such claims mislead customers and undermine credibility.

Best practices that work:

Start from outcomes. For each selected process, ask what observable result shows it is working, and design the lightest practice that produces it.
Name the system of interest at every level. State it on every plan, requirement set and test report, and apply the processes recursively.
Make tailoring a recorded engineering decision. Use Annex A, involve the affected parties and keep the rationale with the plan.
Use one process spine. Map domain standards (safety, security, quality) onto the 15288 processes instead of keeping separate handbooks.
Plan verification and validation early. Write how each requirement will be verified at the time the requirement is written, and involve real users in validation scenarios from the concept stage.
Measure and improve. Use the measurement and knowledge management processes, and consider a periodic process assessment to target improvements.

Summary and key takeaways

ISO/IEC/IEEE 15288:2023 is the current edition of the international framework of processes for the life cycle of systems created by humans, published jointly by ISO, IEC and IEEE.
It covers the whole life of a system, from concept through retirement, and the agreements to acquire and supply it, but it does not prescribe a life cycle model, method, tool or document format.
Thirty processes sit in four groups: agreement (2), organizational project-enabling (6), technical management (8) and technical (14).
Each process is described by purpose, outcomes, activities and tasks; outcomes say what must be achieved, tasks describe the usual work.
Processes are not stages: they are applied iteratively, concurrently and recursively throughout the life cycle.
Tailoring under the normative Annex A, with recorded rationale, is expected; conformance is claimed to outcomes, to tasks or as tailored conformance for a declared set of processes.
There is no accredited certification for organisations; conformance is checked by internal audits, customers and process assessments using ISO/IEC TS 33060 and the ISO/IEC 330xx series.
15288 works as the process spine for companion standards (12207, 24748, 15289, 29148, 42010) and for domain safety standards such as ISO 26262.

Reflection questions

Pick a product you have worked on. What was the system of interest, which enabling systems did it need, and at which level would you apply the processes recursively?
Which of the 30 processes does your organisation perform implicitly but never names or records? What evidence would show that its outcomes are achieved?
If you were tailoring the processes for a small, low-risk internal project, which processes or tasks would you reduce, and how would you justify each decision?
Your customer asks for full conformance to tasks while your organisation is used to conforming to outcomes. What would change in planning, records and cost?
How would you combine 15288 with a domain standard you know (for example ISO 26262, ISO 9001 or a security standard) so that your teams follow one set of processes?