6.1. Requirements ElicitationRequirements elicitation is the process through which a requirements analyst gathers, understands, reviews, and articulates the needs of the software project's stakeholders and users. Elicitation involves fact-finding, validating one's understanding of the information gathered, and communicating open issues for resolution. The objective of this activity is to create a complete list of what the users believe are important requirements. Elicitation activities can include:
When a software system is developed, the first step is to determine what the system will do. This sounds trivial to some peoplethe vision and scope document tells us what features will be developed, so why not start designing the software once everyone agrees that it's complete? This might seem like a reasonable course of action, but there's a big difference between deciding the features that will go into the software and defining the behavior of each of those features. (If a vision and scope document does not yet exist, developing one will do much more good for the project than jumping directly into the requirements. The requirements engineering activities should wait until after the vision and scope document is readysee Chapter 2.) The objective of all elicitation activities is to create a complete list of what the users and stakeholders believe are the important needs that must be filled by the software, the behavior that the software must exhibit, and the constraints to which the software must adhere. A variety of elicitation practices can be used to gain a complete understanding of user needs. Each practice should be considered carefully, to determine which is best suited for a particular project; in addition, several techniques can be used in combination. The goal of using any of the techniques is to gain the commitment of the users so a common view of the system is established. 6.1.1. Conduct InterviewsIt's been said that users don't have requirements; they have information. The requirements analyst must figure out how to get that information out of each user, stakeholder, expert, and anyone else who has information that may impact the project. The most straightforward and effective practice for doing this is by conducting interviews. Interviews with users and stakeholders are the requirements analyst's most important elicitation tool. The goal of the interview is to identify specific needs that the person being interviewed has for the software. This generally requires understanding what the interviewee does on a day-to-day basis that will require her to interact with the software. The first step in conducting interviews is to identify who the interviewees should be. Start with the list of users and stakeholders listed in the vision and scope document. While they are being interviewed, additional people may be mentioned. The interviewer should determine whether any of those people should be interviewed as well. If the software is being built for a specific industry or area of expertise, the requirements analyst may need to seek out subject matter experts in that area in order to ensure that the software meets the needs of a typical professional familiar with the subject. When the software is intended to be marketed or sold by the organization, many of the market needs will originate in a sales or marketing department. In this case, it is important that sales and marketing personnel are considered subject matter experts and are interviewed for requirements. If the goal of the project is to enhance or maintain software that is already out in the field, then the interviewees should include actual external users. The most important rule of the interview is to get the interviewee talking. Software generally doesn't get developed for its own good; a project is usually started because somebody inside an organization needs it. If the requirements analyst is talking to that person, he almost certainly will be happy to talk about it. It is likely that he has been complaining about specific problems and issues for a long time. There are many leading questions that an interviewer can ask to help uncover important information:
In the early stage of interviews, any kind of open-ended questions are good for getting the interviewee talking. It is important that the requirements analyst does not interrupt the interviewee. If he has something to say, it could be important. One key to interviewing is to make sure that the predispositions of the interviewer do not interfere with the free exchange of information. Questions should center on the interviewee's problems. The requirements analyst should try to gain an understanding of the real problem without introducing bias into the user's information. When there are multiple people with similar job functions or expertise, it is often helpful to interview them in groups. When there are too many individual interviews, they will often turn into an endless chain of conflicting statements, making it difficult to reach consensus. After an initial set of interviews, a requirements analyst should follow up with meetings to verify his or her notes and to gather any new information that the interviewees may have come up with. These meetings may consist of additional interviews, ad-hoc meetings with one or more people, brainstorming sessions, or other kinds of interactions. Note: More information on interviews can be found in Managing Software Requirements: A Use Case Approach by Dean Leffingwell and Don Widrig (Addison Wesley, 2003). 6.1.2. Observe Users at WorkObserving a user's workflow in the context of his or her environment allows a requirements analyst to see problems that the user encounters with the current system and to identify ways to enhance and streamline the behavior of the software. Watching users at work provides a more accurate understanding of their activities than simply asking them to communicate the steps involved in performing their tasks. Often there are many details that someone familiar with a task might not think to mention, but that are very important for the requirements analyst to fully understand the task. Most software is built to help users with a job that they already do. Many software projects have a goal of automating or augmenting existing manual processes, providing new capabilities to existing people in an organization, or replacing and extending legacy software programs. In all of these cases, there are already people in the organization who are doing work that is relevant to the behavior of the software. Once the requirements analyst has identified people who will use the software and whose day-to-day work is relevant to the behavior of the software, it is useful to observe those people at their jobs. There are a few guidelines that may be useful:
6.1.3. Use a Discussion SummaryAll of the interaction with the users, stakeholders, and other people who have relevant perspectives will yield a great deal of information. The requirements analyst should capture this information as accurately as possible. Some people find that taking notes on paper (rather than using a computer) allows for better capture of information. However, note-taking software, which captures the interviews in an audio file and links notes to their correct time offset in that file, can also be a useful tool. Once all of the information has been gathered from the elicitation activities, the requirements analyst should use a discussion summary to validate the information. The discussion summary allows all of the notes to be summarized into a single document; that document should be distributed to the main users and stakeholders for a deskcheck (see Chapter 5). This will help catch any potential defects before they make it into the requirements documentation. Table 6-1 contains a template for the discussion summary.
Most, if not all, of the notes gathered by a requirements analyst during the elicitation activities should fit into the discussion summary template. Conversely, the discussion summary template can serve as a guide for a novice requirements analyst in leading interviews and meetings. The requirements analyst should go through all of her notes when writing the discussion summary. Each note that will be relevant to the behavior of the software should be summarized and added to one of the sections of the discussion summary. The discussion summary will be ready to distribute when it contains all of the information gathered during the elicitation sessions. This "Project Background" section contains a summary of all the notes that pertain to the background of the project. It contains these subsections:
The "Perspectives" section is used to identify the people who will help define the behavior of the software. Each person's perspective should be taken into account. Some of these perspectives may conflict with each other; that's okay, as long as they are described accurately. These conflicts will be worked out later, when the behavior is described in the use cases. This section must provide/contain answers to the following key questions:
The "Project objectives" section summarizes the information that was gathered in the elicitation phase, such as the functionality that the software must implement, the work currently being done or planned in the organization that will be affected or augmented by the software, and any constraints that must be taken into account. This section contains:
The "Risks" section summarizes any risks identified during the elicitation process that are not already included in the vision and scope document or the project plan. The "Known future enhancements" section lists expected future enhancements. Often, during elicitation, there are feature requests from users or stakeholders that will not be included in the software. Those requests should be described, in order to make sure everyone knows that they are not going to be implemented. The "References" section should include any internal or external documents needed to understand the software projectfor example, any existing system documentation, screen shots, or original system requirements. The "Open, unresolved, or TBD [to be determined] issues" section is the last part of the discussion summary. There are usually issues that remain unaddressed at the time the discussion summary is distributed for review. Open issues may be under active discussion with users or stakeholders. Some problems may await resolution. And the requirements analyst may not yet have raised some issues. All of these issues should be summarized here. Once the discussion summary is complete, it should be distributed for a deskcheck (see Chapter 5). Minimally, it should be reviewed by the lead users and stakeholders (who are usually listed in the vision and scope document). But ideally, everyone who contributed to the discussion summary should have a chance to review it and give feedback. The wider the audience, the more likely it is that defects will be caught early. When the reviewers return their comments, the discussion summary does not need to be updated. However, those comments should be archived along with the discussion summary, and should be taken into account in later requirements activities. |