ISO / IEC / IEEE 15288 — System lifecycle
Understand the common system lifecycle process framework and use it to organise disciplined work from stakeholder needs through operation, maintenance and disposal.
After this module, you should be able to:
- Describe the purpose of a lifecycle process framework
- Distinguish agreement, organisational, technical-management and technical processes
- Tailor processes to product context and risk
- Connect lifecycle information items to real engineering decisions
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-101 and TEA-201. Think about development, production, operation and retirement as one system lifecycle.
15288 provides a process vocabulary, not a single development model.
ISO / IEC / IEEE 15288 defines processes for the lifecycle of human-made systems. It spans acquisition and supply, organisational support, technical management and technical processes from business analysis and stakeholder needs through design, transition, operation, maintenance and disposal.
The processes can be used with iterative, incremental, sequential or hybrid lifecycles. Tailoring selects appropriate outcomes, activities and information items for the system, organisation, risk and contractual context; it should be explicit and justified.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Agreement processes | How are acquisition, supply and acceptance governed? | Agreements, statements of work and acceptance criteria |
| Organisational enablement | Which infrastructure, competence, quality and knowledge are needed? | Organisational plans and resources |
| Technical management | How are planning, decisions, risk, configuration and information controlled? | Management records and baselines |
| Technical processes | How are needs transformed, realised, verified and validated? | Engineering artefacts and results |
| Tailoring | Which outcomes apply and how will they be achieved? | Tailoring record |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Define the system of interest, lifecycle stages, stakeholders and enabling systems
- 2. Select and tailor applicable processes and expected outcomes
- 3. Plan decision, risk, configuration, information and measurement controls
- 4. Transform stakeholder needs into system requirements and architecture
- 5. Integrate, verify, transition and validate the system in its operational context
- 6. Operate, maintain and dispose while feeding experience into change
Worked application: industrial monitoring platform
The system includes sensors, gateways, cloud services, installer tools and support operations. Lifecycle planning exposes needs for device identity, calibration, fleet updates, spare parts and data migration. These become architecture and verification concerns rather than surprises after product launch.
Build evidence that explains the reasoning.
Stages, decision points, feedback and release concept.
Applicable processes, outcomes and rationale.
Users, operators, maintainers and acquirers.
Functions, interfaces, enabling systems and allocations.
Risk, decisions, configuration and information control.
Deployment, operation, maintenance and disposal readiness.
Common failure patterns
Processes are treated as a mandated one-pass sequence.
Titles are matched while outcomes remain unachieved.
Manufacturing, service and operational systems are omitted.
Activities disappear without risk-based rationale.
Choose lifecycle outcomes before choosing a delivery model
ISO / IEC / IEEE 15288 provides system lifecycle process descriptions. Its scope includes conception, development, production, use, support and retirement, and it can be applied iteratively, concurrently and recursively. It does not prescribe one development methodology or a mandatory sequence of document templates.
Use that flexibility to organise work around outcomes. An iterative team can refine requirements and architecture while retaining configuration and decision control. A staged programme can still need repeated integration and feedback. The process vocabulary should help explain responsibility and evidence rather than force a diagram that does not match real work.
For an embedded product, include enabling systems: manufacturing equipment, service tools, training, installation and update infrastructure. They may sit outside the delivered device but determine whether it can be produced, operated and supported successfully.
Tailor deliberately and connect technical management
Tailoring should retain a rationale for the selected scope and treatment of process outcomes. It is not a retroactive explanation for missing work. Consider product complexity, risk, supply relationships and external commitments, then define roles, activities and evidence in the project’s own process structure.
Requirements, architecture, integration, verification and validation need support from decision management, risk management, configuration management and information management. If versions are ambiguous, a good test cannot establish which product was verified. If an assumption is unowned, a trade study cannot ensure its future validity.
Keep verification and validation distinct. Verification asks whether the realised system meets specified requirements; validation asks whether it fulfils the intended use and stakeholder needs in context. Both can occur at several levels and stages.
| Lifecycle concern | Embedded example |
|---|---|
| Acquisition and supply | Supplier deliverables, acceptance evidence and change notification. |
| Technical definition | Behaviour, interfaces, architecture and implementation constraints. |
| Realisation | Integration sequence, verification and validation. |
| Technical management | Decisions, risks, baselines, information and measurement. |
| Support and retirement | Service capability, update support, data and energy disposition. |
Use recursive thinking without losing the whole product
A subsystem can have its own requirements, architecture and verification, but its acceptance must support the parent system’s behaviour. Allocate responsibilities downwards and reconcile evidence upwards. A subsystem pass cannot compensate for an incorrect system interface assumption.
Review lifecycle transitions as hand-offs. Production needs a reproducible configuration and acceptance criteria; service needs identification and recovery capability; retirement needs a defined end state. Make those needs visible early so architectural choices do not make them impractical.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Plan the transition from prototype to supported product
A controller prototype performs its main function, but there is no controlled build, production calibration process or field update procedure.
- Identify the missing lifecycle outcomes and enabling systems.
- Assign accountable owners and a useful evidence-based gate.
- Explain how an iterative programme can close the gaps without inventing a separate waterfall project.
Show the worked answer
The gaps concern configuration and reproducibility, production realisation and acceptance, and support capability. Identify build and release infrastructure, calibration fixtures and records, update distribution and service procedures as enabling systems. Define owners across engineering, production, quality and service.
Create integrated increments: reproduce a candidate release, calibrate representative units using the intended process, and demonstrate an interrupted update with recovery. Use the results to refine requirements and architecture. The gate should establish a known product configuration with usable production and support evidence; it should not be based solely on whether a set of document titles exists.
Review criteria
- The lifecycle includes production and support.
- Enabling systems and owners are identified.
- The gate measures demonstrated outcomes.
Check your understanding
Does 15288 require a waterfall model?
No. The process framework can be applied iteratively and concurrently; the chosen lifecycle model must support the needed outcomes.
Why include enabling systems?
A device’s success depends on how it is built, installed, operated and maintained, even when those supporting systems are not delivered inside it.
Further learning
- ISO / IEC / IEEE 15288:2023Official ISO entry for system lifecycle processes.
- TEA-101 · Embedded systems architectureSystem boundaries, allocations, interfaces and decisions.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.