Difference between revisions of "Stakeholder Needs Definition"

From SEBoK
Jump to navigation Jump to search
(RWG draft work in process)
Tag: visualeditor
(RWG draft work in process)
Tag: visualeditor
Line 39: Line 39:
  
 
=== Inputs to the Stakeholder Needs Definition Process ===
 
=== Inputs to the Stakeholder Needs Definition Process ===
−
The inputs from the Business or Mission Analysis process includes:
+
The inputs from the Business or Mission Analysis process includes: Identification of major stakeholders, definition of the problem, threat or opportunity space, eaboration of the mission, goals, objectives (MGOs) and measures defining project    success, capture of preliminary life cycle concepts, and identification of initial concepts of the solution space, including alternatives.
−
 
 
−
* 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 life cycle concepts
 
−
* Identification of initial concepts of the solution space, including alternatives
 
−
* Traceability of strategic problems/threats/opportunities and MGOs/measures to the    preferred alternative solution classes
 
−
* Confirmation of organization support
 
  
 
=== Activities of the Process ===
 
=== Activities of the Process ===
 
Major activities and tasks performed during this process include the following:
 
Major activities and tasks performed during this process include the following:
−
* Capture the inputs on problem/threat/opportunity, mission/goals/objectives/measures, initial life cycle concepts, major stakeholders, initial solution classes coming from the Mission or Business Analysis processes.
 
 
* Identify additional stakeholders or classes of stakeholders across the life cycle.
 
* Identify additional stakeholders or classes of stakeholders across the life cycle.
 
* Elicit, capture, consolidate and prioritize stakeholder needs and expectations.
 
* Elicit, capture, consolidate and prioritize stakeholder needs and expectations.
Line 59: Line 50:
 
*Identify the needs associated with people and processes.
 
*Identify the needs associated with people and processes.
 
* Synthesize, baseline, and manage the Integrated Set of Needs.
 
* Synthesize, baseline, and manage the Integrated Set of Needs.
−
The activities behind each of these are described in the following sections.  Additional resources for performing these activities are captured in the References section.
+
The activities behind each of these are described in the following sections.  Additional resources for performing these activities are captured in the INCOSE Needs and Requirements Manual (shown in the References section).
  
−
=== Identify Stakeholders and Elicit Needs ===
+
=== 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 {{Term|Life Cycle (glossary)|life cycle}} concepts across the lifecycle 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
 +
|-
 +
|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 include stakeholder(s) 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 involved in some way 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 life cycle 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|verification]] and [[System Validation|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 life cycle stages the stakeholder represents
 +
* For each life cycle stage, obtain input on expected and off-nominal use cases or 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 consquence
 +
* 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 and stakeholder-owned requirements 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 depending on the needs of the project team members.
 +
 +
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 ===
 
=== Identify Drivers and Constraints ===
 +
Drivers and constraints are things outside the project’s control that constrain or drive the solution space and represent a major source of needs and requirements that drive and constrain the lifecycle concepts analysis and maturation activities as well as the solution space available to the design team.    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.  n a data-centric approach, the drivers and constraints can be included in the MBSE system model, wand trace to the life cycle concepts and inputs for development of the integrated set of needs.  
  
 
=== Identify, Assess and Handle Risk ===
 
=== 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.   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.
  
−
Identify potential {{Term|Risk (glossary)|risks}} (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see [[Risk Management]]).
+
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]]).
  
−
=== Lifecycle Concepts Analysis and Maturation ===
+
Risks could also lead to development of life cycle concepts as part of the mitigation (such as for hazards), which are expanded up further in the next section.
  
 +
=== Life Cycle Concepts Analysis and Maturation ===
 +
 +
 +
 +
Models and diagrams are excellent analysis tools for defining and maturing feasible lifecycle concepts by providing a context for needs and requirements and are key to help ensure correctness, completeness, and consistency of both individual needs and requirements and sets of needs and requirements.  As part of lifecycle concept maturation, functions are defined and relationships between those functions (interactions and interfaces) are identified.  From this knowledge, functional flow block diagrams can be developed as well as context diagrams, boundary diagrams, and external interface diagrams.  
 +
 +
These 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 and requirements dealing with functions, performance, and interactions between the subsystems and system elements within the system physical architecture as well as between the system and external systems in its operational environment.  
 +
 +
This analysis may involve the use of functional flow diagrams, timeline analysis, N2 Diagrams, design reference missions, modeling and simulations, movies, pictures, states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies. 
 +
 +
* Simulations and visualizations
 +
* Prototyping
 +
* Modeling
 +
* Use case diagrams
 +
