Frequently Asked Questions

The 4th 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 4th 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.

The handbook outlines 31 processes (including the Tailoring Process). As described in the book these processes are logical descriptions of what must happen (and why), with some idea of how. There should be no when or who in these process descriptions. Unless we are following a sequential life cycle approach, any of the processes could be invoked more than once during the system life cycle.
With this in mind and studying the IPO for the Validation Process 4.11 “Validated requirements” are one output of the Validation Process. These “Validated requirements” are then input to the 4.2 Stakeholder Needs and Requirements Definition (SNRD) and 5.2 Project Acceptance and Control (PAC). “Validation” is a general process that can be used to validate any other process output, not just the system-of-interest vs. business and stakeholder needs. Perhaps on the first pass through SNRD and PAC the “validated requirements” don’t exist, or they are immature.
Remember, IPO notation does not support iteration or recursion; no suffixes or index numbers, everything needs a fixed name. In real life, SNRD almost never starts from a blank sheet of paper. If some parts of the System are precedented, or even if the System Context is precedented, there will already be some Validated Requirements – either from a previous version of the System, the containing System, or its major System Elements. It would not be prudent to omit these inputs in the SNRD process – they might not end up adopted unmodified, but they’re a good starting point. 
“Strategy documents” are input to 5.1, and, based on their description in Appendix E, can be treated as a subset of “Source documents” which are input to Business or Mission Analysis (BMA) 4.1 and 4.2 Stakeholder Needs and Requirements Definition (SNRD) “Outputs” from these processes are as indicated in the respective IPO diagrams. One can consider “strategy” documents similarly to “life cycle concepts” in that they guide the transformation of needs and other constraints into requirements and project plans. They may arise from any life cycle process (see Appendix E). You may view this as a “pipe” or “bucket” for collecting up to 31 strategies. It might not look much on paper but it is potentially a massive input to 5.1 Project Planning (PP), noting that PP’s own strategy also feeds into the pipe so loops back on itself. It is one of the mechanisms that allows processes to communicate between chapters (or process groups). Another example is “Records”.  
The question asks “what activities” but that’s probably going too deep. If we think about the processes that use the strategy documents then as a minimum each process should use its own strategy, and the outputs from that are clear in the relevant IPO. I suggest we leave the SEMP to figure out the couplings between processes and the outputs that will be produced – as we can see from the IPO diagram for Project Planning, the SEMP has knowledge of all the strategies. The handbook can’t go to this level of detail, and it would be heavily dependent on tailoring.

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.

Do you have more questions? Let us know here. We would be glad to answer.

Scroll to Top