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