Systems Engineering FAQ

Answers by Robert Halligan FIE Aust CPEng IntPE(Aus).

Do you have any advice on systems engineering standard ISO/IEC 15288 (IEEE Std 15288-2008) – 2nd Edition “Systems and software engineering – Systems Life Cycle Processes”?


Yes. We regard ISO/IEC 15288: 2008 as a poor standard, one that will most likely do more harm than good to any enterprise that tries to follow it. The most serious flaws are:

  • the “then a miracle occurs process” that is supposed to occur between the capability/business system and the definition of elements of technology and other elements that are to integrate to provide the capability;
  • the discarding of architecture as a level of abstraction of design of an object and with reference to the next physical level down, replaced by architecture as “design at high physical levels” versus “detailed design” being design at low physical levels. This view has as much usefulness as the views of the Flat Earth Society.
  • excluding the application of systems engineering from systems constructed on a dominant technology, e.g. mechanical, electronic, software. Some of the most successful applications of systems engineering have been in this context.
  • limiting verification and validation to system verification and validation. Insane, a 40 year regression to the days of “inspecting in” quality.
  • totally muddling up the act of production with the act of developing a production system (requirements, design, production of the production system, and V&V of everything along the way); similarly a maintenance system; similarly a disposal system; …  In this debacle, there is not a shred, nor the possibility of a shred, of the concepts and practice of concurrent engineering (simultaneous engineering). And yet, concurrent engineering has been the biggest success story in engineering practice of the 20th century, a way of life for high performance companies.

The author is intimately familiar with ISO/IEC 15288 & ISO/IEC TR 19760, having spent three years as the INCOSE (International Council on Systems Engineering) Head of Delegation to ISO/IEC JTC1 SC7 (Software and Systems Engineering), and a member of Working Group (WG) 7 which developed ISO/IEC 15288 & ISO/IEC TR 19760. I had the same participatory rights as the representatives of National Bodies, but no voting rights. The development team never achieved consensus. Why is a subject that should only be discussed privately, and only where necessary.  Suffice to say that the project was to be cancelled if a particular meeting of WG7 did not vote to move the standard forward along the path to publication. A deal was done to muster enough votes, the deal being that a new project would be immediately raised to redevelop the standard. This project started, but collapsed. Then, per the normal ISO standards cycle, an update was done from ISO/IEC 15288:2002 to ISO/IEC 15288:2008.  The second edition is not as bad as the first, but it is still terrible. The comments above apply to the second edition.

A majority vote of WG7 repeatedly favored fixing the major problems that are described above. This is all on the record.  That it didn’t happen reflects serious flaws in the ISO standards development process.

A detailed critique of ISO/IEC 15288:2008, referred to as an Application Guide, is at the Downloads page of this website.


Answered By

Systems engineering thought leader, consultant, trainer and coach, impacting people's lives on six continents.
Published 2 years ago


FREE Monthly SE Industry News?

Why Recognition of Profit, not Imposition of Process, Will Ultimately Bring Systems Engineering Into Common Usage

What Factors Hold Back the Widespread Practice of Systems Engineering? Randall Iliff explores this fascinating question in the April 2023 issue of PPI SyEN. His perspective as a founding member of INCOSE and current PPI Principal Consultant offers unusual clarity regarding the challenges we face […]

Scroll to Top