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

Process debt and Workflow

What’s going on?

How often have you completed a piece of work but were not sure of the next step, or who needs to work on it next? Or you are yourself not clear what needs to be done next? How much time gets wasted because of this lack of clarity? And what can we do to reduce this waste? This waste is known as “process debt”.

If a person has one job, always does the same thing, and always passes on the work to the same next actor (person or department), such as working on a production line, then organizing their work is fairly straightforward, at least in the sense of always knowing what needs to be done now and next. But for most of us, this is not the case. We do many different things, working with many different people. Even if you are doing the same type of work, you may be receiving it from many people and passing on the results to many different people from different groups. It is far too easy for things to fall through the cracks – you don‘t notice an email asking you to do some work, you have to hunt to find out who to send work on to, you can’t track down all the material you need to do your job and don’t know who to ask, you forget a step,…

Given that most of our working lives are following processes, it is natural to ask if there is anything we can do to make that more efficient or effective. A quote from Abraham Lincoln is appropriate here: “If I had eight hours to chop down a tree, I’d spend the first six of them sharpening my axe.”. In other words, before just jumping in and starting a task, think about the task and how it can be made more effective. We can apply the same thinking at a higher level to processes and projects, not just individual tasks.

In practice in a process, what typically happens is that some person, as an actor in the process, carries out some action to create some output. Assuming the next action is carried out by some other person (though the same applies if the same actor continues), then the original actor has to:

• know what the next action is
• know what they need to supply for the next action to be carried out
• know who has to carry it out
• inform the next actor that there is work waiting for them and where they can find the necessary material

Ideally our systems make all these things easily visible.

So what’s the problem?

Our working lives would be much simpler if we didn’t have to spend so much time looking for the answers to the questions implied at the end of the previous section. In many organizations, far too much time is spent working around problems in the way we work within our processes where there is lack of clarity about the process and specific tasks within it. The two main issues are that we don’t have a clear definition of who needs to do what and when, and much information is not easily accessible.

In my consultancy career much of my work involved helping client organizations to define their processes and implement them in software tools. It was a very common experience to be in a workshop to understand a specific process and there would be disagreement among the client staff about how the process should work, even if it was notionally documented and they were all supposed to be following it. This highlights the need to define processes clearly and, perhaps just as important, make it easy for staff to follow them.

Is there a better way?

So what is the answer? Of course, there is no single solution, and people find lots of ways around it. For example, I have personally set up Outlook so that I can turn a message into a task in a couple of clicks, and have rules so that some messages automatically get turned into tasks. I have been in several meetings where people are doing amazing things with Excel spreadsheets to track work. But these are somewhat lacking. In the first case, the gains in productivity are limited to just one person – nobody else has access to my emails and l don‘t have access to theirs, although other people could, of course, use the same approach. In the second case, the spreadsheets are manually maintained and record status and, to a limited extent, next actions. In at least one case there were three different spreadsheets in use to manage essentially the same information for slightly different purposes so the potential for conflict and confusion was massive.

Some companies are fortunate in having knowledge bases of processes and materials. But these are often limited in a number of ways:

• They document processes but do not provide any support to ensure that they are followed.
• It is often difficult to find the appropriate material within them. Searching generally throws up a mass of material that matches whatever search term you have chosen but this often finds irrelevant material where the term occurs incidentally.
• There is generally no real structure and any tagging and categorization mechanisms are not used consistently.
• They are not always maintained consistently and hence become out of date.

What we really need is a tool to manage the work of a team, where people automatically get notified of their tasks, where status reporting and passing on work to the next step is as simple as checking a box and where the information needed to do a job is maintained consistently. Fortunately, there is a multitude of such workflow management tools available, ranging from the fairly simple to full-featured.

Process definition

The start point of all such tools is process definition. A process can essentially be defined by its inputs, its outputs, and the process itself - how it transforms the inputs to the outputs. This definition is itself recursive, as each process can be decomposed into other processes until you reach something atomic such as “add one to the count of widgets produced”. We also need to define who does the work. Each of these processes is the responsibility of some actor, which may be a person or, more likely, a job role or a team. In general, the overall process involves several actors.

