Stakeholder Needs Definition

It is assumed that the definition of the problem or the issue to be solved and/or the opportunity for developing a new solution or improving a system of interest (SoI) has been done prior to starting the activities necessary to define stakeholder needs and requirements. This means that the context of use of the new or modified mission, operation, or capability has been characterized (see the Mission Analysis topic).

The stakeholder requirements represent the views of users, acquirers, and customers regarding the problem (or opportunity), through a set of requirements for a solution that can provide the services needed by the acquirer, users, and other stakeholders in a defined environment. This topic provides knowledge about the idea of stakeholder needs and requirements, and the activities necessary to identify and prioritize the needs of the stakeholder(s), as well as transform those needs into stakeholder requirements. The definition of the set of stakeholder requirements is the primary outcome of these activities, and these requirements then feed into the next phase of the systems engineering (SE) process of System Definition.

Purpose and Definition

The purpose of defining stakeholder requirements is to elicit a set of needs related to a new or changed mission operation for an enterprise (see Mission Analysis (MA) for information relevant to identifying and defining the mission or operation), and to transform these needs into clear, concise, and verifiable stakeholder requirements.

Stakeholder needs analysis is the elicitation, communication, validation , and refinement of the needs and objectives of the enterprise or set of stakeholders (typically including customer, users, and interacting organizations within an enterprise). Stakeholder needs analysis is aimed at understanding a potential capability (often identified through MA) that is needed to address an identified problem or opportunity. After defining the stakeholder needs and requirements, they interact with the MA to transform the defined set of needs into stakeholder requirements (also known as mission requirements) that reflect these needs.

Principles and Concepts

From the Capture of Needs to the Definition of Stakeholder Requirements

Several steps are necessary to understand the maturity of stakeholder needs and understand how to improve upon that maturity. Figure 1 presents the “Cycle of Needs” as it can be deduced from Professor Shoji Shiba and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering (SE) purposes.

Figure 1. Cycle of Needs (Faisandier 2012) Reprinted with permission of © Alain Faisandier.

Figure 1 shows the steps and the position of the stakeholder requirements and system requirements in the engineering cycle. Below are explanations of each stage of requirements; to illustrate this, an example of a system related to infectious disease identification is provided. (Faisandier 2012)

Real needs are those that lie behind any perception, and indeed may not be perceived at all; they are conditioned by the context in which people live. As an example, a generic need could be the ability to “identify infectious diseases easily.” It often looks like a simple task.
Perceived needs are based on a person’s awareness (possibly imperfect) that something is wrong, that there is a lack of something, that there is something that could improve a situation, or that there are business, investment, or market opportunities. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see the Mission Analysis topic). Following from the infectious disease example above, the real need might be perceived as a need to "carry out medical tests in particular circumstances (laboratories, points of care, hospitals, and/or human dispensaries).” Since the real need is seldom clearly expressed, richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.
Expressed needs originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. In the example, if safety is the primary concern, the expressed need to “protect the operator against contamination” may take priority over other expressed needs such as “assist in the execution of tests.” When determining the expressed needs, the analysis of the expected mission or services in terms of operational scenarios takes place.
Retained needs are selected from the expressed needs. The selection process uses the prioritization of expressed needs to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions for a SoI. These retained “stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis, and possibly consistency and feasibility. Using the concept of operations to aid the understanding of the stakeholder intentions at the organizational level and the system operational concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements” (ISO/IEC/IEEE 29148, Requirements Engineering). Characteristics of good requirements can be found in ISO/IEC/IEEE 29148. Exploration of potential solutions must start from this step (see the Mission Analysis Topic). The various solutions suggested at this step are not yet products, but describe means of satisfying the stakeholder requirements. Each potential solution imposes constraints on the potential future SoI.
Specified needs, generally called “system requirements ,” are the translation of the stakeholder requirements to represent the views of the supplier, keeping in mind the potential preferred and feasible solutions. “The stakeholder requirements are then transformed into system requirements for the SoI, in accordance with Clauses 5.2.4, 5.2.5, and 5.2.6. Consistent practice has shown this process requires iterative and recursive steps in parallel with other life cycle processes through the system design hierarchy. The recursive application of the processes in Clause 6 will generate lower-level system element requirements.” (ISO/IEC/IEEE 29148, Requirements Engineering).
Realized needs are the product, service or enterprise realized, taking into account every system requirement (and hence, the stakeholder requirement(s)).

