| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="_On0agNSAEdmLhZ9H5Plxyw" |
| name="req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw" guid="_On0agNSAEdmLhZ9H5Plxyw" |
| changeDate="2008-10-15T06:42:15.143-0700" version="7.2.0"> |
| <mainDescription><h3>
 |
| Sources of Requirements
 |
| </h3>
 |
| <p>
 |
| Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one
 |
| that&nbsp;takes few&nbsp;resources. Examples of sources of requirements include:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Customers
 |
| </li>
 |
| <li>
 |
| Users
 |
| </li>
 |
| <li>
 |
| Administrators and maintenance&nbsp;staff
 |
| </li>
 |
| <li>
 |
| Partners
 |
| </li>
 |
| <li>
 |
| Domain Experts
 |
| </li>
 |
| <li>
 |
| Industry Analysts
 |
| </li>
 |
| <li>
 |
| Information about competitors&nbsp;
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Requirements Gathering Techniques
 |
| </h3>
 |
| <p>
 |
| After you have identified these sources, 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.
 |
| </p>
 |
| <p>
 |
| To get the requirements down on paper, you&nbsp;can to do one or more of the following:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Conduct a brainstorming session
 |
| </li>
 |
| <li>
 |
| Interview users
 |
| </li>
 |
| <li>
 |
| Send questionnaires
 |
| </li>
 |
| <li>
 |
| Work in the target environment
 |
| </li>
 |
| <li>
 |
| Study analogous systems
 |
| </li>
 |
| <li>
 |
| Examine suggestions and problem reports
 |
| </li>
 |
| <li>
 |
| Talk to support teams
 |
| </li>
 |
| <li>
 |
| Study improvements made by users
 |
| </li>
 |
| <li>
 |
| Look at unintended uses
 |
| </li>
 |
| <li>
 |
| Conduct workshops
 |
| </li>
 |
| <li>
 |
| Demonstrate prototypes to stakeholders
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| 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.&nbsp; Success tips: Do it now,
 |
| keep it small, and correct it immediately.
 |
| </p>
 |
| <h4>
 |
| Conduct a brainstorming session
 |
| </h4>
 |
| <p>
 |
| 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.&nbsp; The following
 |
| basic rules for brainstorming&nbsp;ensures better results:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Start out by clearly stating the objective of the brainstorming session.
 |
| </li>
 |
| <li>
 |
| Generate as may ideas as possible.
 |
| </li>
 |
| <li>
 |
| Let your imagination soar.
 |
| </li>
 |
| <li>
 |
| Do not allow criticism or debate while you are gathering information.
 |
| </li>
 |
| <li>
 |
| Once information is gathered,&nbsp;reshape and combine ideas.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Interview users
 |
| </h4>
 |
| <p>
 |
| Face-to-face contact with users through individual interviewing is the primary source of requirements and an important
 |
| way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can
 |
| conduct interviews many different ways. Develop a repertoire of styles to&nbsp;fit different situations. Unless you use
 |
| the system yourself, you will need to make an effort to understand and experience the user's problem to describe it
 |
| clearly and correctly.
 |
| </p>
 |
| <h4>
 |
| Send Questionnaires
 |
| </h4>
 |
| <p>
 |
| If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering
 |
| the problem behind the problem. Sometimes, though,&nbsp;face-to-face meetings with stakeholders are not feasible (when
 |
| developing products for the consumer market, for example). In those situations, consider using questionnaires.&nbsp;
 |
| Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to
 |
| complete it and return it to you.&nbsp; Success&nbsp;tips: Keep it short and given them a deadline.&nbsp;
 |
| </p>
 |
| <p>
 |
| This technique has the advantage of providing a lot of information for statistical analysis. However, the questions
 |
| must be well designed to be clear and to avoid so-called "leading questions", which bias the responses.&nbsp;
 |
| </p>
 |
| <h4>
 |
| Work in the target environment
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h4>
 |
| Study analogous systems
 |
| </h4>
 |
| <p>
 |
| The starting point for many projects is often a similar or an 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 they are systems installed at the user's site or products
 |
| made by rival organizations. Even if they are trying to solve slightly different problems, they often&nbsp;provide
 |
| valuable clues as to what you need to do.
 |
| </p>
 |
| <p>
 |
| Listen when a customer asks why a product couldn't do something that the customer wants, 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 this way. If not, capture and store suggestions for future use.
 |
| </p>
 |
| <p>
 |
| You can describe to users selected features of other products. Explain that the system is designed for&nbsp;another
 |
| purpose&nbsp;but contains an interesting feature, and you wonder it or something similar&nbsp;would help them.
 |
| Sometimes these systems are described in documents, such as a contract from another organization or a report written
 |
| for management. Often, these documents were never intended as formal requirements, and were written merely to
 |
| communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.
 |
| </p>
 |
| <p>
 |