Unfortunately, many of our processes are not well documented, if they are documented at all, so this first step can be quite difficult. You can almost guarantee that if more than one person is following a process they will actually be doing it in different ways. I have experienced this in customer meetings when I ask the customer engineers to explain their current process. Despite all believing they follow the same process, there are almost always people saying “that’s not how we do it”.

When you start to define a process, you will probably be surprised at how many distinct steps are involved. Some people’s reaction to this is that they cannot possibly define the process as there is no way that they can do that many things. The fact, of course, is that they do those things whether they are defined or not, and not defining them is the reason that essential steps get missed. So being honest is important. Some workflow tools only use a single level of definition, others allow you to define sub-processes. Defining sub-processes is useful for two reasons. First, it allows you to create a single definition for a common sub-process that is used in many places. Second, it allows you to defer the definition of detail, adding it when it becomes useful or necessary.

Having defined a process, you might decide to optimize it, using techniques such as Value-Stream Mapping. That is outside the scope of this post, but well worth looking into.

Using the tools

Workflow tools work in many different ways, the features generally provided include:

• Individuals can quickly identify their own work
• Individuals can quickly identify work products for which they are responsible
• Automatic notification of individuals when there is work waiting for them
• Ability to see upcoming work and its current state, including who is currently working on it

Additional features often found include:

• Ability to find the status of a work product
• Ability to identify unallocated tasks that are otherwise ready to be performed
• Dashboards providing management information on status, burndown, progress, etc.
• Prioritization of activities, generically and for specific instances
• Different views including, for example, Gantt charts, Kanban
• Time tracking. This is particularly useful when companies are still using timesheets, and hence the time spent, as a metric for work done, inaccurate, misleading and damaging though this is (perhaps a topic for another post)

Benefits

Most of the benefits have been discussed above, here is a quick summary:

• Individuals and teams know what they are supposed to be working on
• Individuals and teams know what work is upcoming, so can plan ahead
• Knowledge is available to all, not hidden in spreadsheets on personal computers
• Individuals and teams are notified when work is ready
• Managers and others can see the progress of tasks and the overall status of work

In short, work becomes much more efficient and effective.

A commenter on an earlier version of this post made the point that standardisation and digital processes can support lean, but it can also make processes rigid, less agile and can stifle creativity and continuous improvement. The need is to find the middle ground somewhere, where standardisation of key processes simplifies and reduces administrative burden, while leaving some things up to qualified, competent and experienced employees giving them the freedom to change things quickly should it be needed. You need a stable foundation to start from and the flexibility to tailor processes to a team’s or client’s needs.

Choosing the right tool

It would be ideal if there was a simple way to decide which tool to use. A useful reference is https://www,makeuseof.com/online-task-management-tips-choosing-right-app/. In the end, it comes down to which tool provides the best mix of features that you need for the price you can afford. In a small organization, almost any tool will provide benefits, at the risk that it may not allow for growth. A larger organization should probably consider running pilot projects with different tools.

Origin of tools

Workflow tools come from five main disciplines, project management, software development, business process management, document control, and task management. These disciplines overlap to a greater or lesser extent, so you find tools generally support more than one.

Project management tools, such as MS Project, arose from the need for large projects to be able to manage and report on their work and progress. They generally take a very hierarchical approach and so are suitable for work that is mostly planned in advance, such as most projects, but less so for more responsive tasks such as customer service, sales, etc.

Many tools originate in the need for software development teams to control change, which essentially restricts who can do what work on what content. This has led to the need to define the flow of work and then control it. There are some very simple, but still effective, tools in this area but they are not generally useful for the larger task of managing business processes.

More sophisticated tools, such as IBM’s Engineering Workflow Manager (formerly Rational Team Concert), have grown to include project planning, Kanban, workflow, issue management, and other facilities. These provide all that is needed in a workflow tool but can be difficult to configure and use and are best suited to organizations that can clearly define their processes and have the need to coordinate many people on many different activities.

Tools originating in business process management generally start from the foundation of drawing a business process as a flow diagram. Tools that start from this basis generally develop by allowing the definition of who can do each activity and what work products are involved. These are often the tools that are best suited to an organization that is starting to understand the need for some sophistication in how it manages its processes.

