ISO/IEC 15288

The ISO/IEC 15288 is a systems engineering standard covering processes and lifecycle stages. Initial planning for the ISO/IEC 15288:2002(E) standard started in 1994 when the need for a common systems engineering process framework was recognized. The previously accepted standard MIL STD 499A (1974) was cancelled after a memo from SECDEF prohibited the use of most United States Military Standards without a waiver. The first edition was issued on 1 November 2002. Stuart Arnold was the editor and Harold Lawson was the architect of the standard.[1] In 2004 this standard was adopted as IEEE 15288. ISO/IEC 15288 has been updated 1 February 2008 as well as on 15 May 2015.[2]

ISO/IEC 15288 is managed by ISO/IEC JTC1/SC7, which is the ISO committee responsible for developing ISO standards in the area of Software and Systems Engineering. ISO/IEC 15288 is part of the SC 7 Integrated set of Standards, and other standards in this domain include:

  • ISO/IEC TR 15504 which addresses capability
  • ISO/IEC 12207 and ISO/IEC 15288 which address lifecycle and
  • ISO 9001 & ISO 9000-3 which address quality


  • ISO/IEC 15288:2015
  • Revises: ISO/IEC 15288:2008 (harmonized with ISO/IEC 12207:2008)
  • Revises: ISO/IEC 15288:2002 (first edition)


The standard defines processes divided into four categories:

  • Technical
  • Project
  • Agreement, and
  • Enterprise

Each process is defined by a purpose, outcomes, and activities. ISO 15288 comprises 25 processes which have 123 outcomes derived from 403 activities.[3]

  1. Clause 6.4.1 - Stakeholder Requirements Definition Process
  2. Clause 6.4.2 - Requirements Analysis Process
  3. Clause 6.4.3 - Architectural Design Process
  4. Clause 6.4.4 - Implementation Process
  5. Clause 6.4.5 - Integration Process
  6. Clause 6.4.6 - Verification Process
  7. Clause 6.4.7 - Transition Process
  8. Clause 6.4.8 - Validation Process
  9. Clause 6.4.9 - Operation Process
  10. Clause 6.4.10 - Maintenance Process
  11. Clause 6.4.11 - Disposal Process

Example life cycle stages described in the document are: concept, development, production, utilisation, support, and retirement. However, these stages are not normative; the standard defines processes, not stages.

See also


  1. ^ Systems Engineering – Guide for ISO/IEC 15288 (System Life Cycle Processes)
  2. ^ ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes
  3. ^ What is ISO/IEC 15288 and Why Should I Care?
  • 15288-2008 - ISO/IEC/IEEE Systems and Software Engineering — System Life Cycle Processes. 2008. doi:10.1109/IEEESTD.2008.4475828. ISBN 978-0-7381-5665-1.
Concept of operations

A concept of operations (abbreviated CONOPS, CONOPs, or ConOps) is a document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system such as a business requirements specification or stakeholder requirements specification (StRS). It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. CONOPS are widely used in the military, governmental services and other fields.

A CONOPS generally evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or end state.The first standard was 1362-1998 - IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document that was superseded by the document 29148-2011 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Life cycle processes --Requirements engineering.

Then came the 2012 AIAA revision proposal Guide: Guide to the Preparation of Operational Concept Documents (ANSI/AIAA G-043A-2012) (Revision of G-043-1992), and today we have ISO/IEC/IEEE 15288:2015 Systems and software engineering -- System life cycle processes.

In the field of joint military operations, a CONOPS in DoD terminology is a verbal or graphic statement that clearly and concisely expresses what the joint force commander intends to accomplish and how it will be done using available resources. CONOPS may also be used or summarized in system acquisition DODAF descriptions such as the OV-1 High Level Operational Concept Graphic.

ISO/IEC 12207

ISO/IEC/IEEE 12207 Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

ISO/IEC 15504

ISO/IEC 15504 Information technology – Process assessment, also termed Software Process Improvement and Capability Determination (SPICE), is a set of technical standards documents for the computer software development process and related business management functions. It is one of the joint International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standards, which was developed by the ISO and IEC joint subcommittee, ISO/IEC JTC 1/SC 7.ISO/IEC 15504 was initially derived from process lifecycle standard ISO/IEC 12207 and from maturity models like Bootstrap, Trillium and the Capability Maturity Model (CMM).

ISO/IEC 15504 has been revised by: ISO/IEC 33001:2015 Information technology – Process assessment – Concepts and terminology as of March, 2015 and is no longer available at ISO.

ISO/IEC 42010

ISO/IEC/IEEE 42010 Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.


ISO/IEC JTC 1/SC 7 Software and systems engineering is a standardization subcommittee of the Joint Technical Committee ISO/IEC JTC 1 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), that develops and facilitates standards within the field of engineering of software products and systems. The international secretariat of ISO/IEC JTC 1/SC 7 is the Bureau of Indian Standards (BIS) located in India.

International Council on Systems Engineering

The International Council on Systems Engineering (INCOSE; pronounced in-co-see) is a not-for-profit membership organization and professional society in the field of Systems engineering. INCOSE has about 17000 members[] including individual members, corporate members and student members. INCOSE's main activities include its conferences, publications, local chapters, certifications and technical working groups.

The INCOSE International Symposium is generally held in July in the United States or another country, and the INCOSE International Workshop is held in January in the United States.

Currently, there are about 70 local INCOSE chapters globally with most chapters outside the United States representing entire countries, while chapters within the United States represent cities or regions.

INCOSE organizes about 50 technical working groups with international membership, aimed at collaboration and the creation of INCOSE products, printed and online, in the field of Systems engineering. Working groups exist for topics within systems engineering practice, systems engineering in particular industries and systems engineering's relationship to other related disciplines.

INCOSE produces two main periodicals: the journal Systems Engineering and the practitioner magazine Insight along with a number of individual published works, including the INCOSE Handbook. In collaboration with the IEEE Computer Society and the Systems Engineering Research Council (SERC), INCOSE produces and maintains the online Systems Engineering Book of Knowledge (SEBoK), a wiki-style reference open to contributions from anyone, but with content controlled and managed by an editorial board.

INCOSE certifies systems engineers through its three-tier certification process. Certification requires a combination of education, years of experience and passing an examination based on the INCOSE Systems Engineering Handbook.

INCOSE is a member organization of the Federation of Enterprise Architecture Professional Organizations (FEAPO), a worldwide association of professional organizations formed to advance the discipline of Enterprise Architecture.

Process (engineering)

In engineering, a process is a series of interrelated tasks that, together, transform inputs into outputs. These tasks may be carried out by people, nature or machines using various resources; an engineering process must be considered in the context of the agents carrying out the tasks and the resource attributes involved. Systems engineering normative documents and those related to Maturity Models are typically based on processes, for example, systems engineering processes of the EIA-632 and processes involved in the Capability Maturity Model Integration (CMMI) institutionalization and improvement approach. Constraints imposed on the tasks and resources required to implement them are essential for executing the tasks mentioned.

Quality management

Quality management ensures that an organization, product or service is consistent. It has four main components: quality planning, quality assurance, quality control and quality improvement. Quality management is focused not only on product and service quality, but also on the means to achieve it. Quality management, therefore, uses quality assurance and control of processes as well as products to achieve more consistent quality.

What a customer wants and is willing to pay for it determines quality. It is written or unwritten commitment to a known or unknown consumer in the market . Thus, quality can be defined as fitness for intended use or, in other words, how well the product performs it's intended function

SX000i - International guide for the use of the S-Series of Integrated Logistics Support (ILS) specifications

SX000i - International guide for the use of the S-Series of Integrated Logistics Support (ILS) specifications, is a specification developed jointly by a multinational team from the Aerospace and Defence Industries Association of Europe (ASD) and Aerospace Industries Association (AIA). SX000i is part of the S-Series of ILS specifications.

SX000i provides information, guidance and instructions to ensure compatibility and the commonality of Integrated Logistics Support (ILS) processes among the S-Series suite of ILS specifications jointly developed by both associations.

By defining common logistics processes to be used across all S-Series ILS specifications and the interactions of the current S-Series ILS specifications with the logistics processes, the SX000i forms the basis for sharing and exchanging data securely through the life of products and services, not only within the support domain, but also with other domains such as Engineering. The SX000i also provides governance for the maintenance of current S-Series ILS specifications and the development of new S-Series ILS specifications.

SX000i builds on existing standards and specifications so as to provide a unified view of sometimes contradictory ILS specifications and publications. A reference and mapping of SX000i to these documents has been provided in Chapter 6.

Software architecture

Software architecture refers to the high level structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.Software architecture is about making fundamental structural choices which are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of software. For example, the systems that controlled the space shuttle launch vehicle had the requirement of being very fast and very reliable. Therefore, an appropriate real-time computing language would need to be chosen. Additionally, to satisfy the need for reliability the choice could be made to have multiple redundant and independently produced copies of the program, and to run these copies on independent hardware while cross-checking results.

Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.

Stuart Arnold

Stuart Arnold (1945–2015) was a UK systems engineering professional, with a degree in electrical engineering from Leeds University.

Stuart Arnold had a background in private and public sector engineering management applied to systems and software products and services. This spanned the leadership of engineering teams, the application of new technology and conducting research into systems engineering.

Stuart’s career started in microwave technology at Roke Manor Research in the UK. His systems engineering knowledge drew heavily on many years of international industrial experience working for Philips in the development, manufacture and product support of domestic, professional and defence systems. He was Software Engineering Manager for Thorn EMI Sensors before moving into government service as Systems Engineering Manager in the UK’s Defence Evaluation and Research Agency, later a QinetiQ Fellow and QinetiQ’s Systems Engineering Head of Profession.

Stuart contributed to establishing a common international understanding of the discipline of systems engineering, and to its presentation as a natural and essential element of business practice. As the Editor of the systems engineering International Standards, ISO/IEC 15288 and its companion assessment model ISO/IEC 15504 Part 6, Stuart was at the heart of ISO actions to establish systems engineering as a cardinal component of international trade and commerce. He was also a recognized contributor to both IEEE 1220 and EIA-632.

Stuart was a Chartered Engineer in the UK, a Fellow of the Institution of Engineering and Technology, and a Fellow of the International Council of Systems Engineering (INCOSE).

Systems engineering

Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.

Issues such as requirements engineering, reliability, logistics, coordination of different teams, testing and evaluation, maintainability and many other disciplines necessary for successful system development, design, implementation, and ultimate decommission become more difficult when dealing with large or complex projects. Systems engineering deals with work-processes, optimization methods, and risk management tools in such projects. It overlaps technical and human-centered disciplines such as industrial engineering, mechanical engineering, manufacturing engineering, control engineering, software engineering, electrical engineering, cybernetics, organizational studies, civil engineering and project management. Systems engineering ensures that all likely aspects of a project or system are considered, and integrated into a whole.

The systems engineering process is a discovery process that is quite unlike a manufacturing process. A manufacturing process is focused on repetitive activities that achieve high quality outputs with minimum cost and time. The systems engineering process must begin by discovering the real problems that need to be resolved, and identifying the most probable or highest impact failures that can occur – systems engineering involves finding solutions to these problems.


TRAK is a general enterprise architecture framework aimed at systems engineers based on MODAF 1.2.

ISO standards by standard number
IEC standards
ISO/IEC standards

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.