Guideline: Requirements Gathering Techniques |
This guideline describes various techniques for gathering requirements.
Relationships
Related Elements | Define Vision Find and Outline Requirements
Main Description
Sources of Requirements Good requirements start with good sources. Finding those quality sources is an important task and fortunately, one that takes little in the way of resources. Examples of sources of requirements include: Customers Users Administrators and Maintenance personnel Partners Domain Experts Industry Analysts Competitive information Requirements Gathering Techniques Once these sources are identified, there are a number of techniques that may be used to gather requirements. The following will describe the various techniques, followed by a brief discussion of when to use each technique. T o get the requirements down on paper, you can to do one or more of the following: Conduct a brainstorming session Interview users Send questionnaires Work in the target environment Study analogous systems Examine suggestions and problem reports Talk to support teams Study improvements made by users Look at unintended uses Conduct workshops Demonstrate prototypes to stakeholders The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best structure you can devise, but expect to keep on correcting it throughout the process. Conduct a brainstorming session Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of discussion. After that, a facilitator leads the group in organizing and prioritizing the results. Rules for brainstorming are the following: Start out by clearly stating the objective of the brainstorming session. Generate as may ideas as possible. Let your imagination soar. Do not allow criticism or debate while you are gathering information. Once information is gathered, mutate and combine ideas. Interview users Face-to-face contact with users through individual interviewing is the primary source of requirements and an important way you gather and validate them. Remember that it is not the only possible technique, and that interviews can be run in many different styles. Develop a repertoire of styles to suit different situations. Unless you are a user yourself, you will need to make an effort to understand and experience the user's problem to describe it successfully. Send Questionnaires If face-to-face meetings with stakeholders are not feasible, for example in the case of a product developed for the consumer market, or further clarification and/or prioritization is required questionnaires may be used. A set of questions, possibly with multiple choice responses, is sent to the relevant stakeholders who complete the questionnaire and return it. This technique has the advantage of providing a lot of information for statistical analysis; however the questions must be well designed to avoid "leading questions" which bias the stakeholder. If face-to-face meetings are possible they are always preferred since they provide a better means of uncovering the "problem behind the problem". Work in the target environment Experience the work of the users for yourself. Working with users helps you understand problems that have resisted previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they would like to have to make the work easier. Study analogous systems The starting point for many projects often consists of a similar or existing system. Sometimes comparable products and systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the wheel by looking at systems already on the market—whether installed at the user's site, or products made by rival organizations. Even if they are trying to solve slightly different problems, they often give valuable clues as to what you should be doing. Listen when a customer asks why a product couldn't do something that the customer wanted and keep a list of these suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements directly. If not, capture and store suggestions for future use. You can describe to users some features of other products, explaining that the system is in another area but contains an interesting concept, ask whether it would help them. Sometimes these systems are described in documents—either a contract from another organization or a report written for management. Often these documents were never intended as formal requirements, and were written to communicate a stream-of-consciousness. Define a process of going from a disorganized to an organized information state. Such a process might involve the following activities: •Read the document from end to end (several times) to comprehend what the customer wants and what actually has been written. •Classify all of the types of information in the document. (user, system requirements, design elements, plans, background material, irrelevant detail) •Mark up the original text to separate out such requirements. •Find a good structure for each of the different types of information—a scenario for the user requirements, functional breakdown for the system requirements, architecture for the design. •Organize the information to show gaps and overlaps. You should feel free to add missing elements—but confirm these decisions with the users. •Create traceability links between these information elements to show the designers exactly what is wanted. •Convince the customer to accept the new information as the basis for the contract. Examine suggestions and problem reports Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at suggestions and problems as first described. Most organizations have a form for reporting system problems or software defects. You can ask to look through the reports and there will probably be many. Sort them into groups so you can identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users' actual needs. Talk to support teams Most large sales organizations have a help desk, which keeps a log of problems and fixes, and some support engineers who do the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff and the support engineers may give you good leads into the requirements, and save you time. Talk to the training team and installation teams on what users find difficult. Study improvements made by users This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or related different sheets together, or drawn a graph, which exactly meets their individual needs. You need only ask, what is that for?, Why did you add that? to get to the heart of the actual requirement. This applies also to hardware and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product—and is therefore a valid new requirement for the new version. Look at unintended uses They are an immensely creative way to get new ideas and innovations. An observant product manager noticed that an engineer was staying in the office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive commercial products are now widely available for home use. Conduct workshops They can rapidly pull together a good set of requirements. In two to five days, you can create a set of requirements and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each requirement, the document becomes much more cost-effective. Workshops are quicker and better at discovering requirements than other techniques such as sending out questionnaires. You are bringing the right collection of people together, and getting them to correct and improve on their requirements document. A workshop is inherently expensive because of the number of people involved, but it does save a large amount of time. If you can define the product right the first time and cut three months off the requirements phase, the savings could be enormous. The workshop has to be thoroughly organized to take advantage of people's time. Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that people don't go home at night or go out separately. The example below shows the logic of a requirements workshop. Note that the Workshop provides the environment in which to apply other requirements gathering techniques such as Brainstorming. Demonstrate prototypes to stakeholders They allow us to immediately see some aspects of the system. Showing users a simple prototype can provoke users into giving good requirements or changing their mind about existing requirements. The techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might be able to do. More requirements are likely to emerge when users see what you are suggesting. A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that there is no code and that the system has not been designed or even specified yet (there are dangers here for the unwary). This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems with the prototype! This is excellent, as each problem leads to a new requirement. Which Technique to Apply? Which technique to apply depends on a number of factors such as: Availability and location of stakeholders Development team knowledge of the problem domain Customer/User knowledge of the problem domain Customer/User knowledge of the development process and methods If the stakeholders are not co-located or readily available, for example in the case of a product being developed for mass market, those techniques such as brainstorming, interviews and workshops that require face-to-face contact with the stakeholders may be difficult or impossible. If the stakeholders are available for face-to-face meetings this is a much better situation and almost all of the techniques described, or combination of these may be applied. In this case considerations of the experience, in terms of domain and development experience, of the stakeholders and development team are critical factors to consider in selecting the appropriate technique. The following figure, adapted from [HIC03], provides a framework for determining the appropriate techniques. It defines four main categories of customer or user experience and development team experience: "Fuzzy problem", "Selling/Teaching", "Catch up", and "Mature". There is not "right answer" here, however some guidelines for each of the four categories are: Catch-up: Interviews, Work in Target Environment Fuzzy: Brainstorming, Workshops Mature: Questionnaires, Workshops, Prototypes Selling/Teaching: Prototypes
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright