<?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.4/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.2.0" xmi:id="_On0agNSAEdmLhZ9H5Plxyw"
    name="req_gathering_techniques,_OnoNQNSAEdmLhZ9H5Plxyw" guid="_On0agNSAEdmLhZ9H5Plxyw"
    changeDate="2007-04-13T11:55:02.071-0700" version="1.0.0">
  <mainDescription>&lt;h1> Sources of requirements &lt;/h1>&#xD;
&lt;p> Good requirements start with good sources. Finding those high-quality sources &#xD;
  is an important task and, fortunately, one that takes few resources. &lt;/p>&#xD;
&lt;p> The primary sources of requirements are the &lt;a href=&quot;./../../../openup/roles/stakeholder_9FFD4106.html&quot; target=&quot;_blank&quot; class=&quot;elementLink&quot; guid=&quot;_dTa6gMAYEdqX-s4mWhkyqQ&quot;>Stakeholders&lt;/a>, &#xD;
  so begin by identifying them from among these candidates: &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> Ask each stakeholder to identify other stakeholders. By “peeling the onion” &#xD;
  in this manner you can quickly identify all stakeholders so that you don't miss &#xD;
  important perspectives and associated requirements, so that you can identify &#xD;
  and resolve conflicting requirements as early as possible. &lt;/p>&#xD;
&lt;p> These are other possible sources of ideas for requirements: &lt;/p>&#xD;
&lt;ul>&#xD;
    &#xD;
  &lt;li> Domain experts &lt;/li>&#xD;
  &lt;li> Industry analysts &lt;/li>&#xD;
    &lt;li>&#xD;
        Information about competitors&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p> The last item often includes information about the current system that competitors &#xD;
  are using to solve the business problem. &lt;/p>&#xD;
