Stakeholder Needs Definition

---

Lead Author: Tami Katz, Contributing Authors: Lou Wheatcraft, Mike Ryan

---

Stakeholder Needs Definition, the second activity in concept definition, explores what capabilities are needed by various stakeholders for the system-of-interest (SoI) to accomplish the mission.

Note that the first activity, Business or Mission Analysis process, is often performed iteratively with Stakeholder Needs Definition to better understand the problem (or opportunity) space, as well as options of solution space.

The outcome of the Stakeholder Needs Definition process is used as the basis of system validation, as well as input into the System Requirements Definition process.

Purpose and Definition

Stakeholder needs represent the views of those at the business or enterprise operations level—that is, of users, acquirers, customers, and other stakeholders as they relate to the problem (or opportunity). These are often referred to as "stakeholder needs and requirements", where the stakeholder establishes what they need and communicate as a form of needs from the stakeholder perspective which are then transformed into system requirements from the system perspective (note that this article captures stakeholder requirements as a matured form of the stakeholder needs, as discussed in the Nomenclature section below). When stakeholder needs are combined with results of multiple analysis activities that includes risks, drivers, constraints, and lifecycle concepts analysis, as shown in Figure 1, the result is an overall Integrated Set of Needs.

[Insert figure StkhldrNeeds-1 here]

Figure 1. Establishment of an Integrated Set of Needs ensures that all perspectives are analyzed during the Stakeholder Need Definition process, including risks, drivers, constraints, and lifecycle concepts analysis and maturation.  This figure is derived from the INCOSE Needs and Requirements Manual v1.1, Figure 1-2, reprinted with permission of INCOSE. All other rights are reserved by the copyright owner.

The establishment of needs forms the basis of a full understanding of the capabilities expected of the SoI, and these needs are ultimately transformed into a set of design-input requirements on the SoI as part of the System Requirements Definition process.

Principles and Concepts

The results of the Business or Mission Analysis is provided to the project team to complete the rest of the process of SoI concept definition using the Stakeholder Needs Definition process (shown in Figure 2). This input includes the problem, threat or opportunity statement capturing why the project is worth doing, the mission, goals and objectives (MGOs) used as the criteria for project success, along with identification of major stakeholders, initial lifecycle concepts, and initial concepts of the solution space.

[Insert figure StkhldrNeeds-2 here]

Figure 2. Stakeholder Needs Definition expands upon the Business or Mission Analysis results to refine the set of needs for the SoI.  Original SEBoK figure.

The Stakeholder Needs Definition process continues the concept definition effort to ensure the system-of-interest (SoI) will provide the capabilities needed by users and other stakeholders in a defined environment. This process is much more than identification and elicitation of need statements from various stakeholders, it consists of a series of analysis steps done to ensure that all parameters are captured, including risks, drivers, constraints, as well as the SoI lifecycle concepts analysis and maturation; this effort results in an Integrated Set of Needs as shown in Figure 3.

[Insert figure StkhldrNeeds-3 here]

Figure 3. Establishment of an Integrated Set of Needs ensures that all perspectives are analyzed during the Stakeholder Need Definition process, including risks, drivers, constraints, and lifecycle concepts analysis and maturation.  This figure is derived from the INCOSE Needs and Requirements Manual v1.1, Figure 4-5, reprinted with permission of INCOSE. All other rights are reserved by the copyright owner.

The result of this process is a comprehensive set of needs representing all stakeholders and life cycle concepts, which are used as the basis of generating design-input requirements for the SoI.

Nomenclature discussion

This process is frequently referred to as the "Stakeholder Needs and Requirements" process. Because various guides, textbooks, and standards refer to stakeholder “expectations, needs, and requirements” as if they are the same, resulting in confusion as to what is an “expectation” versus a “need” and a “requirement”, this article focuses on the process of developing a full set of stakeholder needs. The term "stakeholder requirement" is considered a set of requirements on the SoI established by the stakeholder, as transformed from their needs, which is provided as additional input towards the generation of the Integrated Set of Needs. In Figure 3, this is designated as the "higher-level requirements" input, consisting of the stakeholder-owned set of requirements on the SoI.

