<?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" xmi:id="_On0agNSAEdmLhZ9H5Plxyw"
    name="req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw" guid="_On0agNSAEdmLhZ9H5Plxyw"
    changeDate="2007-07-18T05:31:30.889-0700" version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Sources of requirements&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Good requirements start with good sources. Finding those high-quality sources is an important task and, fortunately,&#xD;
    one that takes few resources.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The primary sources of requirements are the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/roles/stakeholder_9FFD4106.html&quot; target=&quot;_blank&quot; guid=&quot;_dTa6gMAYEdqX-s4mWhkyqQ&quot;>Stakeholder&lt;/a>s, so begin by identifying them from among these&#xD;
    candidates:&#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&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Maintenance&amp;nbsp;staff&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Partners&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Ask each stakeholder to identify other stakeholders. By “peeling the onion” in this manner you can quickly identify all&#xD;
    stakeholders so that you don't miss important perspectives and associated requirements.&amp;nbsp; This&amp;nbsp;will help you&#xD;
    identify and resolve conflicting requirements as early as possible.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    These are other possible sources of ideas for requirements:&#xD;
&lt;/p>&#xD;
&lt;ul>&#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&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The last item often includes information about the current system that competitors are using to solve the business&#xD;
    problem.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Requirements-gathering techniques&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    After you have identified these sources, there are several techniques that you can use to gather requirements (also see&#xD;
    &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#TEL06&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[TEL06]&lt;/a>). However, it is important to recognize that requirement gathering is an&#xD;
    iterative process, and there is no single technique that is universally applicable &lt;a href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#HIC03&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[HIC03]&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Success tips:&lt;/strong>&lt;br />&#xD;
    Do it now, keep it small, and iterate.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Capture requirements, and then collaborate with the stakeholders to correct and improve them. You can capture&#xD;
    requirements in one or more of these ways:&#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;
        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 for unintended uses&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Conduct collaborative workshops&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Demonstrate prototypes to stakeholders&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Conduct a brainstorming session&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Brainstorming is a short group session where all participants are allowed to say whatever they feel is important to the&#xD;
    topic of discussion. After that, a facilitator leads the group in organizing and prioritizing the results. The&#xD;
    following basic rules for brainstorming 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 many 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;
        After you have gathered information,&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 interviews is the primary source of requirements and an important&#xD;
    way to 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 fit different situations. Unless you use the&#xD;
    system yourself, you will need to make an effort to understand and experience the user's problem to describe it clearly&#xD;
    and correctly.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Start with unstructured interviews to gain an understanding of the work environment.&amp;nbsp; Ask stakeholders about their&#xD;
    jobs and the problems that they face. Structured interviews, using a prepared set of questions, can be used later to&#xD;
    fill in the gaps of your knowledge.&#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 that were developed in this way inevitably include tools for programmers, such as&#xD;
    interactive editors and compilers, because 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 and avoid reinventing&#xD;
    the wheel by looking at systems already on the market, whether they are systems installed at the user's site or&#xD;
    products made by rival organizations. Even if they are trying to solve slightly different problems, they&#xD;
    often&amp;nbsp;provide valuable clues about what you need to do.&amp;nbsp;&amp;nbsp;&#xD;
&lt;/p>&#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 way to find requirements is to look at&#xD;
    suggestions and problems as they were first described. Most organizations have a form for reporting system problems or&#xD;
    software defects. You can ask to look through those reports (there will probably be many). Sort them into groups so&#xD;
    that you can identify the key areas that are troubling users. Ask users questions about these areas to clarify the&#xD;
    users' actual needs.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If there is an existing&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/workproducts/work_items_list_39D03CC8.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Work Items List&lt;/a> from a previous release, or even from a similar project, review the&#xD;
    list for potential requirements that may apply to the current development project. If you're lucky, you may be able to&#xD;
    re-use some of that code as well!&#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;
    combined different sheets, or drawn a graph that exactly meets their individual needs. You just need to ask: Why did&#xD;
    you add that? Their answers help you get to the heart of the actual requirement.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Look for unintended uses&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    People often use things for purposes other than what the designers intended. 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 collaborative workshops&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Collaborative workshops can help you pull together a good set of requirements quickly. In two to five days, you can&#xD;
    create a set of requirements, and then review and improve them. If everyone in a workshop tries to estimate the cost&#xD;
    and value of each requirement, the outcome is much more useful and cost-effective.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Collaborative workshops are quicker and better at discovering requirements than other techniques, such&#xD;
    as&amp;nbsp;one-on-one interviews. You are bringing the right collection of people together and getting them to correct,&#xD;
    improve, and reach consensus on their requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A workshop is inherently expensive because of the number of people involved, but it saves a significant amount of time.&#xD;
    If you can define the product right the first time and cut three months off the requirements gathering, the savings&#xD;
    could 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. Discourage mobile&#xD;
    phones, but arrange to take messages. Take advantage of informal interactions by choosing a site so that people aren't&#xD;
    likely to go home at night or to go out separately.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The example in the following figure shows the logic of a requirements workshop. Notice that the workshop provides the&#xD;
    environment in which to apply other requirements-gathering techniques, such as brainstorming.&#xD;
&lt;/p>&lt;b>Conducting workshops&lt;/b> &#xD;
&lt;p>&#xD;
    &amp;nbsp;&lt;img height=&quot;371&quot; alt=&quot;Figure 1: Workshop Activity Diagram&quot; src=&quot;resources/Workshop.GIF&quot; width=&quot;545&quot; />&#xD;
&lt;/p>&lt;br />&#xD;
&lt;br />&#xD;
&lt;h4>&#xD;
    Demonstrate prototypes to stakeholders&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Prototypes and models are an excellent way of presenting ideas to users, because they allow people to immediately see&#xD;
    some aspects of the system. Showing users a simple prototype can provoke&amp;nbsp;them into giving good requirements&#xD;
    information or changing their minds about existing requirements. Prototypes can illustrate how an approach might work&#xD;
    or give users a glimpse of what they might be able to do. More requirements are likely to emerge when users see what&#xD;
    you are suggesting.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A presentation can use a sequence of slides, a story board, an artist's impression, or even an animation to give users&#xD;
    a vision of the possibilities. When prototyping software, make a mock-up of the user interface screens, emphasizing&#xD;
    that there is no code and that the system has not been designed or even specified yet. &lt;b>Fair warning:&lt;/b> A mock-up&#xD;
    can set expectations that may be difficult to meet.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This prototyping aims to get users to mention what may turn out to be missing requirements. You are not trying to sell&#xD;
    users an idea or product. Instead, you are finding out what they actually want. Seeing a prototype, which invariably is&#xD;
    wrong in some ways and right in others, is a powerful stimulus to users to start saying what they want. They may point&#xD;
    out plenty of problems with the prototype. This is excellent, because each problem leads to a new requirement.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>