<?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: Requirements Management Software Will Not Solve the Problem</title>
	<atom:link href="http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/</link>
	<description>Software product success.</description>
	<lastBuildDate>Sun, 12 Feb 2012 19:10:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Technical Product Management</title>
		<link>http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/comment-page-1/#comment-1999</link>
		<dc:creator>Technical Product Management</dc:creator>
		<pubDate>Tue, 09 May 2006 16:13:45 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/#comment-1999</guid>
		<description>&lt;strong&gt;Requirements management software will not ......&lt;/strong&gt;

The following are my thoughts on the same:

   1. RM (requirements management) tools, when deployed, affect the working habit of every employee involved in software life-cycle. It is because a requirement should be traceable back to MRD and forward.....</description>
		<content:encoded><![CDATA[<p><strong>Requirements management software will not &#8230;&#8230;</strong></p>
<p>The following are my thoughts on the same:</p>
<p>   1. RM (requirements management) tools, when deployed, affect the working habit of every employee involved in software life-cycle. It is because a requirement should be traceable back to MRD and forward&#8230;..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/comment-page-1/#comment-1351</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Wed, 26 Apr 2006 00:28:59 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/#comment-1351</guid>
		<description>Couldn&#039;t agree more!  Sincerely, thanks for contributing to the discussion and community here - it really does make it a better place.

My wife is helping a friend with kitchen cabinets this week - they made a jig out of cardboard as a drill guide for placing the knob holes.  Funny how it all comes back around.</description>
		<content:encoded><![CDATA[<p>Couldn&#8217;t agree more!  Sincerely, thanks for contributing to the discussion and community here &#8211; it really does make it a better place.</p>
<p>My wife is helping a friend with kitchen cabinets this week &#8211; they made a jig out of cardboard as a drill guide for placing the knob holes.  Funny how it all comes back around.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nils Davis</title>
		<link>http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/comment-page-1/#comment-1347</link>
		<dc:creator>Nils Davis</dc:creator>
		<pubDate>Tue, 25 Apr 2006 23:26:56 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/#comment-1347</guid>
		<description>Scott - excellent points. Getting back to the original analogy, most everything Norm does was done by craftspeople before powertools. But not before steel forging -- so there is some requirement for technology even in the Norm domain. And, these old guys often had to create their own tools (e.g., a dovetail jig or a panel plane) to be able to create their masterpieces. This is something PMs often do, of course. 

The two points have a pendulum effect -- there are things you really can&#039;t do, realistically, unless there&#039;s tool support. But then you still need certain skills and techniques (and even talents) in the domain before you can do a good job, no matter what tools you have available. And then if you have those skills, better tools can enable you to do a better job, or get it done faster, or whatever.</description>
		<content:encoded><![CDATA[<p>Scott &#8211; excellent points. Getting back to the original analogy, most everything Norm does was done by craftspeople before powertools. But not before steel forging &#8212; so there is some requirement for technology even in the Norm domain. And, these old guys often had to create their own tools (e.g., a dovetail jig or a panel plane) to be able to create their masterpieces. This is something PMs often do, of course. </p>
<p>The two points have a pendulum effect &#8212; there are things you really can&#8217;t do, realistically, unless there&#8217;s tool support. But then you still need certain skills and techniques (and even talents) in the domain before you can do a good job, no matter what tools you have available. And then if you have those skills, better tools can enable you to do a better job, or get it done faster, or whatever.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/comment-page-1/#comment-1336</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Tue, 25 Apr 2006 22:00:34 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/#comment-1336</guid>
		<description>Hey Nils, thanks for reading and commenting!

You make some great points that many things would be cost-prohibitive without technology.

I&#039;ve only had one experience with requirements management where a company knew the importance of doing something, knew that a solution existed to make it viable (cost/time), and could/would not invest in the software.

I&#039;ve seen more examples of companies that didn&#039;t appreciate the benefits of the activities (like explicitly associating tests with requirements).  And a couple companies with capability in-house that was not being used effectively (test automation, requirements repository).

To be great, requirements management tools are essential, but insufficient.  Enterprise packages can be better than excel, but following an 80/20 rule, a company with no tools can get pretty far pretty fast &quot;on the cheap.&quot;  Either way, it&#039;s the knowledge of how &lt;i&gt;and why&lt;/i&gt; to use the tools that makes the real difference.</description>
		<content:encoded><![CDATA[<p>Hey Nils, thanks for reading and commenting!</p>
<p>You make some great points that many things would be cost-prohibitive without technology.</p>
<p>I&#8217;ve only had one experience with requirements management where a company knew the importance of doing something, knew that a solution existed to make it viable (cost/time), and could/would not invest in the software.</p>
<p>I&#8217;ve seen more examples of companies that didn&#8217;t appreciate the benefits of the activities (like explicitly associating tests with requirements).  And a couple companies with capability in-house that was not being used effectively (test automation, requirements repository).</p>
<p>To be great, requirements management tools are essential, but insufficient.  Enterprise packages can be better than excel, but following an 80/20 rule, a company with no tools can get pretty far pretty fast &#8220;on the cheap.&#8221;  Either way, it&#8217;s the knowledge of how <i>and why</i> to use the tools that makes the real difference.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nils Davis</title>
		<link>http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/comment-page-1/#comment-1326</link>
		<dc:creator>Nils Davis</dc:creator>
		<pubDate>Tue, 25 Apr 2006 20:29:48 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/02/15/requirements-management-software-will-not-solve-the-problem/#comment-1326</guid>
		<description>Requirements management is an interesting case, in that it *is* possible (barely) to do decet requirements management without tools. It requires lots of manual work, is very error prone, and in general leaves a lot to be desired as far as productivity goes. Just as one example, if you don&#039;t have a central repository for your requirements, then the &quot;gold copy&quot; of the requirements has to travel around the organization (often as many copies, each of which has one set of updates that eventually have to be combined), and it&#039;s never clear who has the last word.  

On the other hand, there *are* product management activities that are so difficult to do in practice that not having a tool to support the activities means they don&#039;t get done.

For example, consider modeling the effectiveness of different sets of requirements (i.e., release scenarios) against different market segments to see which delivers the best return on investment. In practice, even with Excel, you might be able to do this analysis once or twice for a release for two scenarios. But it&#039;s just not feasible to do the analysis against five or ten scenarios, or five different strategies, or to do it every week as your set of unfinished requirements and available resources start to converge. 

It&#039;s like saying that everything you do with Excel you can do on paper - definitely true, but Excel enabled normal people to do whole new types of analysis that they would never have been able to have done before.</description>
		<content:encoded><![CDATA[<p>Requirements management is an interesting case, in that it *is* possible (barely) to do decet requirements management without tools. It requires lots of manual work, is very error prone, and in general leaves a lot to be desired as far as productivity goes. Just as one example, if you don&#8217;t have a central repository for your requirements, then the &#8220;gold copy&#8221; of the requirements has to travel around the organization (often as many copies, each of which has one set of updates that eventually have to be combined), and it&#8217;s never clear who has the last word.  </p>
<p>On the other hand, there *are* product management activities that are so difficult to do in practice that not having a tool to support the activities means they don&#8217;t get done.</p>
<p>For example, consider modeling the effectiveness of different sets of requirements (i.e., release scenarios) against different market segments to see which delivers the best return on investment. In practice, even with Excel, you might be able to do this analysis once or twice for a release for two scenarios. But it&#8217;s just not feasible to do the analysis against five or ten scenarios, or five different strategies, or to do it every week as your set of unfinished requirements and available resources start to converge. </p>
<p>It&#8217;s like saying that everything you do with Excel you can do on paper &#8211; definitely true, but Excel enabled normal people to do whole new types of analysis that they would never have been able to have done before.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