Process Approach

Inputs to the Stakeholder Needs Definition Process

The inputs from the Business or Mission Analysis process includes identification of major stakeholders, definition of the problem, threat or opportunity space, elaboration of the mission, goals, objectives (MGOs) and measures defining project success, capture of preliminary lifecycle concepts, and identification of initial concepts of the solution space.

Activities of the Process

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

• Identify additional stakeholders or classes of stakeholders across the lifecycle.
• Elicit, capture, consolidate and prioritize stakeholder needs and expectations.
• Identify drivers and constraints on the SoI and its development efforts.
• Identify potential risks (such as threats and hazards) that could prevent the SoI from successful operation (see Risk Management for further information on addressing risks).
• Mature and analyze the lifecycle concepts.
• Identify, baseline, and manage the Integrated Set of Needs.

The activities behind each of these are described in the following sections. Additional guidance for performing these activities is captured in the INCOSE Needs and Requirements Manual (shown in the References section).

Identify Stakeholders

Stakeholders are the primary source of needs and requirements, therefore for the project to be successful, all relevant stakeholders must be identified and included at the beginning of the project. Leaving out a relevant stakeholder often results in missing needs and requirements and a failure to pass system validation.  Stakeholders can include, but are not limited to, customers, sponsors, organization decision makers, regulatory organizations, developing organizations, integrators, testers, users, operators, maintainers, support organizations, the public at large (within the context of the business and proposed solution), and those involved in the disposal or retirement of the SoI.  Stakeholders can be both internal and external to the organization. There can be many stakeholders for a SoI over its lifecycle; therefore, considering the lifecycle concepts provides a thorough source for stakeholder identification. Examples of stakeholders are provided in Table 1.

Table 1. Stakeholder Identification Based on Lifecycle Stages. (SEBoK Original)

Lifecycle Stage	Example of Related Stakeholders
Engineering	Paying customer, sponsor, project team, project manager, procurement, research and development, suppliers, regulating authorities, public, marketing, end users, operators, compliance office, regulators, owners of enabling systems, owners of external systems, Approving Authorities
Development	Acquirer, subject matter experts (SMEs), system architects, design engineers, suppliers, procurement, suppliers (technical domains for components realization), integration team
Production, Integration, Verification and Validation	Production organization, process engineers, quality control, production verification, product acceptance, supply chain, test engineers, system integration engineers, system verification engineers, system validation engineers, operators/users, owners of enabling systems, facility personnel, contracting, Approving Authorities, regulators, safety personnel, security personnel
Logistics and Maintenance	Customer/technical support, replacement part providers, service technicians, trainers, IT, quality engineer, inspectors, those conducting post development system verification and system validation activities
Operation	Normal users, unexpected users, etc.
Disposal	Operators, waste management, regulators, public

Often there will be multiple members of a stakeholder group, e.g., users, operators, marketing, sales, safety, regulators, customers, the “public” who will be buying, using, operating, or maintaining a product or may be affected by the product in some way. It may not be practical to collaborate with every member of the group to elicit their needs, identification of a person to represent that group will provide a way to ensure that perspective is addressed. A key part of stakeholder identification is to determine who the Approving Authorities are within the group of stakeholders.  It cannot be assumed that the only stakeholder that has this authority is the "customer". The Approving Authorities additionally include stakeholders that are responsible for formally certifying, qualifying, and approving the system for use in its operational environment by its intended users.

An approach for recording the list of stakeholders is to use a stakeholder register that includes key information for each stakeholder and how they are involved with the SoI.  In a data-centric approach, the register can be included in the MBSE system model, where the stakeholders are identified along with their viewpoints and connection to the lifecycle stage.

It is recommended that the project team re-evaluate the stakeholder community periodically to ensure successful engagement with stakeholders, keeping them engaged, and managing changes in stakeholders and their needs.

Stakeholder Needs Elicitation