* Activity diagrams
 +
* Functional flow block diagrams
  
 
=== Identify Needed People and Processes ===
 
=== Identify Needed People and Processes ===
Line 95: Line 165:
 
[[System Requirements]] definition process.
 
[[System Requirements]] definition process.
  
−
[new section, still in work]
 
−
 
−
original material:
 
  
−
===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 stakeholder needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.
 
−
*Refine the OpsCon and other life-cycle concepts (acquisition concept, deployment concept, support concept, and retirement concept).
 
−
*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 the [[System Requirements]] article.
 
−
* Validate the content and the relevance of each stakeholder requirement with corresponding stakeholder representatives providing {{Term|Rationale (glossary)|rationale (glossary)}} for the existence of the requirement.
 
−
* Identify potential {{Term|Risk (glossary)|risks}} (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see [[Risk Management]]).
 
−
* Synthesize, record, and manage the stakeholder requirements and potential associated risks.
 
  
−
===Artifacts, Methods and Modeling Techniques===
 
  
−
===Identifying Stakeholders===
 
−
Stakeholders of a SoI may vary throughout the {{Term|Life Cycle (glossary)|life cycle}}. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the {{Term|Life Cycle Model (glossary)|life cycle model}} when identifying the stakeholders or classes of stakeholders.
 
  
−
Every system has its own stages of life, which typically include stages such as 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 must be 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.
+
original material:
−
{|
 
−
|+'''Table 1. Stakeholder Identification Based on Life Cycle Stages.''' (SEBoK Original)
 
−
!Life Cycle Stage
 
−
!Example of Related Stakeholders
 
−
|-
 
−
|Engineering
 
−
|Acquirer, panel of potential users, marketing division, research and development department, standardization body, suppliers, verification and validation team, production system, regulator/certification authorities, etc.
 
−
|-
 
−
|Development
 
−
|Acquirer, suppliers (technical domains for components realization), design engineers, integration team, etc.
 
−
|-
 
−
|Transfer for Production or for Use
 
−
|Quality control, production system, operators, etc.
 
−
|-
 
−
|Logistics and Maintenance
 
−
|Supply chain, support services, trainers, etc.
 
−
|-
 
−
|Operation
 
−
|Normal users, unexpected users, etc.
 
−
|-
 
−
|Disposal
 
−
|Operators, certifying body, etc.
 
−
|}
 
  
−
===Identifying Stakeholder Needs===
 
−
Once business management is satisfied that their needs and requirements are reasonably complete, they pass them on to the business operations team. Here, the Stakeholder Needs and Requirements (SNR) Definition Process uses the ConOps, or Strategic Business Plan (SBP), and the life-cycle concepts as guidance.  The requirements engineer (RE) or business analyst (BA) leads stakeholders from the business operations layer through a structured process to elicit stakeholder needs—in the form of a refined OpsCon (or similar document) and other life-cycle concepts.  The RE or BA may use a fully or partially structured process to elicit specific needs, as described in models such as user stories, use cases, scenarios, system concepts, and operational concepts.
 
  
−
===Identifying Stakeholder Requirements===
+
==Practical Considerations==
−
Stakeholder needs are transformed into a formal set of stakeholder requirements, which are captured as models or documented as textual requirements in and output typically called a Stakeholder Requirement Specification (StRS), Stakeholder Requirement Document (StRD) or similar.  That transformation should be guided by a well‐defined, repeatable, rigorous, and documented process of requirements analysis. This requirements analysis may involve the use of functional flow diagrams, timeline analysis, N2 Diagrams, design reference missions, modeling and simulations, movies, pictures, states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies.
 
−
 
 
−
===Collecting Stakeholder Needs and Requirements===
 
−
There are many ways to collect stakeholder needs and requirements. 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
 
−
* Technical, operational, and/or strategy documentation review
 
−
* Simulations and visualizations
 
−
* Prototyping
 
−
* Modeling
 
−
* Feedback from [[System Verification|verification]] and [[System Validation|validation]] processes,
 
−
* Review of the outcomes from the [[System Analysis|system analysis]] process (ISO/IEC 2015)
 
−
* Quality function deployment (QFD) - can be used during the needs analysis and is a technique for deploying the "voice of the customer”.  It provides a fast way to translate customer needs into requirements. (Hauser and Clausing 1988)
 
−
* Use case diagrams (OMG 2010)
 
−
* Activity diagrams (OMG 2010)
 
−
* Functional flow block diagrams (Oliver, Kelliher, and Keegan 1997)
 
  
−
=== From the Capture of Stakeholder Needs to the Definition of Stakeholder Requirements ===
 
