ISO 15288 and technical maturity

The ISO-15288 technical processes, system maturity, and conceptual gaps

This paper was co-authored with Liz Wright and Alexander Hill of Costain Group, UK and was presented at INCOSE International Symposium 2022. At the time of writing the original paper, the 2015 editions of ISO 15288 and INCOSE Systems Handbook were current. The latest editions do not make any substantive change that affects the content of this paper.

Abstract. ISO 15288 and the INCOSE Systems Engineering Handbook define technical (and other) processes but do not really explain why we need all of them. This paper formalizes the technical processes specifically in terms of the changes in maturity that each enacts and why these particular changes are necessary. This in turn clarifies the need for each process and places the processes on a sound philosophical footing.

Introduction

Like many other organizations, Costain’s Systems Engineering Team started using remote meeting technology during the pandemic-induced lockdown to replace and supplement face-to-face interaction. To give these calls structure, we chose specific topics, one of which was reading and learning from ISO 15288 [ISO 2015] and the INCOSE Systems Engineering Handbook [INCOSE 2015]. This caused us to examine these sources in more detail than we had previously, which led eventually to the insights described in this paper. This work builds on that presented in [Collyer et al, 2021] to focus on system maturity and bridging conceptual gaps. [Collyer et al, 2021] presented an approach to the technical processes that focused on state changes in the system or information about the system.

Development of any system progresses through a set of life cycle stages in which information, a record, or an artifact may be developed, as defined in ISO 12207 [ISO 2017]. The state of the system matures as it passes through the life cycle stages: Concept, Development, Production, Utilization, Support, and Retirement. These stages can occur independently, as overlapping stages, or concurrently with one another, depending on the life cycle model adopted [Parnas, & Clements, 1986]. Typically, at any time, various parts of the system will be in different states up to at least the system being operable and often beyond.

ISO 15288 maps these stages onto a total of thirty distinct processes, fourteen of which are classed as technical processes. With so many processes, it is perhaps not surprising that people can get confused about what they are all for and what are the (sometimes subtle) differences between them. This is particularly important when different organizations participate in a project, working on different processes or different parts of the system. For example, an organization in the construction industry might use the Implementation process while delivering “construction” and may contract out the Design Definition process to a design house but will not necessarily be involved in, or aware of, the processes and steps used in this work. Many engineers, program managers, and project managers find it challenging to understand why they cannot skip or combine processes. In particular, the Architecture Definition and Design Definition processes are often confused. In our perspective the distinction is clear as the two processes increase the maturity of the system, or the maturity of the information about the system, in distinct ways. The Architecture Definition process makes a state change in the abstract definition of system elements and the Design Definition process makes a state change from that abstract definition to a concrete definition.

Purpose of processes

ISO 15288 and the INCOSE Systems Engineering Handbook (hereinafter “the Handbook”) define technical and other processes. Unfortunately, it is not always clear exactly what the purpose of each of these processes is. The Handbook defines the purpose of each process in terms of what the processes does, not on what the process is for. For example, the Handbook defines the purpose of the System Requirements Definition process as (from ISO 15288):

The purpose of the System Requirements Definition process is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user.

The start point is reasonably clear, but the phrase “technical view of a solution” would equally well fit Architecture Definition or Design Definition. This gives rise to the obvious questions:

• Why do we need to do this?
• What do we gain by doing this?

Looking at the technical processes from the perspective of a systems engineering novice, perhaps with project management experience, there seem to be things missing without being able to put a finger on exactly what. In this case, the actual outcome of the process is a definition of what the system must do to meet the needs. You can do the same analysis for each of the technical processes. In our view, the focus on the activities conducted within each process and the descriptions of the outcomes through the narrow lens of systems engineering obscures the wider engineering, commercial and financial value of the processes. The approach presented here clarifies the processes in terms of the changes they make to the system, and hence clarifies why we need all the processes.

ISO 15288 itself provides more clarity for the purposes of the processes by providing additional information. The Handbook only quotes the single paragraph purpose for each process. We would contend that most engineers would, in practice, refer to the Handbook rather than the standard. However, we recognize that the Handbook must balance comprehensiveness against readability and the more detail that is provided the less readable the Handbook becomes.

How are the technical processes related?