| Such a process might involve the following activities:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Read the document from end to end (several times) to comprehend what the customer wants and what actually has been
 |
| written.
 |
| </li>
 |
| <li>
 |
| Classify all of the types of information in the document. (user, system requirements, design elements, plans,
 |
| background material, irrelevant detail)
 |
| </li>
 |
| <li>
 |
| Mark up the original text to separate out such requirements.
 |
| </li>
 |
| <li>
 |
| Find a good structure for each of the different types of information such as: a scenario for the user requirements,
 |
| functional breakdown for the system requirements, and architecture for the design.
 |
| </li>
 |
| <li>
 |
| Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions
 |
| with the users.
 |
| </li>
 |
| <li>
 |
| Create traceability links between these information elements to show the designers exactly what the users want.
 |
| </li>
 |
| <li>
 |
| Convince the customer to accept the new information as the basis for the contract.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Examine suggestions and problem reports
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h4>
 |
| Talk to support teams
 |
| </h4>
 |
| <p>
 |
| Most large sales organizations have a help desk that keeps a log of problems and fixes, and 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. Also talk to the training
 |
| team and installation teams about what users find to be&nbsp;difficult.
 |
| </p>
 |
| <h4>
 |
| Study improvements made by users
 |
| </h4>
 |
| <p>
 |
| 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, that exactly meets their individual needs. You need only ask: Why
 |
| did you add that? Their answers help you&nbsp;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,
 |
| which makes it&nbsp;a valid&nbsp;requirement for the new version.
 |
| </p>
 |
| <h4>
 |
| Look at unintended uses
 |
| </h4>
 |
| <p>
 |
| People often use things for purposes for which they were not designed.&nbsp; This is&nbsp;a good way to get new ideas
 |
| and to think of innovations. For example, 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.
 |
| </p>
 |
| <h4>
 |
| Conduct workshops
 |
| </h4>
 |
| <p>
 |
| Workshops 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 useful and cost-effective.
 |
| </p>
 |
| <p>
 |
| Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You
 |
| are bringing the right collection of people together, and getting them to correct and improve on their requirements
 |
| document.
 |
| </p>
 |
| <p>
 |
| A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If
 |
| you can define the product right the first time and cut three months off the requirements gathering, the savings could
 |
| be enormous. The workshop has to be thoroughly organized to take advantage of people's time.
 |
| </p>
 |
| <p>
 |
| 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&nbsp;in Figure 1&nbsp;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.
 |
| </p>
 |
| <p>
 |
| <img height="381" alt="" src="./resources/workshopactivitydiagram.gif" width="542" />
 |
| </p>
 |
| <p>
 |
| <strong>Figure 1: Conducting Workshops</strong>
 |
| </p>
 |
| <h4>
 |
| Demonstrate prototypes to stakeholders
 |
| </h4>
 |
| <p>
 |
| Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can
 |
| provoke&nbsp;them into giving good requirements information 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.
 |
| </p>
 |
| <p>
 |
| 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 (fair warning: there are dangers here
 |
| for the unwary).
 |
| </p>
 |
| <p>
 |
| 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,&nbsp;because each problem leads to a new requirement.
 |
| </p>
 |
| <h3>
 |
| Which Technique to Apply?
 |
| </h3>
 |
| <p>
 |
| Which technique to apply depends on a number of factors, such as:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Availability and location of stakeholders
 |
| </li>
 |
| <li>
 |
| Development team knowledge of the problem domain
 |
| </li>
 |
| <li>
 |
| Customers' and users' knowledge of the problem domain
 |
| </li>
 |
| <li>
 |
| Customers' and users' knowledge of the development process and methods
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| If the stakeholders are not co-located or readily available, for example in the case of a product being developed for
 |
| mass market,&nbsp;techniques such as brainstorming, interviews and workshops that require face-to-face contact with the
 |
| stakeholders may be difficult or impossible.
 |
| </p>
 |
| <p>
 |
| 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 them, may be applied. In this case, the domain and development experience of
 |
| oth the stakeholders and the development team are critical factors in selecting the appropriate technique.
 |
| </p>
 |
| <p>
 |
| Figure 2, adapted from <a
 |
| href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">[HIC03]</a>, 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".
 |
| </p>
 |
| <p>
 |
| <img height="470" alt="" src="./resources/Which%20Req%20Gathering%20Technique.gif" width="514" />
 |
| </p>
 |
| <p>
 |
| <strong>Figure 2: Selection of Techniques</strong>
 |
| </p>
 |
| <p>
 |
| There is no "right answer", but these guidelines may help you decide which method to use:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Catch-up: Interviews, work in target environment
 |
| </li>
 |
| <li>
 |
| Fuzzy: Brainstorming, workshops
 |
| </li>
 |
| <li>
 |
| Mature: Questionnaires, workshops, prototypes
 |
| </li>
 |
| <li>
 |
| Selling/Teaching: prototypes
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
