INCOSE Handbook FAQ

The 4^th edition of the handbook is deliberately aligned to the structure of the ISO/IEC/IEEE 15288:2015 standard. The process names and process purpose statements are directly copied from the standard. INCOSE provided a model for implementing the principles of the standard, supplemented by chapters on subjects such as life cycle stages, tailoring, cross-cutting methods, and specialty engineering.

The parent ISO standard includes “Systems and software engineering” in its title, whereas the handbook only mentions systems in its own title.

CTI considers that all of the principles of systems engineering can be applied to a project that happens to involve software in its solution, and equally to a project that only involves software.

Not in detail. It treats element design as a black-box process. Each technology (or capability, more broadly speaking) has evolved its own body of knowledge (e.g. for electronics or hydraulics). The handbook does not need to reproduce this; it provides the glue that enables systems to be created from a range of element types.

No. Other organizations have produced systems engineering guidance material (for example NASA and ESA, or, in a web-based implementation, SEBoK). Each authoring team may have chosen different vocabulary and different process boundaries, but they all have broadly the same objective.

One of INCOSE’s aims is to create a global community of systems engineers. Agreeing on process boundaries and vocabulary would help in achieving that, but it will undoubtedly be a slow journey.

The handbook accepts that there are different ways of understanding the term “systems engineering”. It delineates three main ways: perspective, process, and profession.

In terms of process, it covers much more than “just doing” the engineering. CTI suggests that the headings for Chapters 4 to 7 allow us to infer a much broader scope:

• Defining and solving the problem (“doing the work”);
• Managing the work;
• Managing acquisition and supply relationships;
• Achieving systematic improvement at organizational level.

There is no single “best order”. It is very common for processes to be invoked in parallel. It is important to define an execution path that is optimal for your particular project, which will be a trade-off between various success factors.

The book has to be printed in chapter order, but that does not mean the processes have to be executed in chapter order.

The chapter order may be helpful in terms of understanding the logical relationships between processes.

CTI has found that, overall, the links between process areas make sense, with perhaps a few anomalies.

In general, the inputs and outputs are represented without any particular state. (System architecture description, for example, could be up-issued a number of times on a project, but this is not explicitly represented in the IPO model).

A small number of inputs and outputs have explicit states defined, for example Final RVTM, Initial RVTM, and Updated RVTM. The reason for this is not entirely clear, but it is worth appreciating this when revising for the exam. This could perhaps be addressed on the next update of the handbook.

Almost certainly. Version 3.2.2 was released in 2011, and Version 4 in 2015. Appendix G in the 4^th Edition can be used to submit comments to the authors. Estimated publishing of the handbook will be 3-5 years (2021-2023). The primary driver is alignment with ISO15288:202x, which will not be initiated for 2-3 years (estimated). Also to date there have not been major comments thus far to move to an earlier release.

Appendix E indicates that “Procedures” arise from any life cycle process. These are inputs to PAC as the bases for “Assessment” of the project, i.e., an assessment of whether the project is conforming to these processes. Although Appendix E lists “including integration …. disposal”, there are other processes whose procedures we may include as an input to PAC such as 5.3 Decision Management and 8.1 Tailoring. This is a challenge to the content of the handbook and not the level of detail you would be expected to know for the examination but it is still good to consider. Ultimately, the content of the handbook should always be adapted, as with standards, to your organization, not the other way around.

Food for thought: At a higher level of abstraction, we also need to assess conformance to processes. Hence “processes” should be an input to PAC but we don’t see it here in the IPO. The set of tailored processes is disguised within the SEMP however the SEMP doesn’t show up as an input to PAC either.