<?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:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc"
    rmc:version="7.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>&lt;h3>&#xD;
    Sources of Requirements&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Good requirements start with good sources. Finding those quality sources is an important task and, fortunately, one&#xD;
    that&amp;nbsp;takes few&amp;nbsp;resources. Examples of sources of requirements include:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Customers&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Users&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Administrators and maintenance&amp;nbsp;staff&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Partners&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Domain Experts&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Industry Analysts&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Information about competitors&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Requirements Gathering Techniques&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    After you have identified these sources, there are a number of techniques that may be used to gather requirements. The&#xD;
    following will describe the various techniques, followed by a brief discussion of when to use each technique.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    To get the requirements down on paper, you&amp;nbsp;can to do one or more of the following:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Conduct a brainstorming session&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Interview users&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Send questionnaires&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Work in the target environment&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Study analogous systems&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Examine suggestions and problem reports&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Talk to support teams&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Study improvements made by users&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Look at unintended uses&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Conduct workshops&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Demonstrate prototypes to stakeholders&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The best idea is to get the requirements down quickly and then to encourage the users to correct and improve them. Put&#xD;
    in those corrections, and repeat the cycle. Do it now, keep it small, and correct it at once. Start off with the best&#xD;
    structure you can devise, but expect to keep on correcting it throughout the process.&amp;nbsp; Success tips: Do it now,&#xD;
    keep it small, and correct it immediately.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Conduct a brainstorming session&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Brainstorming is a short group session where everyone is allowed to say whatever they feel is important to the topic of&#xD;
    discussion. After that, a facilitator leads the group in organizing and prioritizing the results.&amp;nbsp; The following&#xD;
    basic rules for brainstorming&amp;nbsp;ensures better results:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Start out by clearly stating the objective of the brainstorming session.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Generate as may ideas as possible.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Let your imagination soar.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Do not allow criticism or debate while you are gathering information.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Once information is gathered,&amp;nbsp;reshape and combine ideas.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Interview users&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Face-to-face contact with users through individual interviewing is the primary source of requirements and an important&#xD;
    way you gather and validate their requirements. Remember that it is not the only possible technique, and that you can&#xD;
    conduct interviews many different ways. Develop a repertoire of styles to&amp;nbsp;fit different situations. Unless you use&#xD;
    the system yourself, you will need to make an effort to understand and experience the user's problem to describe it&#xD;
    clearly and correctly.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Send Questionnaires&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    If face-to-face meetings are possible, they are always preferable, because they provide a better means of uncovering&#xD;
    the problem behind the problem. Sometimes, though,&amp;nbsp;face-to-face meetings with stakeholders are not feasible (when&#xD;
    developing products for the consumer market, for example). In those situations, consider using questionnaires.&amp;nbsp;&#xD;
    Send a set of questions, possibly with multiple choice responses, to the relevant stakeholders, and ask them to&#xD;
    complete it and return it to you.&amp;nbsp; Success&amp;nbsp;tips: Keep it short and given them a deadline.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This technique has the advantage of providing a lot of information for statistical analysis. However, the questions&#xD;
    must be well designed to be clear and to avoid so-called &quot;leading questions&quot;, which bias the responses.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Work in the target environment&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Experience the work of the users for yourself. Working with users helps you understand problems that have resisted&#xD;
    previous solutions. Familiar systems developed in this way inevitably include tools for programmers, such as&#xD;
    interactive editors and compilers, as the developers naturally have both the expertise in the subject area, and the&#xD;
    desire to solve their own problems. It would be good to see the same dedication devoted to solving problems in other&#xD;
    areas too. Where the work cannot easily be experienced in this way, it may still be possible to do a bit more than just&#xD;
    sit quietly and observe. Users can give you a commentary on what they are doing, what the problems are, and what they&#xD;
    would like to have to make the work easier.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Study analogous systems&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The starting point for many projects is often a similar or an existing system. Sometimes, comparable products and&#xD;
    systems contain working versions of good ideas for solving user problems. You can save the time lost in reinventing the&#xD;
    wheel by looking at systems already on the market, whether they are systems installed at the user's site or products&#xD;
    made by rival organizations. Even if they are trying to solve slightly different problems, they often&amp;nbsp;provide&#xD;
    valuable clues as to what you need to do.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Listen when a customer asks why a product couldn't do something that the customer wants, and keep a list of these&#xD;
    suggestions. Later, use it to start discussions with other users. You should be able to obtain some requirements&#xD;
    directly this way. If not, capture and store suggestions for future use.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    You can describe to users selected features of other products. Explain that the system is designed for&amp;nbsp;another&#xD;
    purpose&amp;nbsp;but contains an interesting feature, and you wonder it or something similar&amp;nbsp;would help them.&#xD;
    Sometimes these systems are described in documents, such as a contract from another organization or a report written&#xD;
    for management. Often, these documents were never intended as formal requirements, and were written merely to&#xD;
    communicate a stream-of-consciousness idea. Define a process of going from disorganized to organized information.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Such a process might involve the following activities:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Read the document from end to end (several times) to comprehend what the customer wants and what actually has been&#xD;
        written.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Classify all of the types of information in the document. (user, system requirements, design elements, plans,&#xD;
        background material, irrelevant detail)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Mark up the original text to separate out such requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Find a good structure for each of the different types of information such as: a scenario for the user requirements,&#xD;
        functional breakdown for the system requirements, and architecture for the design.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Organize the information to show gaps and overlaps. Feel free to add missing elements, but confirm these decisions&#xD;
        with the users.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create traceability links between these information elements to show the designers exactly what the users want.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Convince the customer to accept the new information as the basis for the contract.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Examine suggestions and problem reports&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Requirements can come from change suggestions and user problems. A direct road to finding requirements is to look at&#xD;
    suggestions and problems as first described. Most organizations have a form for reporting system problems or software&#xD;
    defects. You can ask to look through the reports (and there will probably be many). Sort them into groups so you can&#xD;
    identify the key areas that are troubling users. Ask users some questions about these areas to clarify the users'&#xD;
    actual needs.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Talk to support teams&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Most large sales organizations have a help desk that keeps a log of problems and fixes, and support engineers who do&#xD;
    the fixing. Many organizations have similar facilities to support their own operations. Talking to the help desk staff&#xD;
    and the support engineers may give you good leads into the requirements, and save you time. Also talk to the training&#xD;
    team and installation teams about what users find to be&amp;nbsp;difficult.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Study improvements made by users&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    This is an excellent source of requirements. Users of a standard company spreadsheet may have added a few fields, or&#xD;
    related different sheets together, or drawn a graph, that exactly meets their individual needs. You need only ask: Why&#xD;
    did you add that? Their answers help you&amp;nbsp;get to the heart of the actual requirement. This applies also to hardware&#xD;
    and non-computer devices. For example, a lathe operator may have manufactured a special clamp, or an arm that prevents&#xD;
    movement of the tool beyond a certain point. Any such modification points to something wrong with the existing product,&#xD;
    which makes it&amp;nbsp;a valid&amp;nbsp;requirement for the new version.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Look at unintended uses&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    People often use things for purposes for which they were not designed.&amp;nbsp; This is&amp;nbsp;a good way to get new ideas&#xD;
    and to think of innovations. For example, an observant product manager noticed that an engineer was staying in the&#xD;
    office late to use an advanced computer-aided design system to design a new kitchen layout for his home. Inexpensive&#xD;
    commercial products are now widely available for home use.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Conduct workshops&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Workshops can rapidly pull together a good set of requirements. In two to five days, you can create a set of&#xD;
    requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost and value of each&#xD;
    requirement, the document becomes much more useful and cost-effective.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Workshops are quicker and better at discovering requirements than other techniques, such as sending questionnaires. You&#xD;
    are bringing the right collection of people together, and getting them to correct and improve on their requirements&#xD;
    document.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A workshop is inherently expensive because of the number of people involved, but it saves a large amount of time. If&#xD;
    you can define the product right the first time and cut three months off the requirements gathering, the savings could&#xD;
    be enormous. The workshop has to be thoroughly organized to take advantage of people's time.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Choose a quiet location for the workshop so that people are not disturbed by day-to-day business. Mobile phones should&#xD;
    be discouraged; arrange to take messages externally. Take advantage of informal interactions by choosing a site so that&#xD;
    people don't go home at night or go out separately. The example&amp;nbsp;in Figure 1&amp;nbsp;shows the logic of a requirements&#xD;
    workshop. Note that the workshop provides the environment in which to apply other requirements-gathering techniques&#xD;
    such as brainstorming.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;381&quot; alt=&quot;&quot; src=&quot;./resources/workshop_activity_diagram.gif&quot; width=&quot;542&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Figure 1: Conducting Workshops&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Demonstrate prototypes to stakeholders&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Prototypes allow us to immediately see some aspects of the system. Showing users a simple prototype can&#xD;
    provoke&amp;nbsp;them into giving good requirements information or changing their mind about existing requirements. The&#xD;
    techniques described here help you gather ideas for requirements. Prototypes and models are an excellent way of&#xD;
    presenting ideas to users. They can illustrate how an approach might work, or give users a glimpse of what they might&#xD;
    be able to do. More requirements are likely to emerge when users see what you are suggesting.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A presentation can use a sequence of slides, storyboard, an artist's impression, or even an animation to give users a&#xD;
    vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing that&#xD;
    there is no code and that the system has not been designed or even specified yet (fair warning: there are dangers here&#xD;
    for the unwary).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This prototyping aims to get users to express (missing) requirements. You are not trying to sell users an idea or&#xD;
    product, you are finding out what they actually want. Seeing a prototype, which invariably is wrong in some ways and&#xD;
    right in others, is a powerful stimulus to users to start saying what they want. They may point out plenty of problems&#xD;
    with the prototype! This is excellent,&amp;nbsp;because each problem leads to a new requirement.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Which Technique to Apply?&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Which technique to apply depends on a number of factors, such as:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Availability and location of stakeholders&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Development team knowledge of the problem domain&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Customers' and users' knowledge of the problem domain&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Customers' and users' knowledge of the development process and methods&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    If the stakeholders are not co-located or readily available, for example in the case of a product being developed for&#xD;
    mass market,&amp;nbsp;techniques such as brainstorming, interviews and workshops that require face-to-face contact with the&#xD;
    stakeholders may be difficult or impossible.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If the stakeholders are available for face-to-face meetings, this is a much better situation and almost all of the&#xD;
    techniques described, or combination of them, may be applied. In this case, the domain and development experience of&#xD;
    both the stakeholders and the development team are critical factors in selecting the appropriate technique.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Figure 2, adapted from &lt;a&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[HIC03]&lt;/a>, provides a framework for determining the appropriate techniques. It defines&#xD;
    four main categories of customer or user experience and development team experience: &quot;Fuzzy problem&quot;,&#xD;
    &quot;Selling/Teaching&quot;, &quot;Catch up&quot;, and &quot;Mature&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img height=&quot;470&quot; alt=&quot;&quot; src=&quot;./resources/which_req_gathering_technique.gif&quot; width=&quot;514&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Figure 2: Selection of Techniques&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    There is no &quot;right answer&quot;, but these guidelines may help you decide which method to use:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Catch-up: Interviews, work in target environment&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Fuzzy: Brainstorming, workshops&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Mature: Questionnaires, workshops, prototypes&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Selling/Teaching: prototypes&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>