| <?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><h1> Sources of requirements </h1>
 |
| <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 href="./../../../openup/roles/stakeholder_9FFD4106.html" target="_blank" class="elementLink" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Stakeholders</a>, 
 |
| 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, so that you can 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>
 |
| <h1> Requirements-gathering techniques </h1>
 |
| <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>
 |
| <h2> Conduct a brainstorming session </h2>
 |
| <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>
 |
| <h2> Interview users </h2>
 |
| <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>
 |
| <h2> Work in the target environment </h2>
 |
| <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>
 |
| <h2> Study analogous systems </h2>
 |
| <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>
 |
| <h2> Examine suggestions and problem reports </h2>
 |
| <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.</p>
 |
| <h2> Talk to support teams </h2>
 |
| <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>
 |
| <h2> Study improvements made by users </h2>
 |
| <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>
 |
| <h2> Look for unintended uses </h2>
 |
| <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>
 |
| <h2> Conduct collaborative workshops </h2>
 |
| <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>
 |
| <img height="381" alt="" src="./resources/Workshop%20Activity%20Diagram.GIF" width="542" />
 |
| </p>
 |
| <p>&nbsp; </p>
 |
| <h2> Demonstrate prototypes to stakeholders </h2>
 |
| <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> |