For stakeholder needs elicitation, the project team engages the stakeholders to understand their needs and technical requirements not only just during operations but for all lifecycle stages. The elicitation activities allow the project team to discover and understand what is needed, what processes exist, how stakeholders interact with the SoI, what happens over the SoI’s lifecycle from their perspective (examples are provided below). It is recommended that several techniques or methods be considered during elicitation activities to better accommodate the diverse set of sources, including:

• Structured brainstorming workshops.
• Interviews and questionnaires.
• Workshops or Focus groups.
• Use of visual and descriptive content associated with the SoI.
• Technical, operational, and/or strategy documentation review.
• Feedback from System Verification and System Validation processes.

Topics to discuss with the stakeholders include:

• Feedback on the outputs from the Business and Mission Analysis process (problem/threat/opportunity, MGOs, etc.)
• Identify the lifecycle stages the stakeholder represents.
• For each lifecycle stage, obtain input on expected and off-nominal use cases, scenarios, misuse cases, and loss scenarios.
• Identify desired capabilities and functions from their perspective.
• Identify interactions with external systems.
• Obtain input on their view of quality and other "ilities", such as reliability, testability, serviceability, etc.
• Inquire about their view of risks and hazards, along with likelihood and consequence.
• For each need, capture rationale concerning "why".
• Ask about criticality of the stated needs, and relative priorities of all inputs obtained.

During elicitation activities, it is important to ask the stakeholders to prioritize what they are asking for.  Some things will be especially important to the stakeholder, while other things may be “nice-to-haves” or “desires”, but not critical to the system being able to achieve the agreed to mission, goals, and objectives.  There will be some things that the stakeholder may be able to “live without” given budget or schedule constraints.

Not all stakeholders are equal.  Based on their position and role, some stakeholders have more “power” and influence than others (for example, customers and the Approving Authorities).  In this case, higher ranked stakeholder’s needs will have more importance (higher priority) than lower ranked stakeholders.  Higher-ranked stakeholders often have a broader perspective and think at a higher level of abstraction than other stakeholders.  

The information obtained from the elicitation activities needs to be recorded with trace to the stakeholder register. In a data-centric approach, the elicited needs can be included in the MBSE system model, traced to the modeled stakeholders. A major benefit of practicing SE from a data-centric perspective is the increased use of models as analysis tools to both establish traceability between artifacts as well as enable the ability to view the information within the SoI’s integrated dataset from different perspectives The individual outcomes from the elicitation activities represent the unique perspective of a stakeholder or group of stakeholders.  These perspectives will be analyzed and integrated into an integrated set of needs.

Identify Drivers and Constraints

Drivers and constraints are things outside of the project’s control that constrain or drive the solution space.  Drivers and Constraints can include design constraints (parts, materials, organizational design best practices, etc.), design standards, production constraints (existing technology, facilities, equipment, cost, throughput, etc.), human factors, (human/machine interface - HMI), regulations (law), operating environment (natural, induced), other environment (social, cultural), existing systems: (interactions, interfaces, dependencies), technology maturity, cost, schedule.

Concurrently with the stakeholder elicitation activities, drivers and constraints need to be identified and be recorded within the SoI’s integrated dataset. In a data-centric approach, the drivers and constraints can be included in the MBSE system model, traced to the lifecycle concepts, and used as inputs for developing the integrated set of needs.  

Identify, Assess, and Handle Risk

Risks are anything that could prevent the delivery of a successful SoI (providing what is needed, within budget and schedule, with the needed quality), anything that could impact the intended use of the SoI in its intended environment by its intended users, or anything that would allow unintended users to prevent the intended use of the SoI or to use the SOI in an unintended manner, e.g., hack into an aircraft and use the aircraft as a weapon. Risks can be classified as management, development, production, verification and validation, compliance, and operational.

As part of the elicitation activities, issues and risk must be identified and assessed. The identified risks from the Business or Mission Analysis effort should be used as a starting point, and then additional elaboration of risks is needed. Stakeholders should be asked specifically about any issues and risk they think could prevent the SoI to be developed and delivered within budget, schedule, or risk during operations.  Failing to address risk will result in an incomplete set of needs and resulting design input requirements resulting in a SoI that will fail system validation.

