Difference between revisions of "Stakeholder Needs Definition"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(233 intermediate revisions by 17 users not shown)
Line 1: Line 1:
−
====Introduction====
+
----
 +
'''''Lead Author:''''' ''Tami Katz,'' '''''Contributing Authors:''''' ''Lou Wheatcraft, Mike Ryan''
 +
----
 +
 
 +
''Stakeholder Needs Definition'', the second process in Concept Definition, explores what {{term|Capability (glossary)|capabilities}} are needed by various stakeholders for the {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) to accomplish the mission. 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. 
  
 +
Note that the first process, Business or Mission Analysis, is often performed iteratively with Stakeholder Needs Definition to better understand the problem, threat, or opportunity space, as well as options of the solution space. 
 +
==Purpose and Definition==
  
−
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).
+
{{term|Stakeholder Needs and Requirements (glossary)|Stakeholder needs}} represent a user, acquirer, customer, and other {{term|Stakeholder (glossary)|stakeholders}} perspective of the SoI, which are then transformed into {{term|System Requirement (glossary)|system requirements}} which communicate a developer perspective of the SoI. When stakeholder needs are combined with results of multiple analysis activities that includes risks, drivers, constraints, and life cycle concepts analysis, as shown in Figure 1, the result is an overall integrated set of needs.
  
−
The [[Stakeholder Requirement (glossary) |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.
+
[[File:Figure StkhldrNeeds-1 from INCOSE NRM.jpg|thumb|900px|center|'''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 life cycle concepts analysis and maturation.''' This figure is reprinted with permission of Lou Wheatcraft and Mike Ryan. All other rights are reserved by the copyright owner.]]
  
−
====Purpose and definition====
+
The establishment of the integrated set 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 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 results of the [[Business or Mission Analysis]] is provided as inputs into 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) and measures of success used as the criteria for assessing project success, along with identification of major stakeholders, initial life cycle concepts, and initial concepts of the solution space (architecture and design).
  
−
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.
+
[[File:Figure StkhldrNeeds-2 SEBoK Original.jpg|thumb|900px|center|'''Figure 2.''' '''Stakeholder Needs Definition expands upon the Business or Mission Analysis results to refine the set of needs for the System of Interest.''' (SEBoK Original)]]
  
−
==Principles and concepts==
+
The Stakeholder Needs Definition process continues the life cycle concepts definition activities to ensure the {{Term|System-of-Interest (glossary)|system-of-interest (SoI)}} provides the capabilities needed by users and other stakeholders in the intended operational environment.  This process is much more than identification and elicitation of need or requirement statements from various stakeholders, it consists of a series of analysis activities done to ensure that all parameters are captured, including risks, drivers, constraints, as well as the SoI life cycle concepts analysis and maturation; this effort results in an integrated set of needs as shown in Figure 3.
  
−
===From capture of needs to Stakeholder Requirements definition===
+
[[File:Figure StkhldrNeeds-3 from INCOSE NRM.jpg|thumb|900px|center|'''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 life cycle concepts analysis and maturation.''' This figure is reprinted with permission of Lou Wheatcraft. All other rights are reserved by the copyright owner.]] 
  
−
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.
+
The result of this process is a well-formed integrated set of needs that is correct, consistent, complete, and feasible.  It is this set of needs that defines the scope of the project which the organization agrees to provide the resources necessary for developing the SoI, and against which the requirements, design, and the realized SoI will be validated against.  
  
−
<center> FIGURE 1 </center>
+
=== '''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 an integrated set of stakeholder needs.  The term "stakeholder requirements" is considered a set of requirements on the SoI established by the stakeholder, as transformed from their needs, which are provided as additional input towards the life cycle concepts analysis and maturation activities from which the integrated set of needs is defined.  In Figure 3, this is designated as both "stakeholder needs, requirements, and expectations" as well as the "higher-level requirements" inputs.
  
−
<center>Figure 1 – Cycle of needs</center>
+
==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, elaboration of the MGOs and measures of success, capture of preliminary life cycle concepts, and identification of initial concepts of the solution space (architecture and design).
  
−
Figure 1 shows these steps and the position of the Stakeholder Requirements and System Requirements in the engineering cycle:
+
=== Activities of the Process ===
−
#'''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.
+
There are several activities performed during this process:
−
#'''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.
+
* Identify additional stakeholders or classes of stakeholders across the life cycle.
−
#'''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.
+
* Elicit, capture, consolidate and prioritize stakeholder needs, requirements, and expectations.
−
#'''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.
+
* Identify drivers and constraints on the SoI and its development efforts.
−
#'''Specified needs''', generally called “[[System Requirement (glossary) | 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.
+
* Identify potential {{Term|Risk (glossary)|risks}} (such as threats and hazards) that could prevent the SoI from successful operation (see [[Risk Management]] for further information on addressing risks).
−
#'''Realized needs''' are the Product, Service or Enterprise realized, taking into account every System Requirement (and hence Stakeholder Requirement).
+
* Mature and analyze the life cycle concepts.
 +
* Identify, baseline, and manage the integrated set of needs.
 +
The activities behind each of these are described in the following sections.
  
−
===Stakeholders and their requirements===
+
=== Identify Stakeholders ===
  
−
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)
+
Stakeholders are the primary source of needs and requirements, therefore for the project to be successful, all relevant stakeholders must be identified and included from 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 life cycle; therefore, considering the {{Term|Life Cycle (glossary)|life cycle}} concepts provides a thorough source for stakeholder identification.  Examples of stakeholders are provided in Table 1.
 +
{| class="wikitable"
 +
|+'''Table 1. Stakeholder Identification Based on Life Cycle Stages.''' (SEBoK Original)
 +
!Life Cycle Stage
 +
!Example of Related Stakeholders
 +
|-
 +
|Concept
 +
|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
 +
|}
  
