Task: Elicit Stakeholder Requests var defaultQueryStr = '?proc={38A9C609-9A59-4D03-B835-AA84A716E626}&path={38A9C609-9A59-4D03-B835-AA84A716E626},{F9E2B414-29F4-48F9-B263-35570D64314B},_3bgakEogEdqrjq4i3fchvA'; var backPath = './../../'; var imgPath = './../../images/'; var nodeInfo=null; contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, true, true, false); Task: Elicit Stakeholder Requests This task describes how to elicit requests from the stakeholders on what they would like the system to provide. Purpose The purpose of this task is to: Understand who are the stakeholders of the project. Collect requests on what needs the system should fulfill. Prioritize stakeholder requests. Relationships RolesMain: System Analyst Additional: Assisting: InputsMandatory: Business Case Iteration Plan Optional: Change Request Vision External: None Outputs Stakeholder Requests Storyboard Main Description Stakeholder Requests are both actively elicited and gathered from existing sources to get a "wish list" of what different stakeholders of the project (customers, users, product champions) expect or desire the system to include, together with information on how each request has been considered by the project. Steps 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 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. Gather Information Purpose Formulate which questions that need to be answered. Gather and document information.  Storyboarding A useful technique that can be used for gathering information is storyboarding, which results in Storyboard(s).  For more information, see Guideline: Storyboarding 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 Guideline: Interviews.  For specific recommendations on what information can be gathered to document a stakeholder request, see the information provided for the Artifact: Stakeholder Requests. 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. Properties Multiple Occurrences Event Driven Ongoing Optional Planned Repeatable More Information Concepts Prototypes Guidelines Brainstorming and Idea Reduction Fishbone Diagrams Interviews Pareto Diagrams Requirements Workshop Review Existing Requirements Role Playing Storyboarding Use-Case Workshop ©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved. contentPage.onload(); contentPage.processPage.fixDescriptorLinks();