Activity: Elicit Stakeholder Requests Purpose To understand who are the stakeholders of the project. To collect requests on what needs the system should fulfill. To prioritize stakeholder requests. Role:  System Analyst  Frequency: As required, typically at least once per iteration in Inception and Elaboration, and as needed in subsequent phases. Steps Determine Sources for Requirements Gather Information Conduct Requirements Workshops Evaluate Your Results More Information:  Concept: Prototypes Input Artifacts:  Business Case Change Request Iteration Plan Vision   Resulting Artifacts:  Stakeholder Requests Storyboard   Tool Mentors:    Workflow Details:      Determine Sources for Requirements Purpose 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 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 Purpose Formulate which questions that need to be answered. Gather and document information.  Interviews One of the most useful methods of gathering information is to conduct interviews with a select group of key stakeholders. Some sample questions and techniques that may be used are found in the Guidelines: Interviews.  See the supplied template for Artifact: Stakeholder Requests for a sample script for conducting an effective interview. Questionnaires This is a widely used technique. After conducting several interview, 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 Purpose: To make the project team meet the stakeholders of the project. To gather a comprehensive "wish list" from stakeholders of the project. To prioritize the collected requirements based on stakeholders attending the workshop.  Guidelines: Requirements Workshops Brainstorming and Idea Reduction Storyboarding Role Playing Review Existing Requirements   Evaluate Your Results Purpose Compare results from different requirements workshops. Make sure you have the correct information gathered.  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. © Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process