Tools originating in document control are similar to those originating in business process management, with more of an original emphasis on how documents can be changed and formally issued. These often have good electronic signature capabilities.

The tools coming from task management often start with the need to manage the tasks that an individual has to carry out. They gradually add sophistication, such as task dependencies and allocating work to different people. These are often suitable for organizations getting started in process management and can often grow to be sufficient even up to fairly complex situations.

Terms

Those of you in a technical field, especially software-related, will have heard the term “technical debt” being bandied about. According to Wikipedia: “Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.” (https://en.wikipedia.org/wiki/Technical_debt).

Reflecting this Wikipedia definition I have used the term “Process Debt”, which I define as: “Process debt reflects the implied cost of additional work caused by choosing an easy solution to a process problem now instead of using a better approach that would take longer”. To understand this, we need to take a step back. Let‘s start with the Wikipedia definition of a process: “A process is a series or set of activities that interact to produce a result: it may occur once-only or be recurrent or periodic.“ (https://en.wikipedia.org/wiki/Process). So pretty much everything we do is part of a process. What l am considering here are especially those processes that we repeat and form part of our business as usual, though much the same thinking can be applied to one-off processes.

Written with StackEdit.

The Power of Three

Planning top-down and bottom-up and three levels of abstraction

If you are like most people, you have things to do, or that you want to get done, that cover a range of timescales:

• You want to retire by a certain age
• You have a project with a deadline this year
• You need to decide what to have for dinner tonight

When people talk of planning horizons, this is what they mean. The usual advice is to plan from the longer timescales to the shorter. And that is, in general, good advice. But it's not always the right thing to do. There is another way of looking at this, and that is, if you will pardon the terminology, in terms of levels of abstraction. You will almost certainly be familiar with this concept, it recurs over and over again. Some examples:

Planning a military campaign:

• What is the Objective of the campaign?
• What Strategy and Tactics will you adopt to achieve the outcome?
• What Resources do you need to implement the Tactics?

For a project:

• What is the overall Outcome’?
• What Methods will you use to deliver the outcome?
• What Resources will you need to use those Methods’?

For organizational procedures:

• What Policies do you want to follow?
• What Processes will you adopt to meet the Policies?
• What Activities make up the Processes?

In a company:

• What is the Corporate goal?
• What is the Business approach?
• What has to happen at the Functional level?

Also in a company (looked at in another dimension):

• What is the Corporate goal?
• What is the Portfolio of products (or programme of projects)?
• What Products will you create (or projects will you work on)?

And most relevant to us, for a product or system:

• What do users need (stakeholder requirements)?
• What will the system do (system requirements)?
• What is the system (design and implementation)?

Generalizing, what we have in all these examples is:

• Purpose -- Why: A definition of the outcome that is desired: the purpose (which might be a problem to be solved) and the context within which it must be delivered
• Functions -- What: A definition of what must be done to deliver the outcome
• Artefacts -- How: The detail of what needs to be used and exactly how the outcome will be delivered

Sidenote
The use of the term "Purpose" is quite deliberate. in my experience, asking people "What is the purpose?“ of something they are proposing leads to deeper thought and more meaningful answers than asking seemingly similar questions like "What is it for?“, “What is the Goal?", etc.

Each of these levels of abstraction can include more or less detail, but that's a topic for another time.

A key point here is that describing things as more or less abstract doesn't mean that they are more or less real. Retiring at a certain age is no less real than saving a certain amount of money, which is no less real than setting up a specific type of investment.

So, what does all this mean in practice? For any goal you want to reach, there is a consistent set of steps that you should follow. This is:

• Define the purpose - the desired outcome (Why)
• Determine what must be done to deliver the outcome (What)
• Investigate possible means of doing those things (options for How)
• Decide on the best means (by whatever measure of "best" is appropriate) (How)
• Do it!

So going back to our planning horizon discussion at the top, this framework lets you put the planning horizons into context. Of course, there is far more to thinking about how to achieve a goal than that. Other topics I plan to cover in future blogs include:

• Problem and Solution domains - how does this relate to the three levels of abstraction?
• Are three layers enough? Surely we need to break them down further?
• How does modelling fit into this?
• What about iterative, incremental and agile working?
• I've heard about Design Thinking, how does this fit in’?

What is "Effectiveness"

In my introductory post, I said I would write on “effectiveness” but I didn’t say what this means. This post addresses that topic.

I am fascinated by the ways in which individuals and organizations can become more effective and my goal is to help you to do that. I have studied and used many approaches, from simple “To Do” lists to more complex systems such as Stephen Covey’s 7 Habits and David Allen’s Getting things Done and concluded that none of these provides a complete answer.

Introduction

Many years (decades) ago people who had to juggle lots of tasks and priorities concentrated on time management. Then came the realisation that this focused on the wrong thing. You were not managing time, you were managing how you used time. So the emphasis changed to managing what you do and when you do it. This was perhaps exemplified by David Allen’s Getting Things Done approach. Moving on from that, you now get people talking about productivity, to me, the leaders in this field are Francis Wade, Michael Hyatt and Mike Vardy, who come at it from different directions.

One thing that is common to all the current thought leaders and experts is a focus on improving what you get out of your time. Implicit in this, though rarely stated, is not just that you want to do (achieve) the most in the time available, but that you have created the most value (however you measure value) out of that time. This is why I prefer the term “effectiveness” over “productivity”. You can be tremendously productive but be producing the wrong things.

The OED defines effectiveness as the degree to which something is successful in producing a desired result.

Have you ever asked yourself how effective is your organisation, department or team in achieving the results you want? What about your systems and processes? Is everything running as well as it should – or is there room for improvement?

Making a difference

Focusing on improvement

Every organisation has an area that would benefit from producing better results. Imagine how different things would be if everyone and everything was performing exactly the way they should…

How effective is your organisation, department or team in achieving the results you want? Is everything running as well as it should – or is there room for improvement?

Effectiveness: Improving people, processes and systems

Effectiveness is successfully producing a desired result and consistently hitting goals. What does this mean to you and your business? You may manage time well, you may be efficient, you may be productive, each of these goes part way to achieving your goals, but are you as effective as you could be? You can become more effective: whether through better cost, time and quality management; report and presentation delivery; improved product and system development, or process management.

You become more effective by being more organized, more able to use your time well and, importantly, less stressed. And there are associated benefits:

• Work becomes easier, more enjoyable and less stressful.
• People know what is expected of them, when it is expected, and what is coming up in the future.
• Individual and collective performance and productivity increase.
• Accountability improves and company morale soars.

Achieving the outcomes you want

The first step to becoming more effective - and getting the outcomes you want – is recognising that there’s room for improvement. And there is always room for improvement.

What this involves

One of the key things I have learnt is that people focus on solutions before they have understood their problems. So first you need to work to understand what is stopping you from doing what you need to be effective.

Once you understand what is blocking you, you can start to work on what the solution might be and how you can go about implementing that solution.

There is no single approach that will provide the answer for everyone because there is no single question – everyone has different problems.

You become more effective by balancing cost, time and quality through using time effectively, writing and presenting well, improving product development and management and improving the effectiveness of your processes.

And how do I do that?

As you can imagine from the above, there are lots of areas that can be improved, and each of these has several approaches that can be considered. I intend to cover some of these in future posts. I do not intend to provide a comprehensive overview of all possible approaches in all areas, particularly where specialist knowledge of processes or industries are concerned. My background is mostly in systems engineering and software so that drives what I can write about to a large extent.

Written with StackEdit.

A new blog!

I used to blog rather infrequently at https://methods-and-music.blogspot.com but I last posted there over three years ago so rather than revive that I decided to start a new blog. So here it is.

I do intend to post rather more frequently than I used to. The topics will be mostly the same - that is, whatever I feel like writing (or ranting) about. These may, or may not, include:

• Systems engineering
• Music and musicians
• Things I have read
• Effectiveness

I'm going to try to not write about politics. It's frankly too depressing with the mess of Brexit and the most incompetent, malignant, criminal government in my lifetime.