The project must do a risk assessment of each of the classes of risk discussed above.  For each class of risk, the identified risks need to be recorded within the SoI’s integrated dataset and handled (accepted, monitored, researched, or mitigated) during the system lifecycle concepts analysis and maturation activities (for further information, see Risk Management).

Risks could also lead to development of lifecycle concepts as part of the mitigation (such as for hazards), which are expanded further in the next section.

Lifecycle Concepts Analysis and Maturation

As a result of lifecycle concept analysis and maturation activities, architectural and analytical/behavioral models are developed.  Based on the resulting information, the preliminary set of lifecycle concepts established in Business or Mission Analysis are transformed into a mature set of lifecycle concepts that are consistent, correct, complete, and feasible.  Models and diagrams are excellent analysis tools for defining and maturing feasible lifecycle concepts by providing a context for needs, and are key to help ensure correctness, completeness, and consistency of both individual needs and the integrated set of needs, as described in Model-Based Systems Engineering (MBSE). 

The logical architecture defines system boundary and functions, from which more detailed needs can be determined (interactions and interdependencies between logical elements of the system). As part of lifecycle concept maturation, functions are defined and relationships between those functions (interactions and interfaces) are captured.  From this knowledge, visualizations such as functional flow block diagrams can be developed as well as other representations such as context diagrams, boundary diagrams, and external interface diagrams, to depict the functions and their inputs and outputs and interactions between the SoI and external systems and its environment. At this lifecycle stage, the focus is on levels of abstraction and decomposition.  Initially, high-level functions are defined, e.g., “Process Inputs”. Then that function is decomposed into subfunctions, that together result in the parent function being realized, e.g., “Receive inputs”.  “Store Raw Inputs”, “Transform Inputs”, “Store Transformed Inputs”, “Display Transformed Inputs”, “Export Transformed Inputs”.  

Identified functions can then be transformed into a functional architecture and analytical/behavioral models which can, in turn, be transformed into a physical architecture. These models are excellent sources of needs addressing expected capabilities, features, functions, performance, and interactions between the elements within the SoI physical architecture as well as between the SoI and external systems in its operational environment.  This integrated model can then be used during early system verification and system validation activities as well as during design verification and design validation using simulations to uncover issues before the SoI is built or coded.

As the models mature, functions are decomposed, lower-level architectures are defined, and subfunctions, performance, quality, physical attributes are allocated to the lower-level system elements. Supporting analytical/behavioral models can be developed to help assess behavior, interactions between parts of the architecture, and determine the “how well” performance characteristics of the functions.  

Defining and agreeing on a set of feasible lifecycle concepts for the SoI enables the project team to define an integrated set of needs based on those concepts.

Define and Baseline the Integrated Set of Needs

In accordance with the definition of a “need”, the project team derives an integrated set of needs that reflect the set of feasible system lifecycle concepts, MGOs, measures, business operations level and system level stakeholder needs, drivers and constraints, and risk mitigation. The integrated set of needs represent the agreed to outcomes of the stakeholder needs elicitation activities, definition of drivers and constraints, and lifecycle analyses and maturation activities, as shown in Figure 4.  These outcomes include results of the lifecycle concepts analysis and maturation activity to determine expected functionality (what the stakeholders need the system to do), expected performance and quality (“how well” characteristics), the conditions of action, including triggering events, system states, and operating environments (“under what operating conditions”), as well as compliance with standards and regulations.

[Insert figure StkhldrNeeds-3 here]

Figure 4. Input into the Integrated Set of Needs.  This figure is derived from the INCOSE Needs and Requirements Manual v1.1, Figure 4-12, reprinted with permission of INCOSE. All other rights are reserved by the copyright owner.

This integrated set of needs is what will be transformed into the set of design input requirements.  In addition, it is this integrated set of needs which the set of requirements, the design, the set of design output specifications (such as drawings), and the realized system will be validated against.