ISO 24748-1 [ISO 2018] states:

The relationships between the processes are only static. The more important dynamic, real-life relationships between the processes, between the parties, and between the processes and the parties are established when the appropriate document is applied on projects in a manner specific to that project.

In thinking of the Technical Processes from the Handbook in this way, and the resulting relationships between them within a life cycle, we decided to look at them as a flow to see what we could learn. To be clear we are not saying that the technical processes are sequential or that all of them need to be used, this was a thought exercise intended to learn more about each process. Also, note that in using a flow we are very specifically not claiming that the entire system progresses through the flow as a single entity moving from one process to the next. For example, some parts could have gone through the Implementation process while other parts are still transitioning to Defined Stakeholder Requirements. You could even have some parts of a system being disposed of while others are having their scope defined – think of a wing of a hospital being demolished to make way for a new treatment facility while the rest of the hospital is operating as normal.

When using a flow as a means through which to examine the systems engineering technical processes, we came to realize that a state change, equivalent to a change in maturity of understanding, occurs between the entry and exit of each specific process for each entity (system, sub-set, element) that goes through that process. It is only the processes that make these changes, the system and information about it is static between the processes.

Initially, we modelled the ISO 15288 systems engineering technical processes as a Flow Diagram [Collyer, 2020]. To further progress this thinking, we mapped the flow onto an Activity Diagram, as shown in Figure 1. Note that we omit the System Analysis process from the diagram and subsequent consideration in this work as in our view this is a supporting process to all the other technical processes¹

Figure 1: Activity Diagram of the Technical Processes

To repeat, by looking at the processes as a flow, we can see that the system and information about the system only change within the processes.

Starting from the general guidance that any process should do one thing and do it well [McIlroy et al, 1978] we asked: what one thing does each process do? We suggest that the one thing that each technical process should do well is enact a change in the system of interest. This can be a change in the maturity of the system itself or some part of it or a change in the maturity of the information about that system or some part of it. The purpose of each process is clearly to enact the defined change. For ease of expression and in the interests of reducing repetition, in the following we use the term “system” to include any subset of the system or information about the system.

Defining the purpose of each process in terms of the changes in the system that the process enacts clarifies the purpose of each process. This reduces the confusion that typically occurs when people, especially those without a Systems Engineering background, try to get to grips with the difference between two processes, for example, the Architecture Definition and Design Definition processes, as mentioned earlier. We explore the benefits of this in the paper with examples.

The authors believe that this way of thinking about the processes makes them more accessible and makes the purpose of each clearer, particularly for the new systems engineer, organization, or sector.

What are the state changes in the technical processes?

From the preceding work, we can see that for each of the systems engineering technical processes, a state change occurs between the entry and exit of that specific process. In this section we will examine each process and identify the state change involved.

It is worth defining how we use some terms in this context.

• Actor: In this context, used to state that the focus is on those who interact with the system, not on the system itself.
• System: In this context, used to state that the focus is on the system itself.
• Verb: The focus is on what the actor or system does, not what it is.
• Noun: The focus is on what something is.
• Abstract: What we are describing is conceptual, not yet a real thing.
• Concrete: What we are describing is real, either a physical entity, information or other.

For example, if we consider the Transition process, the system state changes from “Verified Concrete System” to “Operable Concrete System”. As an aside, earlier work also defined the overall focus of each process, distinguished between whether the focus was on the Problem Domain or Solution Domain, and separated the level of Abstraction (Abstract or Concrete). However, we felt that this did not add anything significant to the analysis.

We can explore this further through an example. We will use a restaurant serving hot food. For simplicity, we focus on one aspect of this, cooking the food, and narrow our focus as appropriate. Clearly there are several other things that need to be considered, such as accommodation for the restaurant, how food is delivered, how it is paid for, cleaning and maintenance, staffing, hygiene, and so forth. In a very real sense, “Cooking” is a system in a system of systems.

Table 1 maps each technical process to a state change, using the restaurant example throughout.

Table 1: State changes with examples

Process	State Change	Example
Business and Mission Analysis	Initial ideas → Overall Scope	Restaurant supplies hot meals to customers
Stakeholder Requirements Definition	Overall Scope → Verbs describing what the Actors want to achieve (Actor Verbs)	Chef shall be able to cook a meal
System Requirements Definition	Actor Verbs → Verbs describing what the System will do (System Verbs)	System shall supply suitable heating
Architecture Definition	System Verbs → Nouns describing the System in Abstract terms (Abstract System Nouns)	Heat source below pans
Design Definition	Abstract System Nouns → Nouns describing the System in Concrete terms (Concrete System Nouns)	Induction heating and suitable pans!
Implementation	Concrete System Nouns → Individual Elements that will make up the System (Concrete System Elements)	Physical induction stove top and pans
Integration	Individual Concrete System Elements → Integrated System	Integrated stove top and pans
Verification	Integrated Concrete System → Verified System	Verified stove top and pans
Transition	Verified System → Operable System	Operable stove top and pans
Validation	Operable System → Validated System	Validated stove top and pans
Operation	Validated System → Operational System	Stove top and pans in use
Maintenance	Operational System → Maintained System	Maintained stove top and pans
Disposal	Maintained System → Disposed System	Disposed stove top and pans

Laid out in this way, each of these state changes clearly represents an increase in the maturity of the system.

What is the point of all these processes?

As stated above, each of the technical processes effects a state change in the system reflecting an increase in the maturity of the system. But this still does not clarify why all the technical processes are useful. Many program and project managers find it challenging to understand why they cannot skip or combine processes, especially in sectors where they will only traditionally see one phase of a project in isolation. For example, an organization in the construction industry might use the Implementation process while delivering “construction” and may contract out the Design Definition process to a design house but will not necessarily be involved or aware of the processes and steps used to reach this point.

Given “as simple as possible but no simpler” is a good general rule, the obvious question is: why do we need so many processes? The answer is that going from defining the problem in the abstract to defining the solution in detail in the concrete is (in all but the simplest cases) a big conceptual gap. A conceptual gap arises when the concepts or elements in one statement about the system cannot be clearly mapped to concepts or elements in another statement. Using the cooking example above, there is a clear conceptual gap between the need to provide heat and the physical properties of the components of the circuit to control the heat. If you try to bridge too big a conceptual gap, you risk losing the ability to see meaning in the connection. It is not easy to see directly why we need a particular type of wire to be able to cook food.

In particular, the Architecture Definition and Design Definition processes are often confused. Using state change and maturity as a guide, the distinction is clear as the Architecture Definition process makes a state change in the abstract definition of system elements, from verbs (what the element does) to nouns (what the element is), and the Design Definition process makes a state change from abstract nouns to a concrete definition. They both increase the maturity of the system but in distinct ways. In our example above, the architecture decision is to put a heat source below pans, the design specifies the particular type of heat source as induction heating and thus the need for suitable pans.

Each process moves the understanding and development of the system forward in logical and discrete steps which we can follow and justify. This is important when communicating the details of how the system meets stakeholder needs, especially if the result is not what the stakeholders initially expect. In addition, by following every process we reduce errors by progressing the system in a prescribed way. This in turn reduces risk.

Can we combine processes?

Notwithstanding the discussion above, the obvious question arises of whether we can eliminate or combine any of these processes. The answer is, as so often in systems engineering, “it depends”. Using the example from above, could we skip or join any of the technical processes in this case? It is not at all clear that we could, each of them fulfils a clear purpose in achieving a specific goal.

However, if we consider a simpler example, imagine you want to attract birds to your garden. That is a quite simple goal and does not need much in the way of Business and Mission Analysis, so that process could possibly be skipped, and you start with Stakeholder Requirements Definition. Thinking of the birds as stakeholders, you might identify that one way to attract them is to provide food. So, the stakeholder requirements for the birds include being able to get to the provided food. In addition, you do not want predators being able to get to the feeding birds. In this simple case there is virtually a direct one-one correspondence between these stakeholder requirements and the system requirements – the system must be able to provide food in a way that is safe for the birds. What does “safe” mean? We are thinking of safe from predators, such as cats. We can extend this to think about animals that might steal the food, such as squirrels. This leads to a potential architecture consisting of a platform supported in such a way that undesired visitors (predators and thieves) find it difficult to access, but birds can. One way of doing this is to support the platform on a single central pole, with sufficient overhang that undesirables cannot negotiate it to access the platform. Architecture Definition and Design Definition can come together here to a significant extent as the design decision is essentially about the materials you use (spare wood from the shed, perhaps). Similarly, Implementation and Integration can effectively be combined. The same applies to Verification, Transition, and Validation – these together essentially amount to putting the system into a specific location, and ensuring it holds bird food and birds can access it safely. Operation and Maintenance are about putting food on the platform and repairing it if needed. These are clearly separate activities and cannot be combined.

The natural question to ask, then, is how do we know if it is safe to combine processes? Or, to put this a different way, what does the decision to combine processes depend on? In answering this question, consider the state changes associated with each process and the size of cognitive gap with which you are comfortable – or perhaps which you are confident you can safely bridge. In the case of the restaurant, we do not feel comfortable combining processes because we see how each provides us with real value. In the case of the bird table, we do feel comfortable combining certain processes because the conceptual gap is relatively small.

Do we need multiple levels within one process?

We have discussed conceptual gaps as part of the reason we need several processes, that is, to avoid having to bridge too big a conceptual gap. In sufficiently complicated or complex systems, conceptual gaps can occur even within one process; this is one reason we might have several levels for some processes. A common example is having several levels of Stakeholder Requirements Definition with different names and different focuses.

We also see multiple levels of the same process because of the recursive nature of system development, in particular decomposition into subsystems. The progression from the System Requirements Definition process to the Architecture Definition process to the Design Definition process is typically recursive, as a design is, in a sense, defined as a set of decomposed subsystems and their interactions, where the subsystems are each defined by their own system requirements. Figure 2, derived from [QSS, 1998], illustrates this.

Figure 2: Recursive Application of Technical Processes

This recursion ends when we can produce something concrete. In some quite simple cases this might only be a single level, in most non-trivial systems the recursion will be several levels deep. How many levels are needed in a specific case is a matter of judgment. Too few and you have a wide conceptual gap between the levels, too many and the distinctions between the levels are unclear and there is redundancy. Note that this is distinct from iteration, where work in one process leads to revisiting an earlier process without (necessarily) adding more levels.

How many processes do we need?

We can conclude that it is possible to combine and skip processes, depending on the conceptual gap to be bridged. We can also conclude that sometimes there is a sufficiently large conceptual gap that we need to split processes over several levels. We have not answered the obvious question of how we know when to skip, combine, or split processes, other than to say it depends on the size of the conceptual gap. Also consider that what appears to be a large gap to some might seem small to others.

In the restaurant example, the standard set of technical processes is sufficient, although there will probably be some need to use multiple levels in the design of specific elements. Also, consider that we have focused on one aspect of cooking and ignored the wider concerns such as how food is delivered, how it is paid for, and so forth. In the simpler case of the bird table, we can see that it is possible to combine processes with no significant detriment to the overall result.

This means that this decision is always a matter of engineering judgement depending on the context. The context includes the problem to be solved, the proposed solution, the environment, and the participants. A heuristic that we have found useful is to ask when the state of the system needs to be reviewed. Again, some judgment is called for in making this decision. In some cases, there may be mandated reviews for regulatory reasons – this would be a good reason for including a specific technical process. In others it is a question of balancing the costs of having a specific review against the potential costs of not doing it and potentially missing something important.

Related Work

This work builds directly on that presented in [Collyer, 2020] which focused on the importance of state changes in each process. The non-sequential nature of systems development was, to the best of our knowledge, first highlighted by David Parnas and Paul Clements [Parnas, & Clements, 1986] and is fundamental to the relationship between the technical processes discussed in [Collyer, 2020].

The presentation of process information as a table or grid has similarities with MBSE Grid [Morkevicius et al, 2017). This work differs in the significance of the table – for the current work, the table is a tool which helped our understanding but is not fundamental, while the table is the focus of MBSE Grid. Also, each row in MBSE Grid relates to one of the three classic levels of abstraction (Problem Definition, Solution Definition, Solution Design). In this paper’s approach, each row is one of the systems engineering technical processes. The cells in MBSE Grid present specific outcomes and approaches relating the rows to the “pillars” (columns in the table) of requirements, behavior, structure, and parametrics, for example, the use of use case diagrams to define use cases in the intersection of “Black Box” and “Behavior”. Thus, the columns and rows in the two approaches are entirely distinct. Although MBSE Grid is not related directly to the work presented here, the current work supplies a theoretical underpinning to the practical results described in that paper and further work combining the two could be valuable.

