Stakeholder Needs Definition

Introduction

It is assumed that the definition of the problem or the issue to be solved and/or the opportunity for developing or improving a System of Interest has been done when entering the definition of formalized Stakeholder Requirements. This means that the context of use of the System of Interest has been characterized (see Mission Analysis and Marketing Analysis topic), or the Physical Architecture of the parent system considered as the context of use of the concerned system has been defined (see Physical Architecture Design topic).

The Stakeholder Requirements represent the view of the users, acquirers, and customers of the problem or of the opportunity, through a set of requirements for a system that can provide the services needed by the acquirer, users, and other stakeholders in a defined environment. This topic provides knowledge about the notion of stakeholder requirement, and the related systems engineering activities and methods. The set of Stakeholder Requirements represents one of the major outcomes of these activities.

Purpose and definition

The purpose of Stakeholder Requirements definition is to consolidate the initial engineering elements related to a System of Interest, or those related to a system or a System Element defined in the context of the physical architecture of a parent system; and to formalize a set of needs, expectations, goals or objectives into clear, concise, and verifiable stakeholder requirements.

The distinction between stakeholder requirements and needs is related to which system is concerned; for example, a stakeholder requirement for a system may be allocated to a software element of the system, viewed as needs by the supplier of this software element, and further elaborated as (a) requirement(s) for this software element.

Principles and concepts

From capture of needs to Stakeholder Requirements definition

Several steps are necessary to state the maturity of the needs, from "real needs" to reaching a realized solution (that could be called "realized needs"). 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 purposes.

FIGURE 1 Figure 1 – Cycle of needs

Figure 1 shows these steps and the position of the Stakeholder Requirements and System Requirements in the engineering cycle:

1. 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 “identify infectious diseases easily”. It often looks like a simple action.
2. 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 / market opportunities. Perceived needs are often presented as a list of more or less organized expectations, often resulting from an analysis of the usage conditions for the considered action (see Mission Analysis and Marketing Analysis topic). Following on from the example above, the real need might be perceived as a need to "carry out medical tests in particular circumstances (laboratories, point of care, hospital, human dispensary)". Since the real need is seldom expressed, the 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.
3. Expressed needs originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. For example, if safety is the top concern, the expressed need “Protect the operator against contamination” may take priority over other expressed needs, such as “Assist in the execution of tests.” Here the analysis of the expected mission or services in terms of Operational Scenarios takes place.
4. Retained needs are selected from a more or less important number of expressed needs. The selection uses the prioritization of expressed needs in order to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions for a System-of-Interest. The retained needs are generally called "Stakeholder Requirements,” and exploration of potential solutions must start from this step. 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 future System of Interest.
5. Specified needs, generally called “ System Requirements”, are the translation of the Stakeholder Requirements to represent the view and expression of the supplier of the problem or opportunity, having in mind potential feasible solutions. The expression of System Requirements means that potential solutions as systems exist or can be developed, manufactured, or bought.
6. Realized needs are the Product, Service or Enterprise realized, taking into account every System Requirement (and hence Stakeholder Requirement).

Stakeholders and their requirements

Needs, expectations, objectives are collected through stakeholders' interviews (including user surveys), technical documents, feedback from the Verification Process and the Validation Process, and from outcomes of the System Analysis Process. (ISO/IEC. 2008)

Stakeholder Requirements are developed from these needs. To get a complete set of Stakeholder Requirements, it is necessary to consider the System of Interest or the parent system in various stages across its typical life cycle. Every system has its own stages of life; these may include transfer for use or deployment, normal use in operation, production, maintenance, and disposal. For each stage, a list of all actors having an interest in the future system is identified. Those actors are called Stakeholders. The aim is to get every stakeholder point of view for every stage of the system life in order to establish the list of Stakeholder Requirements as exhaustively as possible.

Examples of Stakeholders are provided in Table 1.

TABLE 1 Table 1 – Stakeholders Identification Based on Life Cycle Stages

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 interesting elements for classification. These classifications of Stakeholder Requirements have the goal to facilitate the classification of System Requirements and, subsequently, to prepare the design and validation activities. One possible way to classify the Stakeholder Requirements is under the following categories as indicated in Table 2.

TABLE 2 Table 2 – Example of Stakeholder Requirements classification

Process Approach

Purpose

The purpose of the Stakeholder Requirements Definition Process is to identify all needs and expectations from every stakeholder (acquirer, users and others) and to define clear, concise, and verifiable Stakeholder Requirements.

Generic inputs are concept of operation and/or mission definition, market studies, preliminary stakeholder needs and expectations, business models, etc.

Generic output is a set of consistent Stakeholder Requirements.

Activities of the Process

Major activities and tasks performed during this process include:

1. Elicit, capture or consolidate the stakeholders' needs, expectations, objectives or requirements coming from Mission and Marketing Analysis of the System of Interest.
2. And/or consolidate the stakeholder requirements applicable to the concerned system or System Element coming from the physical architecture of the parent system.
3. Analyze the acquirers’ and users' needs and define corresponding Stakeholder Requirements.
4. Explore, analyze, and identify needs and expectations of the other stakeholders (the list of the stakeholders depends on the system life cycle), including various life cycle constraints.
5. Verify quality, completeness of each Stakeholder Requirement and consistency of the set of Stakeholder Requirements.
6. Validate content and relevance of each Stakeholder Requirement with corresponding stakeholder representative providing Rational (glossary) of the existence of the requirement.
7. Identify potential Risks (or threats and hazards) that could be generated by the Stakeholder Requirements.
8. Synthesize, record and manage the Stakeholder Requirements and potential associated Risks.

Artifacts and Ontology Elements

This process may create several artifacts such as:

1. Stakeholder Requirements Document
2. Stakeholder Interview Report
3. Stakeholder Requirements Database
4. Stakeholder Requirements Justification Document (for traceability purpose)

This process handles the ontology elements of Table 3.

TABLE 3 Table 3 – Main ontology elements within stakeholder requirements definition

Methods and Modeling Techniques

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

• Structured workshops with brainstorming
• Interviews and questionnaires
• Technical documentation review
• Simulations, prototyping, and modeling
• Organizational analysis techniques (e.g., Strengths, Weaknesses, Opportunities, Threats - SWOT analysis, product portfolio)
• Quality Function Deployment (QFD), which can be used during the needs analysis. QFD is a technique for deploying the "Voice of the Customer.” It provides a fast way to translate customer needs into requirements.
• Use Case Diagram of SysML (OMG. 2010)
• Activity Diagram of SysML (OMG. 2010)
• Functional Flow Block Diagram, etc.

Practical Considerations

Major pitfalls encountered with Stakeholder Requirements are presented in Table 4.

TABLE 4 Table 4 – Major pitfalls

Proven practices with Stakeholder Requirements are presented in Table 5.

TABLE 5 Table 5 – Major proven practices