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. ↩︎

What are Stakeholder Requirements?

Introduction

Recently I have seen much discussion around the term “stakeholder requirements”. To make sense of this I have looked into the origin of the term and the related terms “(stakeholder) needs” and “system requirements”. I am particularly concerned as the authors of the INCOSE Needs and Requirements Manual have chosen to interpret the stakeholder requirements in a way that is counter to all my experience in over thirty years of practice, consulting, and teaching.

Where do the terms come from?

Much of the terminology around requirements originated in the software world. One of the first lessons I learnt in writing specifications was to distinguish between the “user requirements”, which defined what users wanted, and the “functional specification”, which defined what the software (system) would do. Over time, these terms were replaced by “stakeholder requirements” as a way of recognizing that people and actors other than the users would have requirements on the system, and “system requirements” to recognize the importance of non-functional aspects¹.

Moving on in time, the two major standards in our field are ISO 15288 Systems and software engineering — System life cycle processes and ISO 29148 Systems and software engineering — Life cycle processes — Requirements engineering. Interestingly, neither of these standards explicitly defines “needs”, “stakeholder requirements”, or “system requirements”. Unless otherwise stated, the definitions here are from ISO 29148, though these are consistent with ISO 15288:

requirement

statement which translates or expresses a need and its associated constraints and
conditions

Note 1 to entry: Requirements exist at different levels in the system structure.

Note 2 to entry: A requirement is an expression of one or more particular needs in a very specific, precise and unambiguous manner.

Note 3 to entry: A requirement always relates to a system, software or service, or other item of interest.

stakeholder requirements specification

structured collection of the requirements [characteristics, context, concepts, constraints and priorities] of the stakeholder and the relationship to the external environment

Although neither standard explicitly defines stakeholder needs or stakeholder requirements, ISO 15288 includes this statement, which I have structured for consistency with other definitions:

Stakeholder needs

describe the needs, wants, desires, expectations and perceived constraints of identified stakeholders.

In terms of process, ISO 29148 states:

Defining requirements begins with stakeholder needs (or goals, or objectives) that are refined and evolve before arriving as valid stakeholder requirements.

This implies that goals or objectives can be needs and is consistent with the definition extracted from ISO 15288.

So, what are Stakeholder Requirements? ISO 15288 defines the process of defining them as (in part):

It analyzes and transforms these needs into a common set of stakeholder requirements that express the intended interaction the system will have with its operational environment and that are the reference against which each resulting operational capability is validated. The stakeholder requirements are defined considering the context of the system of interest with the interoperating systems and enabling systems.

Further, from this and the definition of stakeholder requirements specification in ISO 15288, we can infer the following definition:

stakeholder requirements

requirements of one or more stakeholders that express the intended interaction the system will have with its operational environment, and are the reference against which each resulting operational capability is validated.

We also need to define system requirements. ISO 15288 states this:

system requirements specification

structured collection of the requirements [functions, performance, design constraints, and other attributes] for the system and its operational environments and external interfaces

ISO 15288 further defines the System requirements definition process as:

This process creates a set of measurable system requirements that specify, from the supplier’s perspective, what characteristics, attributes, and functional and performance requirements the system is to possess, in order to satisfy stakeholder requirements. As far as constraints permit, the requirements should not imply any specific implementation.

It is then straightforward to infer the following definition:

system requirements

specify, in a way that is measurable, from the supplier’s perspective, what characteristics, attributes, and functional and performance requirements the system is to possess, in order to satisfy stakeholder requirements. As far as constraints permit, the requirements should not imply any specific implementation.

If we are to use the terms “stakeholder needs”, “stakeholder requirements”, and “system requirements” (and there is value in doing so), then it makes sense for them to mean different things. Defining stakeholder requirements as stakeholder-owned system requirements does not add any meaning, as you should be specifying the owner(s) as an attribute to each requirement anyway. Far better would be to separate them according to the definitions given above. We can use:

• Stakeholder Needs: The original set of statements from the stakeholders, poorly formed, ambiguous, and conflicting though they might be. Define the problem to be solved in its original form.

• Stakeholder Requirements: Derived from the Needs, a self-consistent, unambiguous set of statements that comprehensively define what the system must achieve. Owned by the stakeholders in the sense that they are the final arbiters. The problem to be solved after refinement, including resolving inconsistencies, filling gaps, removing ambiguity, etc. In other words, a well-formed definition of the problem.

• System Requirements: A well-formed definition of what any system must do to satisfy the Stakeholder Requirements. Derived from the Stakeholder Requirements, a self-consistent, unambiguous set of statements that comprehensively define what the system must do. Owned by the systems engineers.

The definitions I use above are consistent with decades of practice, ISO 29148, ISO 15288, and the 4th edition of the handbook. If INCOSE is now choosing to define stakeholder requirements as stakeholder-owned system requirements rather than as the problem definition, then it is taking a huge risk by removing an essential concept.

The controversy

There is nothing too controversial in the above. However, ISO 29148 states the following:

"When the system of interest is a system element at the second or lower level in the overall system structure, it is also necessary to identify stakeholder needs and requirements at that level. These needs do not just apply to the topmost system in the system structure. There could be additional stakeholders that are not discovered until lower level architecture or design decisions are made.

The stakeholder-owned system requirements are then transformed into lower level system element requirements for the system-of-interest."

The authors of the INCOSE Needs and Requirements Manual chose to interpret this as follows:

“To avoid ambiguity, whenever the phrase “stakeholder or customer requirements” is used in this Manual, the reader should assume what is meant is “stakeholder-owned or customer-owned system requirements”. This distinction is important in that “stakeholder, user, or customer needs” represent a stakeholder, user, or customer perspective of what they need the SOI to do while the “stakeholder-owned”, “user-owned”, or “customer-owned” system requirements are a different perspective that communicates what the stakeholders, users, or customers require the SOI to do to meet their needs. In this context, the stakeholder-owned, user-owned, or customer-owned system requirements are transformed from the stakeholder needs, user needs, or customer needs. Often, the requirements from the customer included in a contract with a supplier are “customer-owned system requirements”.”

To my mind, this interpretation is based on a fundamental misreading (or perhaps it would be kinder to call it an over-interpretation) of the quoted material from ISO 29148, as that document clearly uses the term “stakeholder-owned system requirements” in a very specific and limited way that definitely does not cover the full meaning generally ascribed to “stakeholder requirements”. Specifically, ISO 29148 does not state that the stakeholder needs and requirements identified at lower levels are system requirements. Indeed, the use of “stakeholder needs” clearly implies a transformation to stakeholder requirements following the stakeholder requirements process.

A reminder, as I wrote earlier, ISO 29148 also states:

• Defining requirements begins with stakeholder needs (or goals, or objectives) that are refined and evolve before arriving as valid stakeholder requirements.

The whole point of the statement is that stakeholder needs evolve to become stakeholder requirements. In other words, they are two clearly different things that effectively represent advances in the maturity of (information about) the system of interest. It is also clear from this that stakeholder requirements are not, as the NRM has it, a subset of system requirements. If they were, then the processes would be “Stakeholder needs definition process” and “Stakeholder and System [System/Software] Requirements definition process” instead of “Stakeholder needs and requirements definition process” and “System [System/Software] Requirements definition process”.

The authors of the manual are using the term “stakeholder needs” to mean what has traditionally been called “stakeholder requirements” and using “stakeholder requirements” to define a specific subset of system requirements, again going against decades of usage. Such a drastic and unnecessary change in terminology, particularly changing the meaning of a well-understood term, is potentially catastrophic and one wonders how a profession that prides itself on removing ambiguity can have allowed this to happen.

Discussion

The following discussion is based on responses given by one of the authors of Needs and Requirements Manual, Lou Wheatcraft, and me to posts on LinkedIn. I have annotated Lou Wheatcraft’s material with [LW] and mine with [KC]. I have used Lou’s material verbatim, but in some cases have edited mine for clarity.

[LW]: the phrase comes from ISO 29148.

[KC] I guess the phrase you are referring to is “stakeholder requirements”? ISO 29148 defines these as being at the business operational level, which is not the case for system requirements. It also states:

“The Stakeholder Requirements Specification (StRS) describes the organization’s motivation for why the system is being developed or changed, defines processes and policies/rules under which the system is used and documents the top-level requirements from the stakeholders’ perspective including expressing needs of users/operators/maintainers as derived from the context of use in a specific, precise and unambiguous manner. In the context described in the BRS, the StRS describes how the organization will utilize the system as a means to contribute to the business.”

In other words, Stakeholder Requirements state the problem and the context within which it must be solved. If stakeholder requirements were just system requirements owned by stakeholders, the standards would define them as such. But that is not the case. Neither ISO 15288 nor ISO 29148 define stakeholder requirements in that way. This definition is a clear misinterpretation of what ISO 29148 states.

The definitions I use are consistent with both ISO 29148 and ISO 15288.

[LW] My interpretation is not the same as yours. I do not find it useful for me to define and manage two sets of requirements communicating the same perspective when one is all that is needed.

[KC] Although you can consider needs and stakeholder requirements as addressing the same perspective, it is better to think of needs as the draft and stakeholder requirements as the published material. Same perspective, different degrees of maturity.

[LW] I must clearly define and understand the well-formed integrated set of needs and get them baselined and agreed to. This defines the scope of the project. Then I will transform those needs into a well-formed set of system design input requirements to which I will verify the design and realized SOI against. I will, or the customer will, then validate that the verified system meets the integrated set of needs.

[KC] I don’t disagree with this. But I do disagree with the use of well-understood terminology to mean something different from what most practitioners are used to. This would be like deciding to change the meaning of strain from force per unit area to force² per unit area.

[LW] I am not trapped in the “That’s how we have always done it” argument. If I can find a more practical and effective way, I will do it, even if not per any outdated standards that may exist, especially when those standards are not accepted not practiced by all organizations involved in product development.

[KC] I agree with this, except the last clause. It is fair to say that very few standards are accepted and practised by all organizations involved in product development. However, although not all the hundreds of organizations I have worked with over the years have used the term “stakeholder requirements”, none of them has ever used it in the way the Needs and Requirements Manual does.

[LW] In advancing the state of art, we sometimes must be willing to move forward and not be held back by the past.

[KC] Also true, but this is a clear case of taking a sledgehammer and destroying a useful, nay, vital, piece of existing terminology for absolutely no benefit.

Conclusion

I cannot agree with the usage by the authors of the manual. If we accept that usage, then there is no difference between stakeholder requirements and system requirements except that the former are owned by stakeholders (and the latter have no defined owner). If this is the case, then there is no need to have separate processes to define them, yet both ISO 15288 and ISO 29148 do have distinct processes for each.

There is no valid reason to change the definition of a term that has been in use for decades. Such a change will only cause confusion and, in this case at least, provides no benefit whatsoever.

Written with StackEdit.

---

1. One of the ironies of a typical functional specification was that the non-functional requirements section was bigger than the functional requirements section. ↩︎