Log in

Page Read View source View history PDF Export Search SEBoK
Stewards

Stakeholder Needs and Requirements

Stakeholder Needs and Requirements

Lead Authors: Alan Faisandier, Garry Roedler, Contributing Author: Rick Adcock

Stakeholder needs and requirements represent the views of those at the business or enterprise operations level—that is, of users, acquirers, customers, and other
stakeholders as they relate to the problem (or opportunity), as a set of requirements for a solution that can provide the services needed by the stakeholders in a defined
Quicklinks environment. Using enterprise-level life cycle concepts (see Business or Mission Analysis for details) as guidance, stakeholders are led through a structured process to
Main Page elicit stakeholder needs (in the form of a refined set of system-level life-cycle concepts). Stakeholder needs are transformed into a defined set of Stakeholder
Letter from the Editor Requirements, which may be documented in the form of a model, a document containing textual requirement statements or both.
Governance and Editorial Boards Stakeholder requirements play major roles in systems engineering, as they:
SEBoK Sponsors
Form the basis of system requirements activities.
Acknowledgements and Release
History
Form the basis of system validation and stakeholder acceptance .
FAQs Act as a reference for integration and verification activities.
Outline Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.

Table of Contents This topic describes the definition of stakeholder needs and requirements which involves the activities necessary to elicit and prioritize the needs of the stakeholder(s), and
Part 1: SEBoK Introduction transform those needs into a set of defined stakeholder requirements. Defining the problem or the issue to be solved, identifying the opportunity for developing a new
Part 2: Foundations of Systems 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
Engineering initial context of use of the new or modified mission, operation, or capability has already been characterized (see Business or Mission Analysis). System requirements are
Part 3: SE and Management 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
Introduction to Life Cycle Processes
traceability, for which a number of iterations may be needed.
Life Cycle Models

Concept Definition Contents [hide]

Business or Mission Analysis 1 Purpose and Definition
Mission Engineering 2 Principles and Concepts
Stakeholder Needs and 2.1 Identifying Stakeholders
Requirements 2.2 Identifying Stakeholder Needs
System Definition 2.3 Identifying Stakeholder Requirements
System Realization 2.4 Collecting Stakeholder Needs and Requirements
System Deployment and Use 2.5 From the Capture of Stakeholder Needs to the Definition of Stakeholder Requirements
Systems Engineering Management 2.6 Classification of Stakeholder Requirements
Product and Service Life 3 Process Approach
Management
3.1 Activities of the Process
Systems Engineering Standards
3.2 Artifacts, Methods and Modeling Techniques
Part 4: Applications of Systems
4 Practical Considerations
Engineering
Part 5: Enabling Systems Engineering
5 References
5.1 Works Cited
Part 6: Related Disciplines
5.2 Primary References
Part 7: SE Implementation Examples
5.3 Additional References
Part 8: Emerging Knowledge
5.4 Relevant Videos
Use the SEBoK

How to Read the SEBoK

Download SEBoK PDF Purpose and Definition

Copyright Information The purpose of the Stakeholder Needs and Requirements definition activities are to elicit a set of clear and concise needs related to a new or changed mission for an
Cite the SEBoK enterprise (see mission analysis (MA) for information relevant to identifying and defining the mission or operation), and to transform these stakeholder needs into verifiable
About the SEBoK stakeholder requirements.
Navigation
Stakeholders may well begin with desires, and expectations that may contain vague, ambiguous statements that are difficult to use for SE activities. Care must be taken to
Knowledge Areas ensure that those desires and expectations are coalesced into a set of clear and concise need statements that are useful as a start point for system definition. These need
Topics statements will then need to be further clarified and translated into more engineering-oriented language in a set of stakeholder requirements to enable proper architecture
Use Cases definition and requirement activities. As an example, a need or an expectation such as, to easily manoeuvre a car in order to park, will be transformed in a set of
Examples stakeholder requirements to a statement such as, increase the driviability of the car, decrease the effort for handling, assist the piloting, protect the coachwork against
Glossary of Terms shocks or scratches, etc.
Acronyms To allow a clear description of the activities of stakeholder needs and requirements to be described, a generic view of the business teams and roles involved in a typical
Primary References enterprise has been used below., tThis includes teams such as business management and business operations;, and roles including requirements engineer and business
Tools analyst. For an overview of these roles and how they enable both stakeholder and business requirements across the layers of a typical enterprise see Life Cycle
Processes and Enterprise Need.
What links here
Permanent link
Page information Principles and Concepts
Cite this page
Browse properties Identifying Stakeholders
Sponsors 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 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.

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 Quality control, production system, operators, etc.
Production or for
Use
Logistics and Supply chain, support services, trainers, etc.
Maintenance
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

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 verification and validation processes,
Review of the outcomes from the 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.

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 iterative and 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.

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 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 rationale (glossary) 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:

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.

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 The exhaustiveness of requirements can be an issue; in particular, the interfaces with external objects of the context of the system
Objects Forgotten can be forgotten (exchanges of matter, energy, information).
Physical Connections with Within the interface issue, physical connections of the system-of-interest with external objects can be forgotten (technological
External Objects Forgotten 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 Involve the stakeholders early in the stakeholder requirements development process.
Stakeholders
Presence of Capture the rationale for each stakeholder requirement.
Rationale
Analyze Sources Complete stakeholder requirements as much as possible before starting the definition of the system requirements.
before Starting
Modeling Use modeling techniques as indicated in sections above.
Techniques
Requirements Consider using a requirements management tool. This tool should have the capability to trace linkages between the stakeholder requirements
 Management Tool 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.

Hauser, J. and D. Clausing. 1988. "The House of Quality." Harvard Business Review. (May - June 1988).

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.

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.

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

Relevant Videos
How to Get Project Requirements from Project Stakeholders
Requirements Engineering Challenges
Requirements Engineering Processes
User and System Requirements

< Previous Article | Parent Article | Next Article >

SEBoK v. 2.4, released 19 May 2021

Category: Concept Definition

Add comment

This page was last edited on 19 May 2021, at 03:44.

Privacy policy About SEBoK Disclaimers