−
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.
+
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 include stakeholders that are responsible for formally certifying, qualifying, and approving the system for use in its operational environment by its intended users.  There can be approving authorities both within and external to the organization, especially for highly-regulated systems.  
  
−
Examples of Stakeholders are provided in Table 1.
+
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. It is recommended that the project team re-evaluate the stakeholder community periodically to ensure successful engagement with stakeholders, keeping them engaged across all life cycle activities, 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, requirements, and expectations for all life cycle stages. The elicitation activities allow the project team to discover what is needed, what processes exist, how stakeholders interact with the SoI, what happens over the SoI’s life cycle from their perspective (examples are provided below). 
  
−
<center> TABLE 1 </center>
+
It is recommended that several techniques or methods be considered during elicitation activities to better accommodate the diverse set of sources (INCOSE NRM 2022):
 +
* 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, and
 +
* feedback from [[System Verification]] and [[System Validation]] processes.
 +
A broad range of topics are discussed with the stakeholders:
  
−
<center>Table 1 – Stakeholders Identification Based on Life Cycle Stages</center>
+
* Obtain feedback on the outputs from the Business and Mission Analysis process (problem, threat, opportunity, MGOs, etc.).
 +
* Identify the life cycle stages the stakeholder represents and their role.
 +
* For each life cycle stage, obtain input on expected and off-nominal use cases, scenarios, misuse cases, and loss scenarios.
 +
* Identify the 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 provide rationale for and prioritize what they are asking for.  Some needs will be especially important to the stakeholder, while others may be “nice-to-haves” and not critical to the system being able to accomplish its intended use.  There will be some things that the stakeholder may be able to “live without” given budget or schedule constraints.  Providing rationale often reveals the real need, especially when the stakeholder expresses a need as an implementation.
  
−
===Classification of Stakeholder Requirements===
+
The information obtained from the elicitation activities needs to be recorded with trace to the stakeholder register.  In a [[Model-Based Systems Engineering (MBSE)]] effort, the elicited needs can be included in the MBSE system model and traced to the stakeholders. 
  
−
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.
+
=== 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.
−
<center> TABLE 2 </center>
 
−
 
 
−
<center>Table 2 – Example of Stakeholder Requirements classification</center>
 
