There are a number of different methods to capture and document requirements from your customer. Most customers have a pretty good idea of what they want, but have you talked with enough members from the customer community or with all the functions that will use or be impacted by the product? And to make matters more interesting, everyone has a different preferred style for describing what they want in the product, so different techniques may be required to successfully capturing requirements.
When you say you are going to gather requirements from your customer, the first thought
that comes to mind is that that you will ask questions and document the answers. But you must ask the right kind of questions, and listen carefully to the answers. Gathering requirements through an interview process like this is probably the most common technique. However, there are many techniques for gathering requirements, and in many projects the team will need to utilize a number of them instead of, or in addition to, interviewing.
For instance, if you want to gather input from 100 users, you probably will not be able to talk to each one of them independently. In fact, if you did, you would find that you are not receiving very much information after you have finished the first couple. A better, faster, and cheaper approach might be to interview a small number of people in this group and then send surveys to the rest.
There are a number of techniques for eliciting requirements, and your project may need to use multiple techniques depending on the circumstances.
- One-on-one interviews. The most common technique for gathering requirements is to sit down with the customers and ask them what they need. The discussion should be planned out ahead of time based on the type of requirements you are looking for.
- Group interviews. These are similar to the one-on-one interview except that there is more than one person being interviewed. These do require more preparation and more formality to get the information you want from all the participants, as you will need to keep the group focused.
- Questionnaires. These are much more informal, and they are good tools to gather requirements from stakeholders in remote locations, from many members of a large stakeholder community, or from those that will have only minor input into the overall requirements. A questionnaire can also be a valuable way to gather quick statistics, such as the number of people who would use certain features, or to get a sense for the relative priority of requirements.
- Use Cases. Here the goal is to capture a detailed description of how the product will interact with and respond to the user under a number of scenarios, which helps to define the functions and features needed to achieve the customers' needs. See our Use Case Specification template for one example of how to do this.
- Prototyping. Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather preliminary requirements that you use to build an initial version of the solution—a prototype. You show this to the customer, who then gives you additional requirements. This repetitive process continues until the product meets the critical mass of business needs, or for an agreed number of iterations.
- Following people around. This is especially helpful when gathering information on current processes. You may find, for instance, that some people have their work routine down to such a habit that they have a hard time explaining what they do or why. You may need to watch them perform their job before you can understand the entire picture. In some cases, you might also like to participate in the actual work process to get a hands-on feel for how the business function works today.
Which one to use depends upon your comfort level with these processes and the project objectives. Often you will need a combination of approaches to capture different aspects of the requirements. Remember, the end goal of collecting requirements is to provide the development team as clear a picture as possible of what the customer is expecting the product to deliver. An example that can be used for more than software products is the Software Requirements Capture Guideline, which provides guidelines for some of the methods mentioned above.
Now what do you do with all this good information? You capture it in a way that others can use. This can be in done in a number of different ways, some of which are discussed below. You will want to keep track of the source of the requirement, because you may need to get more information as development progresses, or to ask that person or group evaluate a prototype. Most product requirements are captured in product requirements documents—examples of these are the Product Requirements Specification and Software Requirements Specification. You may also want to read "Project Management Survival Tools – Part B (Use Cases)," which provides guidelines on this technique of requirements capture and documentation.