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

End User System Analyst Capture a Common Vocabulary Elicit Stakeholder Requests Develop Vision Find Actors and Use Cases Manage Dependencies Iteration Plan Glossary Requirements Management Plan Requirements Attributes (refined) Vision (refined) Use-Case Model Supplementary Specifications (outlines) Requirements Attributes Stakeholder Requests Vision Change Request (approved) Storyboard


Description To top of page

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.

Related Information To top of page

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

Timing To top of page

This work is normally addressed early in each iteration.

Optionality To top of page

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

How to Staff To top of page

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 To top of page

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



© Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process   2003.06.13