&lt;h1> Requirements-gathering techniques &lt;/h1>&#xD;
&lt;p> After you have identified these sources, there are several techniques that &#xD;
  you can use to gather requirements (also see &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#TEL06&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[TEL06]&lt;/a>). &#xD;
  However, it is important to recognize that requirement gathering is an iterative &#xD;
  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> &lt;strong>Success&#xD;
    tips:&lt;/strong> &lt;br />&#xD;
  Do it now, keep it small, and iterate. &lt;/p>&#xD;
&lt;p>Capture requirements, and then collaborate with the stakeholders to correct &#xD;
  and improve them. You can capture requirements in one or more of these ways:&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> Look for unintended uses &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;h2> Conduct a brainstorming session &lt;/h2>&#xD;
&lt;p> Brainstorming is a short group session where all participants are allowed &#xD;
  to say whatever they feel is important to the topic of discussion. After that, &#xD;
  a facilitator leads the group in organizing and prioritizing the results. The &#xD;
  following basic rules for brainstorming ensures better results: &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> Generate as many ideas as possible. &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> After you have gathered information,&amp;nbsp;reshape and combine ideas. &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h2> Interview users &lt;/h2>&#xD;
&lt;p> Face-to-face contact with users through individual interviews is the primary &#xD;
  source of requirements and an important way to gather and validate their requirements. &#xD;
  Remember that it is not the only possible technique and that you can conduct &#xD;
  interviews many different ways. Develop a repertoire of styles to fit different &#xD;
  situations. Unless you use the system yourself, you will need to make an effort &#xD;
  to understand and experience the user's problem to describe it clearly and correctly. &#xD;
&lt;/p>&#xD;
&lt;p> Start with unstructured interviews to gain an understanding of the work environment.&amp;nbsp; &#xD;
  Ask stakeholders about their jobs and the problems that they face. Structured &#xD;
  interviews, using a prepared set of questions, can be used later to fill in &#xD;
  the gaps of your knowledge. &lt;/p>&#xD;
&lt;h2> Work in the target environment &lt;/h2>&#xD;
&lt;p> Experience the work of the users for yourself. Working with users helps you &#xD;
  understand problems that have resisted previous solutions. Familiar systems &#xD;
  that were developed in this way inevitably include tools for programmers, such &#xD;
  as interactive editors and compilers, because the developers naturally have &#xD;
  both the expertise in the subject area and the desire to solve their own problems. &#xD;
  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 &#xD;
  be possible to do a bit more than just sit quietly and observe. Users can give &#xD;
  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. &lt;/p>&#xD;
&lt;h2> Study analogous systems &lt;/h2>&#xD;
&lt;p> The starting point for many projects is often a similar or an existing system. &#xD;
  Sometimes, comparable products and systems contain working versions of good &#xD;
  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 &#xD;
  installed at the user's site or products made by rival organizations. Even if &#xD;
  they are trying to solve slightly different problems, they often&amp;nbsp;provide &#xD;
  valuable clues about what you need to do.&amp;nbsp;&amp;nbsp; &lt;/p>&#xD;
&lt;h2> Examine suggestions and problem reports &lt;/h2>&#xD;
&lt;p> Requirements can come from change suggestions and user problems. A direct &#xD;
  road way to find requirements is to look at suggestions and problems as they &#xD;
  were first described. Most organizations have a form for reporting system problems &#xD;
  or software defects. You can ask to look through those reports (there will probably &#xD;
  be many). Sort them into groups so that you can identify the key areas that &#xD;
  are troubling users. Ask users questions about these areas to clarify the users' &#xD;
  actual needs. &lt;/p>&#xD;
&lt;p> 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 &#xD;
  Items List&lt;/a> from a previous release, or even from a similar project, review &#xD;
  the list for potential requirements that may apply to the current development &#xD;
  project. If you're lucky, you may be able to re-use some of that code.&lt;/p>&#xD;
&lt;h2> Talk to support teams &lt;/h2>&#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;h2> Study improvements made by users &lt;/h2>&#xD;
&lt;p> This is an excellent source of requirements. Users of a standard company spreadsheet &#xD;
  may have added a few fields, or combined different sheets, or drawn a graph &#xD;
  that exactly meets their individual needs. You just need to ask: Why did you &#xD;
  add that? Their answers help you get to the heart of the actual requirement. &#xD;
&lt;/p>&#xD;
&lt;h2> Look for unintended uses &lt;/h2>&#xD;
&lt;p> People often use things for purposes other than what the designers intended. &#xD;
  This is&amp;nbsp;a good way to get new ideas and to think of innovations. For example, &#xD;
  an observant product manager noticed that an engineer was staying in the office &#xD;
  late to use an advanced computer-aided design system to design a new kitchen &#xD;
  layout for his home. Inexpensive commercial products are now widely available &#xD;
  for home use. &lt;/p>&#xD;
&lt;h2> Conduct collaborative workshops &lt;/h2>&#xD;
&lt;p> Collaborative workshops can help you pull together a good set of requirements &#xD;
  quickly. In two to five days, you can create a set of requirements, and then &#xD;
  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> Collaborative workshops are quicker and better at discovering requirements &#xD;
  than other techniques, such as&amp;nbsp;one-on-one interviews. You are bringing &#xD;
  the right collection of people together and getting them to correct, improve, &#xD;
  and reach consensus on their requirements. &lt;/p>&#xD;
&lt;p> A workshop is inherently expensive because of the number of people involved, &#xD;
  but it saves a significant amount of time. If you can define the product right &#xD;
  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 &#xD;
  of people's time. &lt;/p>&#xD;
&lt;p> Choose a quiet location for the workshop so that people are not disturbed &#xD;
  by day-to-day business. Discourage mobile phones, but arrange to take messages. &#xD;
  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. &lt;/p>&#xD;
&lt;p>The example in the following figure shows the logic of a requirements workshop. &#xD;
  Notice that the workshop provides the environment in which to apply other requirements-gathering &#xD;
  techniques, such as brainstorming. &lt;/p>&#xD;
&lt;b> Conducting workshops &lt;/b> &#xD;
&lt;p>&#xD;
    &lt;img height=&quot;381&quot; alt=&quot;&quot; src=&quot;./resources/Workshop%20Activity%20Diagram.GIF&quot; width=&quot;542&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&amp;nbsp; &lt;/p>&#xD;
&lt;h2> Demonstrate prototypes to stakeholders &lt;/h2>&#xD;
&lt;p> Prototypes and models are an excellent way of presenting ideas to users, because &#xD;
  they allow people to immediately see some aspects of the system. Showing users &#xD;
  a simple prototype can provoke&amp;nbsp;them into giving good requirements information &#xD;
  or changing their minds about existing requirements. Prototypes can illustrate &#xD;
  how an approach might work or give users a glimpse of what they might be able &#xD;
  to do. More requirements are likely to emerge when users see what you are suggesting. &#xD;
&lt;/p>&#xD;
&lt;p> A presentation can use a sequence of slides, a story board, an artist's impression, &#xD;
  or even an animation to give users a vision of the possibilities. When prototyping &#xD;
  software, make a mock-up of the user interface screens, emphasizing that there &#xD;
  is no code and that the system has not been designed or even specified yet. &#xD;
  &lt;b>Fair warning: &lt;/b>A mock-up can set expectations that may be difficult to &#xD;
  meet. &lt;/p>&#xD;
&lt;p> This prototyping aims to get users to mention what may turn out to be missing &#xD;
  requirements. You are not trying to sell users an idea or product. Instead, &#xD;
  you are finding out what they actually want. Seeing a prototype, which invariably &#xD;
  is wrong in some ways and right in others, is a powerful stimulus to users to &#xD;
  start saying what they want. They may point out plenty of problems with the &#xD;
  prototype. This is excellent, because each problem leads to a new requirement. &#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>