Activity:  Elicit Stakeholder Requests

Determine Sources for Requirements

For an existing system, the first set of input to this activity will be the set of postponed enhancement requests, which have been gathered throughout the product lifecycle as part of the formal change request management process. This will provide a valuable starting point from which to gather data and further refine your set of stakeholder requests.

After this initial information has been gathered, look for partners, users, customers, domain experts, and industry analysts who can represent your stakeholders. Determine which individuals you would work with to collect information, considering their knowledge, communication skills, availability, and "importance". These individuals will act as stakeholders of your project—in effect, an "extended project team". In general, it is better to have a small (2–5) group of people that can stay with you for the duration of the project. Also, the more people there are in your extended team, the more time it will take to manage them and make sure that you use their time effectively. These people do not work fulltime on the project—they typically participate in one or a few requirements gathering workshops in the inception and elaboration phases, and later on in review sessions.

Find a way to learn how others do what you are trying to do. If you are developing a software product, this would mean to gather competitive information. If you are developing a new version of an in-house information system, you need to schedule site visits to see how people are using the current system and find out what can be improved.

An important source is any existing descriptions of the organization in which the system is to be used. These could either be business models produced as described in the business modeling discipline, or any other form of business definition.

Gather Information

Interviews

One of the most useful methods of gathering information is to conduct interviews with a select group of key stakeholders. 

Questionnaires

This is a widely used technique. After conducting several interviews, you may realize that the same information is appearing over and over again. This type of information may be collected into a set of questions with typical answers from which to choose and send to a larger set of stakeholders. This method allows you to better gather formal statistics on the answers that are given to the included questions. They key, however, is to be able to formulate questions in such a way that these statistics give realistic results of what your stakeholders actually need.

The stakeholders may be able to answer and send the results back to you via the internet. This allows you to reach a much wider range of people than if you do direct interviews, but you have less control of the results. You are not there to directly communicate with the person answering the questions to clarify any issues or misunderstandings. Questionnaires can be a very powerful tool, but they do not replace a direct interview. Also, an assumption is that relevant questions can be determined in advance, and that you can phrase them so that the reader hears them in the intended way.

Conduct Requirements Workshops

Evaluate Your Results

Especially if you have conducted more than one requirements workshop, it is a good habit for the project team to walk through the results and:

• Make sure there is a priority given to each request.
• Make sure that there is information about what or who is the source of the request.
• Note and maybe clarify obvious inconsistencies between the requests.

The results of the requirements workshop need to be presented to a select set of customers or users in a review or follow-up session. In this session, you will identify if there are any issues that need to be clarified, which in turn means you will identify tasks that need to be completed, and assign people to those tasks.