−
Several steps are necessary to understand the maturity of stakeholder needs and to understand how to improve upon that maturity. Figure 1 presents the ''cycle of needs ''as it can be deduced from Professor Shoji Shiba's and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering (SE) purposes.
 
−
[[File:SEBoKv05_KA-SystDef_Cycle_of_needs.png|centre|thumb|600x600px|
 
−
'''Figure 1. Cycle of Needs (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.
 
−
]]
 
−
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 (Faisandier 2012); to illustrate this, consider this example of a system related to infectious disease identification:
 
−
* '''Real needs '''are those that lie behind any perceived needs (see below); 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.''Often, real needs appear to be simple tasks.
 
−
* '''Perceived needs '''are based on a person’s awareness that something is wrong, that something is lacking, that improvements could be made, or that there are business, investment, or market opportunities that are not being capitalized upon. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see [[Business or Mission Analysis]]). 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 a solution or to make attaining 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 ''Systems and software engineering - Requirements engineering '' (ISO 2011). Characteristics of good requirements can be found in (ISO 2011). 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 potential future SoI.
 
−
* '''Specified needs''', are the translation of the stakeholder needs to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. Specified needs are translated into system requirements. Consistent practice has shown this process requires {{Term|Iteration (glossary)|iterative}} and {{Term|Recursion (glossary)|recursive}} steps in parallel with other life cycle processes through the system design hierarchy (ISO 2011).
 
−
* '''Realized needs '''are the product, service, or enterprise realized, taking into account every specified need (and hence, the retained needs).
 
−
Each class of needs listed above aligns with an area of the SE 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).
 
−
 
−
===Classification of Stakeholder Requirements===
 
−
Several classifications of stakeholder requirements are possible, e.g. ISO/IEC 29148, section 9.4.2.3 (ISO 2011) provides a useful set of elements for classification. Examples of classification of stakeholder requirements include: service or functional, operational, interface, environmental, human factors, logistical, maintenance, design, production, verification requirements, validation, deployment, training, certification, retirement, regulatory, environmental, reliability, availability, maintainability, design, usability, quality, safety, and security requirements. Stakeholders will also be faced with a number of constraints, including: enterprise, business, project, design, realization, and process constraints.
 
−
 
−
==Practical Considerations==
 
  
  
Line 207: Line 201:
 
|}
 
|}
 
</center>
 
</center>
−
 
  
 
Proven practices with stakeholder requirements are presented in Table 4.
 
Proven practices with stakeholder requirements are presented in Table 4.

Revision as of 20:16, 23 November 2023

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

The second activity performed in concept definition after Business or Mission Analysis is called "Stakeholder Needs Definition", which explores what capabilities are needed by various stakeholders for the system-of-interestsystem-of-interest (SoI) to accomplish the mission.

Note that Business or Mission Analysis 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 validationvalidation, as well as input into the System Requirements definition process.

Purpose and Definition

The initial effort of SoI development is to establish the problem space, which is used as inputs into the design process.  As shown in Figure 1, prior to the establishment of requirements there is an activity to gather the needs.  These needs are assessed from multiple analysis activities, resulting in an Integrated Set of Needs that includes stakeholder needs, risks, drivers, constraints, and the results from life cycle concepts analysis and maturation effort.

[figure 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 life cycle concepts analysis and maturation.  Figure from INCOSE Needs and Requirements Manual v1.1, Figure 1-2.

The establishment of the needs forms the basis of a full understanding of the capabilities expected of the SoI, and is 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 and Mission Analysis [link to page] 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 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 life cycle concepts, and identification of initial concepts of the solution space.

[insert figure 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 to ensure the system-of-interest (SoI)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 life cycle concepts analysis and maturation (shown in Figure 2); this effort results in an Integrated Set of Needs. [glossary term addition].

[insert Figure 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 life cycle concepts analysis and maturation.  Figure from INCOSE Needs and Requirements Manual v1.1, Figure 4-5.

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 part of 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, eaboration of the mission, goals, objectives (MGOs) and measures defining project success, capture of preliminary life cycle concepts, and identification of initial concepts of the solution space, including alternatives.

Activities of the Process

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

  • Identify additional stakeholders or classes of stakeholders across the life cycle.
  • Elicit, capture, consolidate and prioritize stakeholder needs and expectations.
  • Identify drivers and constraints on the SoI and its development efforts.
  • Identify potential risksrisks (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see Risk Management).
  • Mature and analyze the life-cycle concepts (acquisition concept, deployment concept, support concept, and retirement concept).
  • Identify the needs associated with people and processes.
  • Synthesize, baseline, and manage the Integrated Set of Needs.

The activities behind each of these are described in the following sections. Additional resources for performing these activities are 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 life cyclelife cycle concepts across the lifecycle 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
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 include stakeholder(s) 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 involved in some way 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 life cycle 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 verification and 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 life cycle stages the stakeholder represents
  • For each life cycle stage, obtain input on expected and off-nominal use cases or 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 consquence
  • 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 and stakeholder-owned requirements 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 depending on the needs of the project team members.

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 the project’s control that constrain or drive the solution space and represent a major source of needs and requirements that drive and constrain the lifecycle concepts analysis and maturation activities as well as the solution space available to the design team.    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. n a data-centric approach, the drivers and constraints can be included in the MBSE system model, wand trace to the life cycle concepts and inputs for development of 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.   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 life cycle concepts as part of the mitigation (such as for hazards), which are expanded up further in the next section.

Life Cycle Concepts Analysis and Maturation

Models and diagrams are excellent analysis tools for defining and maturing feasible lifecycle concepts by providing a context for needs and requirements and are key to help ensure correctness, completeness, and consistency of both individual needs and requirements and sets of needs and requirements.  As part of lifecycle concept maturation, functions are defined and relationships between those functions (interactions and interfaces) are identified.  From this knowledge, functional flow block diagrams can be developed as well as context diagrams, boundary diagrams, and external interface diagrams.  

These 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 and requirements dealing with functions, performance, and interactions between the subsystems and system elements within the system physical architecture as well as between the system and external systems in its operational environment.  

This analysis may involve the use of functional flow diagrams, timeline analysis, N2 Diagrams, design reference missions, modeling and simulations, movies, pictures, states and modes analysis, fault tree analysis, failure modes and effects analysis, and trade studies.

  • Simulations and visualizations
  • Prototyping
  • Modeling
  • Use case diagrams
  • Activity diagrams
  • Functional flow block diagrams

Identify Needed People and Processes

Define and Baseline the Integrated Set of Needs

Outputs of the Process

This process may create several artifacts, such as:

  • Recommendations to refine the Business Requirement Specification (if necessary)
  • Refined life-cycle concepts (OpsCon, acquisition concept, deployment concept, support concept, and retirement concept)
  • Stakeholder requirements (in the form of a model or a document containing textual requirements, such as the Stakeholder Requirement Specification)
  • Stakeholder interview reports
  • Stakeholder requirements database
  • Stakeholder requirements justification documents (for traceability purposes)
  • Input for draft verification and validation plans

The content, format, layout and ownership of these artifacts will vary depending on who is creating them and in which domains they will be used. Between these artifacts and the outputs of the process, activities should cover the information identified in the first part of this article.

System Requirements definition process.



original material:


Practical Considerations

original material:

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

Table 3. Major Pitfalls for Stakeholder Requirements. (SEBoK Original)
Pitfall Description
Operator Role Not Considered Sometimes engineers do not take into account the humans acting as operators inside a system or those who use the system and are outside of the system. As a consequence, elements are forgotten (e.g. roles of operators).
Exchanges with External Objects Forgotten The exhaustiveness of requirements can be an issue; in particular, the interfaces with external objects of the context of the system can be forgotten (exchanges of matter, energy, information).
Physical Connections with External Objects Forgotten Within the interface issue, physical connections of the system-of-interest with external objects can be forgotten (technological constraints).
Forgotten Stakeholders Stakeholders can be forgotten, as everyone thinks of direct users, customers, and suppliers; however, one may fail to consider those who do not want the system to exist and malevolent persons.

Proven practices with stakeholder requirements are presented in Table 4.

Table 4. Stakeholder Requirements Proven Practices. (SEBoK Original)
Practice Description
Involve Stakeholders Involve the stakeholders early in the stakeholder requirements development process.
Presence of Rationale Capture the rationale for each stakeholder requirement.
Analyze Sources before Starting Complete stakeholder requirements as much as possible before starting the definition of the system requirements.
Modeling Techniques Use modeling techniques as indicated in sections above.
Requirements Management Tool Consider using a requirements management tool. This tool should have the capability to trace linkages between the stakeholder requirements and the system requirements and to record the source of each stakeholder requirement.

References

Works Cited

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

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

Primary References

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. 2015. 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.

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

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

OMG. 2010. OMG Systems Modeling Language specification, version 1.2. Needham, MA: Object Management Group. July 2010.

Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY, USA: McGraw-Hill.

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

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

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

Relevant Videos

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Stakeholder_Needs_Definition&oldid=70398"