This activity addresses collecting and eliciting information from the stakeholders in the project in order to understand what their needs really are (see Elicit Stakeholder Requests). 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 (see Develop Vision), which drive the specification of the Software Requirements, as described in the Software Requirements Specification (which may reference the Use-Case Model, Use Cases and Supplementary Specifications).

The main objective is to elicit stakeholder requests using such input as interviews, 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 defining the system, managing system scope).

This information results in a refinement of the vision, as well as a better understanding of the  Requirements Attributes. Also, during the enactment of this activity you may start discussing the functional requirements of the system in terms of its use cases and actors (see Find Actors and Use Cases).  Those requirements which do not fit appropriately within the use cases should be documented in Supplementary Specifications (see Develop Supplementary Specifications). 

As you define new requirements, it is important to document any dependencies (e.g.,  Traceability) between these requirements (see  Manage Dependencies).

Another important output is an updated Glossary of terms to facilitate communication through the use of a common vocabulary among team members (see Capture a Common Vocabulary).

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.

It should be noted that activities being performed in this capability pattern are not performed in sequence.  In fact, it is more-often the case that these activities are performed concurrently. For example, while identifying actors and use cases (Find Actors and Use Cases), we may encounter requirements that do not naturally align with a particular use case, in which case the requirement may be defined in the Supplementary Specifications (Develop Supplementary Specifications). Conversely, while identifying non-use-case-specific requirements (e.g., system-wide requirements), we may encounter requirements that only apply to a particular use case, in which case the requirement is associated with the use case.