Section 6.1. Requirements Elicitation


6.1. Requirements Elicitation

Requirements 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:

  • Interviews with the users, stakeholders, and anyone else whose perspective needs to be taken into account during the design, development, and testing of the software

  • Observation of the users at work

  • Distribution of discussion summaries to verify the data gathered in interviews

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 Interviews

It'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:

  • Why is the software being built? What benefits will the interviewee directly see? What benefits will other people in the organization see?

  • What problems need to be addressed with new software? Why do those problems exist? How would you solve them?

  • Who will use the software once it is built? Why do they need it? How frequently will they be using the software? Who will support the software?

  • In what environment will the software be used? Will it be run within the organization or by its customers? Who will control the hardware?

  • Are there any known constraints on the performance, design, or quality of the software?

  • What inputs will be used by the software? What outputs will it create? (If examples of these exist, they should be saved for later requirements activities.)

  • Are your answers "official," or is there someone else who might be able to answer these questions better? Are there "experts" in the organization who may have additional information?

  • How do the users currently do their jobs? How do they expect their jobs to change after the software goes into production? Are there typical problems they currently encounter that they would like to fix?

  • Are there any "workarounds" that the users perform, in order to make up for the shortcomings of existing software? Can these workarounds be incorporated into planned features or turned into additional ones? (If the workarounds are not part of the original scope of the project, does that scope need to be expanded to include them?)

  • "Is there anything that I missed?"

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 Work

Observing 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:

  • Many software projects are started because people who are doing work face tedious or difficult tasks that could be automated. Those people are often happy to open up and talk about the problems that need to be solved.

  • Some people may feel self-conscious being observed. It is important that they know that the goal of the requirements analyst is to understand their needs in order to build software to help them. It is also important that they understand that the software is not being built to replace them, but to help make their jobs easier.

  • Many organizations have training programs for new employees. If a training program exists for the job being observed, the requirements analyst should attend it. This will often yield more insight into the work, especially if there are training materials that can be used as part of the requirements gathering process.

  • If possible, the requirements analyst should try to participate in the work being observed. This is often an effective way to understand the perspective of the users of the software.

6.1.3. Use a Discussion Summary

All 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.

Table 6-1. Discussion summary template

  1. Project background

    1. Purpose of project

    2. Scope of project

    3. Other background information

  2. Perspectives

    1. Who will use the system?

    2. Who can provide input about the system?

  3. Project objectives

    1. Known business rules

    2. System information and/or diagrams

    3. Assumptions and dependencies

    4. Design and implementation constraints

  4. Risks

  5. Known future enhancements

  6. References

  7. Open, unresolved, or TBD issues


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:


Purpose of the project

Every stakeholder and user has a reason that the software should be developed. This section should contain a summary of each of those reasons. The goal is to give the reader an understanding of why these people need the system to be developed.


Scope of the project

The vision and scope document described the scope of the software to be developed, by listing each feature that would be included. This section should go into greater detail, elaborating on each feature by listing specific behaviors and tasks the software will perform.


Other background information

This section should contain any additional information that may help a reader understand why the system is needed. (Additionally, most of the notes that don't fit anywhere else in the discussion summary can go into this section.)

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:


Who will use the system?

The people who will be using the software should be divided into categories. Each category of users should have a unique name ("Salesperson") and description ("A member of the North America sales team who will be selling the software in a specific territory."). The names that are given to the categories of users should make sense to people in the organizationmost organizations have their own names for different roles or positions, and the requirements analyst should use that terminology wherever possible. The analyst will have many notes that pertain to each of these categories. They should be divided up by category and summarized in this section.


Who can provide input about the system?

The organization contains many people who can provide some input about the system to be developed. This section should list everyone who was consulted about the system behavior, and summarize any notes that describe the needs of each one.

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:


Known business rules

This section should contain details of any procedures that are currently being performed or that are needed in the organization and that will affect the software. The section should indicate who is involved or will be affected.


System information and/or diagrams

This section should contain a summary of any notes that describe functionality that must be implemented, existing or planned organizational workflow, specific user interactions, information about the environment in which the software will be used, calculations that must be performed, and any other functionality that must be implemented. This will probably be the longest section in the discussion summary.


Assumptions and dependencies

During elicitation meetings, many assumptions and dependencies will be brought up. They should be summarized in this section. (See Chapter 3 for an explanation of how assumptions affect software development.) Many of these assumptions may already be in the vision and scope document, or in the results of a Wideband Delphi estimation session; it is often sufficient to reference that document, rather than reproduce them in the discussion summary.


Design and implementation constraints

Many times there are constraints that must be placed on the software: known input or output data formats; tools, code libraries, visual controls, programming languages, or APIs that must be used; visual or GUI design standards that must be adhered to; and performance or quality requirements and other known nonfunctional requirements. These should be listed in this section in detail.

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.



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net