OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/guidelines/requirements_gathering_techniques.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>openup&amp;#92;guidances&amp;#92;guidelines&amp;#92;&amp;#92;requirements_gathering_techniques.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: requirements_gathering_techniques.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_OnoNQNSAEdmLhZ9H5Plxyw CRC: 1425429376 -->Requirements Gathering Techniques<!-- END:presentationName,_OnoNQNSAEdmLhZ9H5Plxyw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_OnoNQNSAEdmLhZ9H5Plxyw CRC: 856766130 -->This guideline describes various techniques for gathering requirements.<!-- END:briefDescription,_OnoNQNSAEdmLhZ9H5Plxyw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_On0agNSAEdmLhZ9H5Plxyw CRC: 1706125774 --><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><!-- END:mainDescription,_On0agNSAEdmLhZ9H5Plxyw -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>openup&#92;guidances&#92;guidelines&#92;&#92;requirements_gathering_techniques.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: requirements_gathering_techniques.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_OnoNQNSAEdmLhZ9H5Plxyw CRC: 1425429376 -->Requirements Gathering Techniques<!-- END:presentationName,_OnoNQNSAEdmLhZ9H5Plxyw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_OnoNQNSAEdmLhZ9H5Plxyw CRC: 856766130 -->This guideline describes various techniques for gathering requirements.<!-- END:briefDescription,_OnoNQNSAEdmLhZ9H5Plxyw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_On0agNSAEdmLhZ9H5Plxyw CRC: 1706125774 --><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 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.  This 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, 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.  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 provide valuable clues about what you need to do.
	</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 <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 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 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 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="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 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><!-- END:mainDescription,_On0agNSAEdmLhZ9H5Plxyw -->
	</body>
	</html>