Needs are written in a structured, natural language from the perspective of the what the stakeholders need the SoI to do, while system requirements are written from the perspective of what the SoI must do to meet the need(s) from which they were transformed. To help distinguish needs from the requirements, the needs statements do not include the word “shall”, it is recommended to use a different format, such as: “The stakeholders need the system to ……….”. See Table 2 for example need statements.

Table 2. Example of Need Statements. (SEBoK Original)

ID	Name	Need Statement	Rationale	Category	Source
N1	Variable Temperature Settings.	The user needs the coffee maker to have three temperature settings (warm, hot, extra hot) for the water temperature.	Focus groups provided input that a multi-select option for temperature is a desired feature.	Function/Performance	Consumer input
N2	Variable Brew Size Options	The user needs the coffee maker to have three brew size options for the completed coffee.	Focus groups provided input that a multi-select option for varying the coffee size is a desired feature.	Function/Performance	Consumer input
N3	Automatic Brew Stop Capability	The user needs the coffee maker to stop making coffee once the requested brew size has been made.	Expected function in operation lifecycle.	Function/Performance	Lifecycle concept
N4	Prohibit Brew if Container Missing	The user needs the coffee maker to not brew unless a coffee container is in place.	Mitigation of risk of user error prior to starting coffee maker brew process.	Function/Performance	Risk mitigation
N5	Brew Time	The user needs the coffee to brew within five minutes of triggering the Start Brew feature.	Focus groups provided input that a quick brew feature is more likely to sell.	Function/Performance	Consumer input
N6	Electrical Standard Compliance	The user needs the coffee maker to comply with the UL 1082 standard.	Regulatory standard to ensure safe operation in the United States.	Compliance	Regulation
N7	Coffee Maker Color Options	The company stakeholders need the coffee maker to come in four colors: black, grey, blue and red.	Marketing survey found that offering multiple colors provides competitive advantage with consumers.	Form	Marketing stakeholder
N8	Operating Life	The company stakeholders need the coffee maker to last 3 years.	Coffee maker needs to last the warranty period plus one year to ensure company brand positive impression.	Quality	Business stakeholder
N9	Ease of Use	The user needs the coffee maker to be easy to use (simple interfaces, simple programming).	Focus groups provided input that they are more likely to purchase products with simple user interfaces and operation controls.	Fit	Consumer input

To help with the development and organization of the requirements that will be transformed from the integrated set of needs, it is useful to organize the integrated set of needs into the following groupings: function/performance, fit, form, quality, and compliance.

The integrated set of needs must be recorded within the SoI’s integrated dataset in a form and media suitable for review and feedback from the stakeholders, as well as a form that allows traceability.  It is critical that the project team has confirmation from the stakeholders that the project team understands their expectations, needs, MGOs, measures, drivers and constraints, and risk as communicated by integrated set of needs. Traceability is critical in support of needs verification and needs validation as well as change assessment and management. In a model-based systems engineering (MBSE) approach the needs can be included in the system model, where they are traced to their source (lifecycle model, stakeholder model, etc.).

Once the integrated set of needs is captured, the output from this effort is used to start the System Requirements Definition process.

References

Works Cited

INCOSE. 2022. INCOSE Needs and Requirements Manual, version 1.1. INCOSE-TP-2021-002-01.

INCOSE. 2022. INCOSE Guide to Needs and Requirements, version 1. INCOSE-TP-2021-003-01.

Primary References

INCOSE. 2022. INCOSE Needs and Requirements Manual, version 1.1. INCOSE-TP-2021-002-01.

INCOSE. 2022. INCOSE Guide to Needs and Requirements, version 1. INCOSE-TP-2021-003-01.

ISO/IEC/IEEE. 2018. 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. 2023. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

Additional References

OMG MBSE Wiki: omgwiki.org

Relevant Videos

• INCOSE Webinar, Lifecycle Concepts and Needs Definition
• How to Get Project Requirements from Project Stakeholders

---

< Previous Article | Parent Article | Next Article > SEBoK v. 2.9, released 20 November 2023