Conclusions

Looking at the technical processes from the perspective of a systems engineering novice, albeit with project management experience, the technical processes defined in ISO 15288 focus on how to do the process, not necessarily on the outcome of the process, hence the value provided by the process can be missed.

By defining what changes occur in the maturity of the system of interest during each of these processes, we reduce confusion about exactly how the processes differ. In our experience, this confusion typically occurs when people, especially those without a systems engineering background, try to get to grips with the difference between two processes, particularly those processes where the system definition is developed. For example, the Architecture Definition process and Design Definition process are often confused – viewing them as making well-defined changes to the state of the system makes clear how they are different.

The work presented in this paper makes it clear what the outcome is for each of the technical processes defined in ISO 15288 and shows how each process adds value. Framing this in terms of state changes, increases in maturity, and bridging conceptual gaps also gives us guidance for when processes need to be kept separate, when they can be combined and when they need to be further decomposed.

Focusing on the perspective of increasing maturity within the technical processes will significantly improve awareness of what each process delivers and makes the processes easier to understand. It further makes explicit the value of using each of the processes in terms of their outcomes. This understanding will also help a systems engineer tailor the processes to their specific system.

A consequence of using all the technical processes is that we reduce the conceptual gap between the as-is and the to-be for each activity in our life cycle. If we skip or combine processes this conceptual gap is generally too great to comprehend.

We have presented an approach that makes use of these ideas to reduce confusion and provide greater clarity, leading to systems that better match the needs of stakeholders. We believe that reducing confusion about, and showing the value of, the systems engineering processes will increase the adoption of systems engineering on projects and programs, with consequent reduction of risk.

In summary, in our work we looked at the technical processes and why we may need them all. Thinking in terms of state changes helps us to understand the need for each process. Each enacts a specific state change. Each of these state changes in turn reflects increasing maturity of the System of Interest.

We have shown what this means in practice through examples.

References

Collyer, K.A., 2020 ‘Process Models are not Flow Charts’ In: INCOSE UK Annual Systems Engineering Conference (ASEC) 2020, Ilminster, UK: INCOSE UK

Collyer, K.; Wright, L.; Hall, A., 2021 ‘Making the technical processes work for you – a new perspective’ In: INCOSE UK Annual Systems Engineering Conference (ASEC) 2021, Ilminster, UK: INCOSE UK

DAU. 2010. ‘Defense Acquisition Guidebook (DAG)’. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.

DoD 2022. ‘Engineering Defense Systems Guidebook’. Washington, DC, USA: U.S. Department of Defense (DoD). February 2022

INCOSE 2015, ‘Systems Engineering Handbook’, 4th ed. San Diego: INCOSE

ISO/IEC 15288:2015, ‘Systems and software engineering — System life cycle processes’, Geneva: ISO

ISO/IEC/IEEE 12207:2017. ‘Systems and software engineering — Software life cycle processes’, Geneva: ISO

ISO/IEC/IEEE 24748-1:2018. ‘Systems and software engineering — Life cycle management’, Geneva: ISO

McIlroy, M.D.; Pinson, E.N.; Tague, B.A. 1978 ‘UNIX Time-Sharing System: Forward’ In: Bell System Technical Journal, 57: 6. July-August 1978 pp 1899-1904, Murray Hill, NJ: Bell Laboratories

Morkevicius, A; Aleksandraviciene, A; Mazeika, D; Bisikirskiene, L; Strolia, Z 2017 ‘MBSE Grid: A Simplified SysML-Based Approach for Modeling Complex Systems’ In: Proceedings 27th Annual INCOSE International Symposium: San Diego: INCOSE

Parnas, D. L. & Clements, P. C. 1996 ‘A Rational Design Process: How and Why to Fake It’ IEEE Transactions on Software Engineering, Vol.12, No. 2.

QSS (1998) ‘Requirements Methodology: 3-day training course’ Oxford: QSS

Written with StackEdit.

---

1. Based on this understanding, we suggest changing ISO 15288 by renaming the Technical Management Processes to Technical Support Processes and moving System Analysis to this section. ↩︎