−
 
 
−
==Process Approach==
 
  
−
===Purpose===
+
Concurrently with the stakeholder elicitation activities, drivers and constraints need to be identified and recorded within the SoI’s integrated dataset. 
  
−
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.
+
=== Identify, Assess, and Handle Risk ===
  
−
'''Generic inputs''' are concept of operation and/or mission definition, market studies, preliminary stakeholder needs and expectations, business models, etc.
+
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.  
  
−
'''Generic output''' is a set of consistent Stakeholder Requirements.
+
As part of the elicitation activities, issues and risks 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 along with how the project is expected to handle those risks. 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|system validation]].  
  
 +
The project must do a risk assessment of each of the risks (see [[Risk Management]]).  Some risks could lead to development of life cycle concepts as part of the mitigation (such as for hazards), which are expanded further in the next section.
  
−
===Activities of the Process===
+
=== Life Cycle Concepts Analysis and Maturation ===
  
−
Major activities and tasks performed during this process include:
+
As a result of life cycle concept analysis and maturation activities, architectural and analytical/behavioral models are developed.  Based on the resulting information, the preliminary set of life cycle {{term|Operational Concept (glossary)|concepts}} established in [[Business or Mission Analysis]] are transformed into a mature set of life cycle concepts that are consistent, correct, complete, and feasible.  Models and diagrams (such as those used in [[Model-Based Systems Engineering (MBSE)]] are excellent analysis tools for defining and maturing feasible life cycle 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.
−
#Elicit, capture or consolidate the stakeholders' needs, expectations, objectives or requirements coming from Mission and Marketing Analysis of the System of Interest.
 
−
#And/or consolidate the stakeholder requirements applicable to the concerned system or System Element coming from the physical architecture of the parent system.
 
−
#Analyze the acquirers’ and users' needs and define corresponding Stakeholder Requirements.
 
−
#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.
 
−
#Verify quality, completeness of each Stakeholder Requirement and consistency of the set of Stakeholder Requirements.
 
−
#Validate content and relevance of each Stakeholder Requirement with corresponding stakeholder representative providing [[Rationale (glossary)]] of the existence of the requirement.
 
−
#Identify potential [[Risk (glossary) | Risks]] (or threats and hazards) that could be generated by the Stakeholder Requirements.
 
−
#Synthesize, record and manage the Stakeholder Requirements and potential associated Risks.
 
  
−
===Artifacts and Ontology Elements===
+
The {{Term|Logical Architecture (glossary)}} defines {{term|System Boundary (glossary)|system boundary}} and {{term|Function (glossary)|functions}}, from which more detailed needs can be determined (interactions and interdependencies between logical elements of the system).  As part of life cycle concept maturation, functions are defined, grouped logically, and relationships and interactions between those functions are captured. Supporting analytical and behavioral models can be developed to help assess behavior, interactions between parts of the architecture, and determine the performance characteristics of the functions.  
  
−
This process may create several artifacts such as:
+
=== Define and Baseline the Integrated Set of Needs ===
−
#Stakeholder Requirements Document
+
The project team derives an integrated set of needs that reflect the set of feasible system life cycle concepts, MGOs, measures, business operations level and system level stakeholder needs, drivers and constraints, and risk mitigation (Figure 4).  These outcomes include results of the life cycle 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.
−
#Stakeholder Interview Report
 
−
#Stakeholder Requirements Database
 
−
#Stakeholder Requirements Justification Document (for traceability purpose)
 
  
−
This process handles the ontology elements of Table 3.
+
[[File:Figure StkhldrNeeds-4 from INCOSE NRM.jpg|thumb|900px|center|'''Figure 4. Input into the integrated set of needs.''' This figure is reprinted with permission of Lou Wheatcraft. 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 design input requirements, design, and realized system will be validated against.
  
−
<center> TABLE 3 </center>
+
Needs are written in a structured, natural language from the perspective of what the stakeholders need the SoI to do. To help distinguish needs from the requirements, the needs statements do not include the word “shall” (or other word that depicts the statement is a requirement). It is recommended that need statements use a different format from requirements, such as: “The stakeholders need the system to” (INCOSE GtWR 2023).  See Table 2 for example need statements.
 +
{| class="wikitable"
 +
|+'''Table 2. Example Need Statements.''' (SEBoK Original)
 +
!ID
 +
!Name
 +
!Need Statement
 +
!Rationale
 +
!Source
 +
|-
 +
|N1
 +
|Variable Temperature Settings.
 +
|The user needs the coffee maker to have two temperature settings (warm and  hot) for the water temperature.
 +
|Focus groups provided input that a multi-select option for temperature is  a desired feature.
 +
|Consumer input
 +
|-
 +
|N2
 +
|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.
 +
|Risk mitigation
 +
|-
 +
|N3
 +
|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.
 +
|Marketing stakeholder
 +
|-
 +
|N4
 +
|Ease of Use
 +
|The user needs the coffee maker to be easy to use (clearly defined user interface and a minimum of steps to get a cup of coffee).
 +
|Focus groups provided input that they are more likely to purchase  products with simple user interfaces and operation controls.
 +
|Consumer input
 +
|}
 +
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 their needs, requirements, expectations, MGOs, measures, drivers and constraints, and risk are properly communicated by integrated set of needs, this is supported by traceability.  In a {{term|Model-Based Systems Engineering (MBSE) (glossary)|model-based systems engineering (MBSE)}} approach, the needs can be included in the system model, where they can be traced to their source (life cycle, stakeholder, MGO, risk, etc.).
  
−
<center>Table 3 – Main ontology elements within stakeholder requirements definition</center>
+
Once the integrated set of needs is captured, they are used as inputs into the [[System Requirements Definition]] process.
  
 +
==References==
 +
===Works Cited===
  
−
===Methods and Modeling Techniques===
+
INCOSE. 2022. ''INCOSE Needs and Requirements Manual'', version 1.1. INCOSE-TP-2021-002-01.
−
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
+
INCOSE. 2022. ''INCOSE Guide to Needs and Requirements'', version 1. INCOSE-TP-2021-003-01.
−
*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.
 
  
 +
INCOSE. 2023. ''INCOSE Guide to Writing Requirements (GtWR)'', version 4. INCOSE-TP-2006-004-04.
  
−
==Practical Considerations==
+
===Primary References===
−
Major pitfalls encountered with Stakeholder Requirements are presented in Table 4.
+
INCOSE. 2022. ''INCOSE Needs and Requirements Manual'', version 1.1. INCOSE-TP-2021-002-01.
  
−
<center> TABLE 4 </center>
+
INCOSE. 2022. ''INCOSE Guide to Needs and Requirements'', version 1. INCOSE-TP-2021-003-01.
  
−
<center>Table 4 – Major pitfalls</center>
+
INCOSE. 2023. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'', version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
  
−
Proven practices with Stakeholder Requirements are presented in Table 5.
+
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.
  
−
<center> TABLE 5 </center>
+
ISO/IEC/IEEE. 2023. ''[[ISO/IEC/IEEE 15288|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.
  
−
<center>Table 5 – Major proven practices</center>
+
===Additional References===
 +
INCOSE. 2023. ''INCOSE Guide to Writing Requirements'', version 4. INCOSE-TP-2006-004-01.
 +
===Relevant Videos===
 +
*[https://youtu.be/hEGfNLvuyXo?list=PLVfZ7HbxxzBVnavoSAMUXjP49triK36KN INCOSE Webinar, Life cycle Concepts and Needs Definition]
 +
*[https://www.youtube.com/watch?v=YJ4wCbKJeXY How to Get Project Requirements from Project Stakeholders]
 +
----
 +
<center>[[Business or Mission Analysis|< Previous Article]] | [[System Concept Definition|Parent Article]] | [[System Requirements Definition|Next Article >]]</center>
  
 +
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
  
−
==Citations==
+
[[Category: Part 3]][[Category:Topic]]
−
==Primary References==
+
[[Category:System Concept Definition]]
−
==Additional References and Readings==
 

Latest revision as of 23:20, 2 May 2024

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

Stakeholder Needs Definition, the second process in Concept Definition, explores what capabilitiescapabilities are needed by various stakeholders for the system-of-interestsystem-of-interest (SoI) to accomplish the mission. 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.

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

Purpose and Definition

Stakeholder needsStakeholder needs represent a user, acquirer, customer, and other stakeholdersstakeholders perspective of the SoI, which are then transformed into system requirementssystem requirements which communicate a developer perspective of the SoI. When stakeholder needs are combined with results of multiple analysis activities that includes risks, drivers, constraints, and life cycle concepts analysis, as shown in Figure 1, the result is an overall integrated set of needs.

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 life cycle concepts analysis and maturation. This figure is reprinted with permission of Lou Wheatcraft and Mike Ryan. All other rights are reserved by the copyright owner.

The establishment of the integrated set 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 as inputs into 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) and measures of success used as the criteria for assessing project success, along with identification of major stakeholders, initial life cycle concepts, and initial concepts of the solution space (architecture and design).

Error creating thumbnail: File missing
Figure 2. Stakeholder Needs Definition expands upon the Business or Mission Analysis results to refine the set of needs for the System of Interest. (SEBoK Original)

The Stakeholder Needs Definition process continues the life cycle concepts definition activities to ensure the system-of-interest (SoI)system-of-interest (SoI) provides the capabilities needed by users and other stakeholders in the intended operational environment. This process is much more than identification and elicitation of need or requirement statements from various stakeholders, it consists of a series of analysis activities done to ensure that all parameters are captured, including risks, drivers, constraints, as well as the SoI life cycle concepts analysis and maturation; this effort results in an integrated set of needs as shown in Figure 3.

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 life cycle concepts analysis and maturation. This figure is reprinted with permission of Lou Wheatcraft. All other rights are reserved by the copyright owner.

The result of this process is a well-formed integrated set of needs that is correct, consistent, complete, and feasible. It is this set of needs that defines the scope of the project which the organization agrees to provide the resources necessary for developing the SoI, and against which the requirements, design, and the realized SoI will be validated against.

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 an integrated set of stakeholder needs. The term "stakeholder requirements" is considered a set of requirements on the SoI established by the stakeholder, as transformed from their needs, which are provided as additional input towards the life cycle concepts analysis and maturation activities from which the integrated set of needs is defined. In Figure 3, this is designated as both "stakeholder needs, requirements, and expectations" as well as the "higher-level requirements" inputs.

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, elaboration of the MGOs and measures of success, capture of preliminary life cycle concepts, and identification of initial concepts of the solution space (architecture and design).

Activities of the Process

There are several activities performed during this process:

  • Identify additional stakeholders or classes of stakeholders across the life cycle.
  • Elicit, capture, consolidate and prioritize stakeholder needs, requirements, and expectations.
  • Identify drivers and constraints on the SoI and its development efforts.
  • Identify potential risksrisks (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 life cycle concepts.
  • Identify, baseline, and manage the integrated set of needs.

The activities behind each of these are described in the following sections.

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 from 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 life cycle; therefore, considering the life cyclelife cycle concepts provides a thorough source for stakeholder identification. Examples of stakeholders are provided in Table 1.

Table 1. Stakeholder Identification Based on Life Cycle Stages. (SEBoK Original)
Life Cycle Stage Example of Related Stakeholders
Concept 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

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 include stakeholders that are responsible for formally certifying, qualifying, and approving the system for use in its operational environment by its intended users. There can be approving authorities both within and external to the organization, especially for highly-regulated systems.

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. It is recommended that the project team re-evaluate the stakeholder community periodically to ensure successful engagement with stakeholders, keeping them engaged across all life cycle activities, 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, requirements, and expectations for all life cycle stages. The elicitation activities allow the project team to discover what is needed, what processes exist, how stakeholders interact with the SoI, what happens over the SoI’s life cycle 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 (INCOSE NRM 2022):

  • 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, and
  • feedback from System Verification and System Validation processes.

A broad range of topics are discussed with the stakeholders:

  • Obtain feedback on the outputs from the Business and Mission Analysis process (problem, threat, opportunity, MGOs, etc.).
  • Identify the life cycle stages the stakeholder represents and their role.
  • For each life cycle stage, obtain input on expected and off-nominal use cases, scenarios, misuse cases, and loss scenarios.
  • Identify the 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 provide rationale for and prioritize what they are asking for.  Some needs will be especially important to the stakeholder, while others may be “nice-to-haves” and not critical to the system being able to accomplish its intended use.  There will be some things that the stakeholder may be able to “live without” given budget or schedule constraints. Providing rationale often reveals the real need, especially when the stakeholder expresses a need as an implementation.

The information obtained from the elicitation activities needs to be recorded with trace to the stakeholder register. In a Model-Based Systems Engineering (MBSE) effort, the elicited needs can be included in the MBSE system model and traced to the stakeholders.

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 recorded within the SoI’s integrated dataset.

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.

As part of the elicitation activities, issues and risks 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 along with how the project is expected to handle those risks. 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 risks (see Risk Management).  Some risks could lead to development of life cycle concepts as part of the mitigation (such as for hazards), which are expanded further in the next section.

Life Cycle Concepts Analysis and Maturation

As a result of life cycle concept analysis and maturation activities, architectural and analytical/behavioral models are developed.  Based on the resulting information, the preliminary set of life cycle conceptsconcepts established in Business or Mission Analysis are transformed into a mature set of life cycle concepts that are consistent, correct, complete, and feasible.  Models and diagrams (such as those used in Model-Based Systems Engineering (MBSE) are excellent analysis tools for defining and maturing feasible life cycle 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.

The logical architecturelogical architecture defines system boundarysystem boundary and functionsfunctions, from which more detailed needs can be determined (interactions and interdependencies between logical elements of the system). As part of life cycle concept maturation, functions are defined, grouped logically, and relationships and interactions between those functions are captured. Supporting analytical and behavioral models can be developed to help assess behavior, interactions between parts of the architecture, and determine the performance characteristics of the functions.  

Define and Baseline the Integrated Set of Needs

The project team derives an integrated set of needs that reflect the set of feasible system life cycle concepts, MGOs, measures, business operations level and system level stakeholder needs, drivers and constraints, and risk mitigation (Figure 4).  These outcomes include results of the life cycle 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.

Figure 4. Input into the integrated set of needs. This figure is reprinted with permission of Lou Wheatcraft. 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 design input requirements, design, and realized system will be validated against.

Needs are written in a structured, natural language from the perspective of what the stakeholders need the SoI to do. To help distinguish needs from the requirements, the needs statements do not include the word “shall” (or other word that depicts the statement is a requirement). It is recommended that need statements use a different format from requirements, such as: “The stakeholders need the system to” (INCOSE GtWR 2023). See Table 2 for example need statements.

Table 2. Example Need Statements. (SEBoK Original)
ID Name Need Statement Rationale Source
N1 Variable Temperature Settings. The user needs the coffee maker to have two temperature settings (warm and hot) for the water temperature. Focus groups provided input that a multi-select option for temperature is a desired feature. Consumer input
N2 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. Risk mitigation
N3 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. Marketing stakeholder
N4 Ease of Use The user needs the coffee maker to be easy to use (clearly defined user interface and a minimum of steps to get a cup of coffee). Focus groups provided input that they are more likely to purchase products with simple user interfaces and operation controls. Consumer input

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 their needs, requirements, expectations, MGOs, measures, drivers and constraints, and risk are properly communicated by integrated set of needs, this is supported by traceability. In a model-based systems engineering (MBSE)model-based systems engineering (MBSE) approach, the needs can be included in the system model, where they can be traced to their source (life cycle, stakeholder, MGO, risk, etc.).

Once the integrated set of needs is captured, they are used as inputs into 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.

INCOSE. 2023. INCOSE Guide to Writing Requirements (GtWR), version 4. INCOSE-TP-2006-004-04.

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.

INCOSE. 2023. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 5.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

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

INCOSE. 2023. INCOSE Guide to Writing Requirements, version 4. INCOSE-TP-2006-004-01.

Relevant Videos

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Stakeholder_Needs_Definition&oldid=71892"