Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Workflow Detail: Understand Stakeholder Needs

The purpose of this workflow detail is to understand the needs of the primary project stakeholders by gathering information about the desired or envisaged product.
Topics - Description - Related Information - Timing - Optionality - How to Staff - Work Guidelines

Description

This workflow detail addresses collecting and eliciting information from the stakeholders in the project in order to understand what their needs really are. The collected stakeholder requests can be regarded as a “wish list” that will be used as primary input to defining the high-level features of your system, as described in the Vision, which drive the specification of the software requirements, as described in the use-case model, use cases and supplementary specifications. (See also: stakeholder requests, use-case model, use cases and supplementary specifications).

Typically, this activity is mainly performed during iterations in the Inception and Elaboration phases, however additional stakeholder requests will continue to be gathered throughout the project via Change Requests submitted and approved in accordance with your projects Change-Request Management Process.

The main objective is to elicit stakeholder requests using such input as interviews business rules, enhancement requests, and requirements workshops. The primary outputs are collection(s) of prioritized features and their critical attributes, which will be used in defining the system and managing the scope of the system. (See also: defining the system, managing system scope, business rules and the Related Information section for additional guidance).

This information results in a refinement of the Vision artifact, as well as a better understanding of the requirements attributes. Also, during the enactment of this workflow detail you may start discussing the functional requirements of the system in terms of its use cases and actors. Those non-functional requirements, which do not fit appropriately within the use-case specifications, should be documented in Supplementary Specifications. (See also: non-functional requirements, requirements attributes, use cases and actors).

Another important output is an updated Glossary of terms to facilitate communication through the use of a common vocabulary among team members.

This section provides links to additional information related to this workflow detail.

Timing

This work is normally addressed early in each iteration.

Optionality

Should be performed in iterations where the needs of the stakeholders are being discovered or undergoing change.

How to Staff

The project members involved in understanding stakeholder needs should be efficient facilitators and have experience in eliciting information. Of course, familiarity with the targeted technology is desirable, but it is not essential.

Work Guidelines

See the Related Information section for additional guidance that will help you in performing this work.