| <?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><h3>
 |
| Sources of requirements
 |
| </h3>
 |
| <p>
 |
| Good requirements start with good sources. Finding those high-quality sources is an important task and, fortunately,
 |
| one that takes few resources.
 |
| </p>
 |
| <p>
 |
| The primary sources of requirements are the <a class="elementLink" href="./../../../openup/roles/stakeholder_9FFD4106.html" target="_blank" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholder</a>s, so begin by identifying them from among these
 |
| candidates:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Customers
 |
| </li>
 |
| <li>
 |
| Users
 |
| </li>
 |
| <li>
 |
| Administrators
 |
| </li>
 |
| <li>
 |
| Maintenance&nbsp;staff
 |
| </li>
 |
| <li>
 |
| Partners
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Ask each stakeholder to identify other stakeholders. By “peeling the onion” in this manner you can quickly identify all
 |
| stakeholders so that you don't miss important perspectives and associated requirements.&nbsp; This&nbsp;will help you
 |
| identify and resolve conflicting requirements as early as possible.
 |
| </p>
 |
| <p>
 |
| These are other possible sources of ideas for requirements:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Domain experts
 |
| </li>
 |
| <li>
 |
| Industry analysts
 |
| </li>
 |
| <li>
 |
| Information about competitors
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The last item often includes information about the current system that competitors are using to solve the business
 |
| problem.
 |
| </p>
 |
| <h3>
 |
| Requirements-gathering techniques
 |
| </h3>
 |
| <p>
 |
| After you have identified these sources, there are several techniques that you can use to gather requirements (also see
 |
| <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#TEL06" guid="_9ToeIB83Edqsvps02rpOOg">[TEL06]</a>). However, it is important to recognize that requirement gathering is an
 |
| iterative process, and there is no single technique that is universally applicable <a href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#HIC03" guid="_9ToeIB83Edqsvps02rpOOg">[HIC03]</a>.
 |
| </p>
 |
| <p>
 |
| <strong>Success tips:</strong><br />
 |
| Do it now, keep it small, and iterate.
 |
| </p>
 |
| <p>
 |
| Capture requirements, and then collaborate with the stakeholders to correct and improve them. You can capture
 |
| requirements in one or more of these ways:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Conduct a brainstorming session
 |
| </li>
 |
| <li>
 |
| Interview users
 |
| </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 for unintended uses
 |
| </li>
 |
| <li>
 |
| Conduct collaborative workshops
 |
| </li>
 |
| <li>
 |
| Demonstrate prototypes to stakeholders
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Conduct a brainstorming session
 |
| </h4>
 |
| <p>
 |
| Brainstorming is a short group session where all participants are 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. The
 |
| following basic rules for brainstorming ensures better results:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Start out by clearly stating the objective of the brainstorming session.
 |
| </li>
 |
| <li>
 |
| Generate as many ideas as possible.
 |
| </li>
 |
| <li>
 |
| Let your imagination soar.
 |
| </li>
 |
| <li>
 |
| Do not allow criticism or debate while you are gathering information.
 |
| </li>
 |
| <li>
 |
| After you have gathered information,&nbsp;reshape and combine ideas.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Interview users
 |
| </h4>
 |
| <p>
 |
| Face-to-face contact with users through individual interviews is the primary source of requirements and an important
 |
| way to 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 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>
 |
| <p>
 |
| Start with unstructured interviews to gain an understanding of the work environment.&nbsp; Ask stakeholders about their
 |
| jobs and the problems that they face. Structured interviews, using a prepared set of questions, can be used later to
 |
| fill in the gaps of your knowledge.
 |
| </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 that were developed in this way inevitably include tools for programmers, such as
 |
| interactive editors and compilers, because 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 and avoid 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 about what you need to do.&nbsp;&nbsp;
 |
| </p>
 |
| <h4>
 |
| Examine suggestions and problem reports
 |
| </h4>
 |
| <p>
 |
| Requirements can come from change suggestions and user problems. A direct road way to find requirements is to look at
 |
| suggestions and problems as they were first described. Most organizations have a form for reporting system problems or
 |
| software defects. You can ask to look through those reports (there will probably be many). Sort them into groups so
 |
| that you can identify the key areas that are troubling users. Ask users questions about these areas to clarify the
 |
| users' actual needs.
 |
| </p>
 |
| <p>
 |
| If there is an existing&nbsp;<a class="elementLink" href="./../../../openup/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a> from a previous release, or even from a similar project, review the
 |
| list for potential requirements that may apply to the current development project. If you're lucky, you may be able to
 |
| re-use some of that code as well!
 |
| </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
 |
| combined different sheets, or drawn a graph that exactly meets their individual needs. You just need to ask: Why did
 |
| you add that? Their answers help you get to the heart of the actual requirement.
 |
| </p>
 |
| <h4>
 |
| Look for unintended uses
 |
| </h4>
 |
| <p>
 |
| People often use things for purposes other than what the designers intended. 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 collaborative workshops
 |
| </h4>
 |
| <p>
 |
| Collaborative workshops can help you pull together a good set of requirements quickly. 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 outcome is much more useful and cost-effective.
 |
| </p>
 |
| <p>
 |
| Collaborative workshops are quicker and better at discovering requirements than other techniques, such
 |
| as&nbsp;one-on-one interviews. You are bringing the right collection of people together and getting them to correct,
 |
| improve, and reach consensus on their requirements.
 |
| </p>
 |
| <p>
 |
| A workshop is inherently expensive because of the number of people involved, but it saves a significant 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. Discourage mobile
 |
| phones, but arrange to take messages. Take advantage of informal interactions by choosing a site so that people aren't
 |
| likely to go home at night or to go out separately.
 |
| </p>
 |
| <p>
 |
| The example in the following figure shows the logic of a requirements workshop. Notice that the workshop provides the
 |
| environment in which to apply other requirements-gathering techniques, such as brainstorming.
 |
| </p><b>Conducting workshops</b> 
 |
| <p>
 |
| &nbsp;<img height="371" alt="Figure 1: Workshop Activity Diagram" src="resources/Workshop.GIF" width="545" />
 |
| </p><br />
 |
| <br />
 |
| <h4>
 |
| Demonstrate prototypes to stakeholders
 |
| </h4>
 |
| <p>
 |
| Prototypes and models are an excellent way of presenting ideas to users, because they allow people 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 minds about existing requirements. Prototypes 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, a story board, 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. <b>Fair warning:</b> A mock-up
 |
| can set expectations that may be difficult to meet.
 |
| </p>
 |
| <p>
 |
| This prototyping aims to get users to mention what may turn out to be missing requirements. You are not trying to sell
 |
| users an idea or product. Instead, 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, because each problem leads to a new requirement.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
