<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Top Five Requirements Gathering Tips</title>
	<atom:link href="http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/</link>
	<description>Software product success.</description>
	<lastBuildDate>Sat, 19 May 2012 12:04:06 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: LKW Autoverwertung Berlin</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-847442</link>
		<dc:creator>LKW Autoverwertung Berlin</dc:creator>
		<pubDate>Tue, 27 Dec 2011 10:18:11 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-847442</guid>
		<description>Really a very informative site. I hope there are still a few more Disussion on the subject, put the page in my favorites. best regards</description>
		<content:encoded><![CDATA[<p>Really a very informative site. I hope there are still a few more Disussion on the subject, put the page in my favorites. best regards</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mary Chant</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-830681</link>
		<dc:creator>Mary Chant</dc:creator>
		<pubDate>Mon, 21 Nov 2011 05:12:39 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-830681</guid>
		<description>&lt;span class=&quot;topsy_trackback_comment&quot;&gt;&lt;span class=&quot;topsy_twitter_username&quot;&gt;&lt;span class=&quot;topsy_trackback_content&quot;&gt;Top Five Requirements Gathering Tips http://t.co/SMqhzvJp&lt;/span&gt;&lt;/span&gt;</description>
		<content:encoded><![CDATA[<p><span class="topsy_trackback_comment"><span class="topsy_twitter_username"><span class="topsy_trackback_content">Top Five Requirements Gathering Tips <a href="http://t.co/SMqhzvJp" rel="nofollow">http://t.co/SMqhzvJp</a></span></span></span></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Markus Pope</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-824375</link>
		<dc:creator>Markus Pope</dc:creator>
		<pubDate>Thu, 27 Oct 2011 02:00:47 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-824375</guid>
		<description>&lt;span class=&quot;topsy_trackback_comment&quot;&gt;&lt;span class=&quot;topsy_twitter_username&quot;&gt;&lt;span class=&quot;topsy_trackback_content&quot;&gt;Six tips for gathering requirements - http://t.co/4tmOjJqy&lt;/span&gt;&lt;/span&gt;</description>
		<content:encoded><![CDATA[<p><span class="topsy_trackback_comment"><span class="topsy_twitter_username"><span class="topsy_trackback_content">Six tips for gathering requirements &#8211; <a href="http://t.co/4tmOjJqy" rel="nofollow">http://t.co/4tmOjJqy</a></span></span></span></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Qurie de Berk</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-820674</link>
		<dc:creator>Qurie de Berk</dc:creator>
		<pubDate>Wed, 12 Oct 2011 17:07:27 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-820674</guid>
		<description>&lt;span class=&quot;topsy_trackback_comment&quot;&gt;&lt;span class=&quot;topsy_twitter_username&quot;&gt;&lt;span class=&quot;topsy_trackback_content&quot;&gt;RT @sehlhorst: Top Five Requirements Gathering Tips http://t.co/4mFK5IoG&lt;/span&gt;&lt;/span&gt;</description>
		<content:encoded><![CDATA[<p><span class="topsy_trackback_comment"><span class="topsy_twitter_username"><span class="topsy_trackback_content">RT @sehlhorst: Top Five Requirements Gathering Tips <a href="http://t.co/4mFK5IoG" rel="nofollow">http://t.co/4mFK5IoG</a></span></span></span></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-409887</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Mon, 28 Jul 2008 13:17:19 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-409887</guid>
		<description>RP, Thanks for the compliment and great question, and welcome to Tyner Blain.

This approach will absolutely work with hosted products as well.  A hosted product is just like a non-hosted one, when it comes to gathering requirements.  The differences are at a lower level of detail (must be connected to the internet (at least occasionally, for some products), (ideally) has a cost structure that drives different implementation approaches and provides unique ROI opportunities for features, and possibly has a sense of community (either walled-garden or open) and an opportunity to integrate mash-up style with other applications to support unintentional uses.

There are two distinct paths to conceptually explore: improve the product for existing customers (to retain them), or improve the product to entice new customers (and grow the community).  The requirements gathering tips in this article would apply in either case - the difference is in who you talk with.

Take a look at &lt;a href=&quot;http://tynerblain.com/blog/2008/07/15/the-non-customer-is-always-right/&quot; rel=&quot;nofollow&quot;&gt;The Non-Customer Is Always Right&lt;/a&gt;, and &lt;a href=&quot;http://tynerblain.com/blog/2008/07/22/buyers-and-users/&quot; rel=&quot;nofollow&quot;&gt;Buyer Personas and User Personas&lt;/a&gt; for a couple recent discussions about how to think about it.  I suspect your questions are a little more strategic (how to find people to focus on), and once you do that, the answers are combination of looking at buyer personas (for new customers) and applying the requirements gathering techniques within those frameworks.  Check out the links (in the article and comment sections) for the personas article to get exposed to what some of the marketing experts are saying about accessing new markets.

Thanks again, and don&#039;t hesitate to ask more questions if this answer is off the mark.</description>
		<content:encoded><![CDATA[<p>RP, Thanks for the compliment and great question, and welcome to Tyner Blain.</p>
<p>This approach will absolutely work with hosted products as well.  A hosted product is just like a non-hosted one, when it comes to gathering requirements.  The differences are at a lower level of detail (must be connected to the internet (at least occasionally, for some products), (ideally) has a cost structure that drives different implementation approaches and provides unique ROI opportunities for features, and possibly has a sense of community (either walled-garden or open) and an opportunity to integrate mash-up style with other applications to support unintentional uses.</p>
<p>There are two distinct paths to conceptually explore: improve the product for existing customers (to retain them), or improve the product to entice new customers (and grow the community).  The requirements gathering tips in this article would apply in either case &#8211; the difference is in who you talk with.</p>
<p>Take a look at <a href="http://tynerblain.com/blog/2008/07/15/the-non-customer-is-always-right/" rel="nofollow">The Non-Customer Is Always Right</a>, and <a href="http://tynerblain.com/blog/2008/07/22/buyers-and-users/" rel="nofollow">Buyer Personas and User Personas</a> for a couple recent discussions about how to think about it.  I suspect your questions are a little more strategic (how to find people to focus on), and once you do that, the answers are combination of looking at buyer personas (for new customers) and applying the requirements gathering techniques within those frameworks.  Check out the links (in the article and comment sections) for the personas article to get exposed to what some of the marketing experts are saying about accessing new markets.</p>
<p>Thanks again, and don&#8217;t hesitate to ask more questions if this answer is off the mark.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RP</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-408813</link>
		<dc:creator>RP</dc:creator>
		<pubDate>Sat, 26 Jul 2008 09:54:51 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-408813</guid>
		<description>Hi,
     Great article like so many other on your website.
     I was wondering if these techniques will work for a hosted product. I am in a fix since I am not able to think of any other technique but online user feedback mechanism for a hosted products.
     I have known a hosted product with more than 200,000 registered users. In this case interviewing them, brainstorming etc is just impossible. Was wondering what would be the right mechanism to crack this problem since many of the product offerings these days are getting hosted.

Also - I am only referring to a situation where we have the product already hosted with huge registered customer base and not a requirement gathering for a new would be hosted product.

Regards,
RP.</description>
		<content:encoded><![CDATA[<p>Hi,<br />
     Great article like so many other on your website.<br />
     I was wondering if these techniques will work for a hosted product. I am in a fix since I am not able to think of any other technique but online user feedback mechanism for a hosted products.<br />
     I have known a hosted product with more than 200,000 registered users. In this case interviewing them, brainstorming etc is just impossible. Was wondering what would be the right mechanism to crack this problem since many of the product offerings these days are getting hosted.</p>
<p>Also &#8211; I am only referring to a situation where we have the product already hosted with huge registered customer base and not a requirement gathering for a new would be hosted product.</p>
<p>Regards,<br />
RP.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Recursos de fin de semana</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-56944</link>
		<dc:creator>Recursos de fin de semana</dc:creator>
		<pubDate>Sat, 18 Nov 2006 02:35:45 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-56944</guid>
		<description>[...] Top five requirement gathering tips: algunos tips para la captura de requerimientos. Visto en Ingeniería de Software [...]</description>
		<content:encoded><![CDATA[<p>[...] Top five requirement gathering tips: algunos tips para la captura de requerimientos. Visto en Ingeniería de Software [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Symbolism and communication -Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-280</link>
		<dc:creator>Symbolism and communication -Tyner Blain</dc:creator>
		<pubDate>Mon, 13 Feb 2006 01:03:44 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-280</guid>
		<description>[...] What does this have to do with requirements? We see from our earlier post on requirements gathering techniques that communication is central to the most important requirements elicitation methods. Understanding how people associate ideas symbolically helps us communicate more effectively. [...]</description>
		<content:encoded><![CDATA[<p>[...] What does this have to do with requirements? We see from our earlier post on requirements gathering techniques that communication is central to the most important requirements elicitation methods. Understanding how people associate ideas symbolically helps us communicate more effectively. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: From MRD to PRD: The key to defining a spec -Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-174</link>
		<dc:creator>From MRD to PRD: The key to defining a spec -Tyner Blain</dc:creator>
		<pubDate>Mon, 30 Jan 2006 17:20:28 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-174</guid>
		<description>[...] One of the things that makes this requirements design activity so difficult is that we have to have good ideas about how to solve the problems we are tasked with solving. Look at example number three - there are many different ways to attempt to solve the problem - the challenge is in picking the right one. Requirements elicitation will unearth the required capabilities. [...]</description>
		<content:encoded><![CDATA[<p>[...] One of the things that makes this requirements design activity so difficult is that we have to have good ideas about how to solve the problems we are tasked with solving. Look at example number three &#8211; there are many different ways to attempt to solve the problem &#8211; the challenge is in picking the right one. Requirements elicitation will unearth the required capabilities. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Top five ways to be a better listener -Tyner Blain</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-160</link>
		<dc:creator>Top five ways to be a better listener -Tyner Blain</dc:creator>
		<pubDate>Fri, 27 Jan 2006 13:58:18 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-160</guid>
		<description>[...] Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating. [...]</description>
		<content:encoded><![CDATA[<p>[...] Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyner Blain &#187; Where bugs come from</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-124</link>
		<dc:creator>Tyner Blain &#187; Where bugs come from</dc:creator>
		<pubDate>Sun, 22 Jan 2006 21:19:32 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-124</guid>
		<description>[...] E1 - The wrong requirements. The first source of errors is stakeholders who don’t describe (or don’t know) what they really want. Or they don&#8217;t know why they want it. Everyone who’s gathered requirements has heard things like “Now that I see it working, I realize that what I really want is…” We’ve had the most success in minimizing this situation through rapid-development techniques (repeated iterations of deployment), development of prototypes, and interaction with stakeholders throughout the design process - helping them envision what you are creating before you create it. We won’t succeed by using the spec as a defense: “But we implemented what the spec says” - your clients should not be expected to visualize what a software solution would look like just by reading a spec - that’s your job. [...]</description>
		<content:encoded><![CDATA[<p>[...] E1 &#8211; The wrong requirements. The first source of errors is stakeholders who don’t describe (or don’t know) what they really want. Or they don&#8217;t know why they want it. Everyone who’s gathered requirements has heard things like “Now that I see it working, I realize that what I really want is…” We’ve had the most success in minimizing this situation through rapid-development techniques (repeated iterations of deployment), development of prototypes, and interaction with stakeholders throughout the design process &#8211; helping them envision what you are creating before you create it. We won’t succeed by using the spec as a defense: “But we implemented what the spec says” &#8211; your clients should not be expected to visualize what a software solution would look like just by reading a spec &#8211; that’s your job. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyner Blain &#187; Prioritizing requirements - three techniques</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-104</link>
		<dc:creator>Tyner Blain &#187; Prioritizing requirements - three techniques</dc:creator>
		<pubDate>Thu, 19 Jan 2006 05:02:26 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-104</guid>
		<description>[...] This is a good example of why document analysis is important to eliciting requirements. [...]</description>
		<content:encoded><![CDATA[<p>[...] This is a good example of why document analysis is important to eliciting requirements. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tyner Blain &#187; Brainstorming - making something out of everything</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-99</link>
		<dc:creator>Tyner Blain &#187; Brainstorming - making something out of everything</dc:creator>
		<pubDate>Wed, 18 Jan 2006 04:38:11 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-99</guid>
		<description>[...] Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps). [...]</description>
		<content:encoded><![CDATA[<p>[...] Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps). [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marcus Ting-A-Kee</title>
		<link>http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/comment-page-1/#comment-92</link>
		<dc:creator>Marcus Ting-A-Kee</dc:creator>
		<pubDate>Sun, 15 Jan 2006 07:06:20 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/01/14/top-five-requirements-gathering-tips/#comment-92</guid>
		<description>Great post on different techniques people can use to gather requirements!</description>
		<content:encoded><![CDATA[<p>Great post on different techniques people can use to gather requirements!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

