Stakeholder Needs Definition

Stakeholder requirements represent the views of users, acquirers, customers, and other stakeholders as they relate to a the problem (or opportunity), as a set of requirements for a solution that can provide the services needed by the stakeholders in a defined environment. Stakeholder requirements describe the overall objectives of the system, its principal stakeholders, its context of use, the specific needs which should be satisfied, and how success will be assessed.

Stakeholder requirements play major roles in systems engineering, as they:

• Form the basis of system requirements activities.
• Form the basis of system validation and stakeholder acceptance .
• Act as a reference for integration and verification activities.
• Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.

This topic provides knowledge about the idea of stakeholder needs and requirements which involves the activities necessary to elicit and prioritize the needs of the stakeholder(s), and transforming those needs into stakeholder requirements. The definition of the set of stakeholder requirements is the primary outcome of these activities which begin in concept definition stage. Defining the problem or the issue to be solved, identifying the opportunity for developing a new solution , or improving a system-of-interest (SoI) must begin prior to starting the activities necessary to define stakeholder needs and requirements. This means that an initial context of use of the new or modified mission, operation, or capability has already been characterized (see the Mission Analysis topic). System requirements are considered in detail during system definition. None of the above can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.

Purpose and Definition

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

stakeholder needs analysis is the elicitation, communication, validation and refinement of the needs and objectives of the enterprise or set of stakeholders. Stakeholder needs analysis is aimed at understanding a potential capability (often identified through MA) that is required to address an identified problem or opportunity. Data from the needs analysis and the MA are used to transform the defined set of needs into stakeholder requirements (also known as mission requirements) that reflect these needs.

The set of stakeholder needs, desires, and expectations may contain vague, ambiguous, and qualitative user-oriented need statements that are difficult to use for SE activities. These statements may need to be further clarified and translated into more engineering-oriented language to enable proper architecture definition and requirement activities. As an example, a need or an expectation such as, to easily maneuver a car in order to park, will be transformed in a set of stakeholder requirements to a statement such as, increase the drivability of the car, decrease the effort for handling, assist the piloting, protect the coachwork against shocks or scratch, etc.

Principles and Concepts

From the Capture of Needs to the Definition of Stakeholder Requirements

Several steps are necessary to understand the maturity of stakeholder needs and 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.

Figure 1. Cycle of Needs (Faisandier 2012). Permission granted by Singery'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 the Mission Analysis topic). Following from the infectious disease example above, the real need might be perceived as a need to carry out medical tests in particular circumstances (laboratories, points of care, hospitals, and/or human dispensaries). Since the real need is seldom clearly expressed, richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.
• Expressed needs originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. In the example, if safety is the primary concern, the expressed need to protect the operator against contamination may take priority over other expressed needs such as assist in the execution of tests. When determining the expressed needs, the analysis of the expected mission or services in terms of operational scenarios takes place.
• Retained needs are selected from the expressed needs. The selection process uses the prioritization of expressed needs to achieve 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 2011). Characteristics of good requirements can be found in ISO/IEC/IEEE 29148 (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, generally called system requirements, are the translation of the stakeholder requirements to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. Consistent practice has shown this process requires iterative and recursive steps in parallel with other life cycle processes through the system design hierarchy (ISO/IEC/IEEE 29148 2011).
• Realized needs are the product, service, or enterprise realized, taking into account every system requirement (and hence, the stakeholder requirements).

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

Identifying Stakeholders and their Requirements

Stakeholders of a SoI may vary throughout the life cycle. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the life cycle 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.

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.

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

Classification of Stakeholder Requirements

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

Table 2. Example of Stakeholder Requirements Classification. (SEBoK Original)

Type of Stakeholder Requirement	Description
Service or Functional	Sets of actions to perform the mission or operation of the system-of-interest; enhanced by effectiveness or performance characteristics attached to the mission or operations.
Operational	This category may include: Operational concepts that indicate the operational features to be provided without specifying design solutions. Operational scenarios describing the sequence or series of activities supported by the system-of-interest. Operational modes and transitions of modes between states/modes of the system-of-interest during its utilization to include dynamic interactions between the system-of-interest (viewed as a black box) and the system-of-interest's interface with external components in the context of its use.
Interface	Matter, energy, or information flows exchanged between the system-of-interest and its external components in the context of its use, including physical interfaces.
Environmental	External conditions that affect the system when in operation.
Utilization Characteristics	The '-ilities' used to indicate conditions of the utilization of the system-of-interest (e.g. usability, dependability, security, etc.).
Human Factors	Capabilities of users and operators, ergonomics, and associated constraints.
Logistical	Acquisition, transportation, and storage of elements needed by the system-of-interest to perform its services (e.g. constraints for logistical support).
Design and Realization Constraints	Reuse of existing system elements or forbidden materials, for example.
Process Constraints	These are stakeholder (usually acquirer or user) requirements imposed through the contract or statement of work. These requirements do not directly address the end-item system, but rather how the end-item system will be developed and provided. Process requirements include compliance with national, state, or local laws, such as environmental laws, administrative requirements, acquirer/supplier relationship requirements, and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work (SOW), and quality plans.
Project Constraints	Constraints to performing the project and/or the end-item system within cost and schedule.
Business Model Constraints	Constraints related to the expected business goal achieved by the system-of-interest, when this is relevant within the context of use, which may include: geographic position (local, national, international) of the future product, service, or organization resulting from the system-of-interest, distribution channels, alliance and partnership, finance and revenue model, etc.

Process Approach

Activities of the Process

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

• Identify the stakeholders or classes of stakeholders across the life cycle.
• Elicit, capture, or consolidate the stakeholders' needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.
• 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 rationale for the existence of the requirement.
• Identify potential 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

This process may create several artifacts, such as:

• Stakeholder requirements documents
• Stakeholder interview reports
• Stakeholder requirements database
• Stakeholder requirements justification documents (for traceability purposes)

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.

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

• Structured brainstorming workshops
• Interviews and questionnaires
• Technical, operational, and/or strategy documentation review
• Simulations and visualizations
• Prototyping
• Modeling
• 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)
• Use case diagrams (OMG 2010)
• Activity diagrams (OMG 2010)
• Functional flow block diagrams

Practical Considerations

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

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

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

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

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

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. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).

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

Additional References

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

MITRE. 2011. "Requirements Engineering." Systems Engineering Guide. Accessed 9 March 2012 at http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/requirements_engineering/.

MITRE. 2011. "Stakeholder Assessment and Management." Systems Engineering Guide. Accessed 9 March 2012 at http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/stakeholder_assessment_management.html.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

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

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

blog comments powered by Disqus