Purpose:
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
Objective:
To gather Customer Requirements from the Requirements Providers, Analyze the gathered requirements, and document detailed and traceable requirements.
Description:
The needs of stakeholders (e.g., customers, end users, suppliers, builders, testers, manufacturers, and logistics support staff) are the basis for determining customer requirements. The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
Stakeholder needs, expectations, constraints, and interfaces are frequently poorly identified or conflicting. Since stakeholder needs, expectations, constraints, and limitations should be identified and understood, an iterative process is used throughout the project’s life to accomplish this objective. To facilitate the required interaction, a surrogate for the end user or customer is frequently involved in representing their needs and helping resolve conflicts. The customer relations or marketing part of the organization and members of the development team from disciplines such as human engineering or support can be used as surrogates. Environmental, legal, and other constraints should be considered when creating and resolving the set of customer requirements.
Inputs:
- Draft Project Charter
- Baseline Project Charter
- Process Design Summary
- Requirements Traceability Matrix Template
Outputs:
- Customer Requirements Document
- Requirements Traceability Metrics
- Meeting Minutes
- Updated Project Issue Log
Controls:
Task Instructions:
Elicit Stakeholder Needs
- Using the Draft Project Charter and [methods?], [the Business Analyst], with support from the Business Relationship Manager and identified list of Requirements Providers, is responsible for engaging relevant stakeholders for eliciting needs, expectations, constraints, and external interfaces.
Develop and Prioritize Customer Requirements
- Using the Draft Project Charter and the Customer Requirements Document Template, [the Business Analyst], with support from the identified list of Requirements Providers, is responsible for translating stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.
- Using the System Requirements Specifications Template, [the Business Analyst], with support from the identified list of Requirements Providers, is responsible for updating the consolidating the elicited information into Functional and non-functional.
- Using the System Requirements Specifications Template, the [Business Analyst], with support from the identified list of Requirements Providers, is responsible for prioritizing the requirements.
- Using the System Requirements Specifications Template, [the Business Analyst], with support from the identified list of Requirements Providers, is responsible for proposing acceptance criteria for each User Requirement.
- Using the System Requirements Specification Template [the Business Analyst] with support from the identified list of Requirements Providers is responsible for developing operational concepts through User Stories, Data Models, and/or Screen Shots.
- Using User Stories, Data Models, and/or Screenshots [the Business Analyst] with support from Requirements Providers is responsible for gathering additional requirements.
Use These Seven Techniques to Elicit Requirements
Requirements are usually gathered in two places during a traditional project. High-level requirements help you complete a Project Charter. Detailed requirements are gathered during an Analysis Phase. The detailed requirements help you understand how to design and build the solution.
The elicitation step is where the high-level requirements are gathered. To elicit accurate requirements, the project manager must ask the right questions and then listen carefully to the answers. Gathering requirements through an interview process is probably the most common technique. However, there are several techniques for eliciting requirements, and your project may need to use multiple techniques depending on the circumstances.
- One-on-one interviews. The most common technique for gathering requirements is to sit down with the clients and ask them what they need. The discussion should be planned ahead of time based on the type of requirements you are looking for.
- Group interviews. These are similar to the one-on-one interview, except that more than one person is being interviewed. Group interviews require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period if you can keep the group focused.
- Facilitated sessions. In a facilitated session, you bring a larger group together for a common purpose. In this case, you are trying to gather a set of standard requirements from the group faster than if you were to interview each separately.
- JAD sessions. Joint Application Development (JAD) sessions are similar to general facilitated sessions. However, the group typically stays in the session until the objectives are completed. In this case, the participants would remain in session until a complete set of requirements is documented and agreed to.
- Questionnaires. These are much more informal and are good tools to gather requirements from stakeholders in remote locations or those that will have only minor input into the overall requirements. A questionnaire can also be a valuable way to collect quick statistics, such as the number of people using specific features, or to get a sense of the relative priority of requirements.
- Prototyping. Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements to build an initial version of the solution – a prototype. You show this to the client, who then gives you additional requirements. You change the application and cycle around with the client again. This repetitive process continues until the product meets the critical mass of business needs or for an agreed number of iterations.
- Following people around. This is especially helpful when gathering information on current processes. You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. You may need to watch them perform their job before understanding the entire picture. In some cases, you might also like to participate in the actual work process to get a hands-on feel for how the business function works today.
Knowing the stakeholders that will provide requirements will help you determine the best techniques to meet your needs. You should select techniques that get the most relative information and best suit the audience.
