To identify individuals who will act as stakeholders in your "extended project team".
To determine and prioritize sources for requirements.
For an existing system, the first set of input to this task 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 full time 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 a result business modeling or business process re-engineering, or any
other form of business definition.