Each class of needs listed above aligns with an area of the systems engineering process. For example, the development of "specified needs" requirements is discussed in the System Requirements topic. For more information on how requirements are used in the systems engineering process, please see the System Definition knowledge area (KA).

Stakeholders and their Requirements

There are many ways to collect stakeholder needs, expectations, and objectives. Some of the most common techniques are interviews (including user surveys); technical, operational, and strategy document reviews; feedback from the verification and validation processes; and review of the outcomes from the system analysis process (ISO/IEC 2008). Stakeholder requirements are developed from these needs.

Stakeholders of a SoI may vary throughout the lifecycle. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the lifecycle when identifying the stakeholders or classes of stakeholders. Every system has its own stages of life; these may include concept, development, production, operations, sustainment, and retirement (for more information, please see Life Cycle Models). For each stage, a list of all stakeholders having an interest in the future system is identified. The goal is to get every stakeholder’s point of view for every stage of the system life in order to consolidate a complete set of stakeholder needs that can be prioritized and transformed into the set of stakeholder requirements as exhaustively as possible. Examples of stakeholders are provided in Table 1.

Table 1. Stakeholders Identification Based on Life Cycle Stages (Table Developed for BKCASE)

Classification of Stakeholder Requirements

Several classifications of stakeholder requirements are possible, e.g. ISO/IEC 29148, section 9.4.2.3 (ISO/IEC 2011) provides a useful set of elements for classification. One possible way to classify the stakeholder requirements is under the following categories indicated in Table 2.

Table 2. Example of Stakeholder Requirements Classification (Table Developed for BKCASE)

Process Approach

Activities of the Process

Major activities and tasks performed during this process include the following:

identify the stakeholders or classes of stakeholders across the life cycle;
elicit, capture, or consolidate the stakeholders' needs, expectations, and objectives as well as any constraints coming from MA;
prioritize the stakeholder needs;
transform the prioritized and retained stakeholder needs into stakeholder requirements;
verify the quality of each stakeholder requirement and of the set of stakeholder requirements using the characteristics of good requirements identified in Tables 4 and 5 in System Requirements;
validate the content and the relevance of each stakeholder requirement with corresponding stakeholder representatives providing rationale for the existence of the requirement;
identify potential risk (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see Risk Management); and
synthesize, record, and manage the stakeholder requirements and potential associated risks.

Artifacts and Ontology Elements

This process may create several artifacts, such as:

stakeholder requirements documents;
stakeholder interview reports;
stakeholder requirements database; and
stakeholder requirements justification documents (for traceability purposes).

This process handles the ontology elements of Table 3.

Table 3. Main ontology elements as handled within stakeholder requirements definition (Table Developed for BKCASE)

Methods and Modeling Techniques

It is recommended that several techniques or methods for identifying needs, expectations, and requirements are considered during the elicitation activity to better accommodate the diverse set of requirements sources, including the following:

structured brainstorming workshops;
interviews and questionnaires;
technical, operational, and/or strategy documentation review;
simulations and visualizations;
prototyping;
modeling;
quality function deployment (QFD), which can be used during the needs analysis, and is a technique for deploying the "voice of the customer” and provides a fast way to translate customer needs into requirements;
use case diagrams (OMG 2010);
activity diagrams (OMG 2010); and
functional flow block diagrams.

Practical Considerations

Major pitfalls encountered with stakeholder requirements are presented in Table 4.

Table 4. Major pitfalls with definition of Stakeholder Requirements (Table Developed for BKCASE)

Proven practices with stakeholder requirements are presented in Table 5.

Table 5. Proven practices with definition of Stakeholder Requirements (Table Developed for BKCASE)

References

Works Cited

Faisandier, A. 2012 (in press). Engineering and Architecture Multidisciplinary Systems - a Series of guides for Practitioners.

OMG. 2010. OMG Systems Modeling Language specification, version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.

ISO/IEC/IEEE. 2011. Systems and software engineering - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.

ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).

Primary References

Buede, D.M. 2009. The engineering design of systems: Models and methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.

ISO/IEC/IEEE. 2011. Systems and software engineering - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.

ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

Additional References

MITRE. 2011. "Requirements Engineering." Systems Engineering Guide. Accessed 9 March 2012 at [[1]].

MITRE. 2011. "Stakeholder Assessment and Management." Systems Engineering Guide. Accessed 9 March 2012 at [[2]].

< Previous Article | Parent Article | Next Article >

Comments from SEBoK 0.5 Wiki

Please note that in version 0.5, this article was titled “Mission Analysis and Stakeholder Requirements”. The comments below are shared with the Mission Analysis article.

SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus