<?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: Software Requirements &#8211; Process and Roles</title>
	<atom:link href="http://tynerblain.com/blog/2006/02/13/software-requirements-process-and-roles/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2006/02/13/software-requirements-process-and-roles/</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: Roger L. Cauvin</title>
		<link>http://tynerblain.com/blog/2006/02/13/software-requirements-process-and-roles/comment-page-1/#comment-288</link>
		<dc:creator>Roger L. Cauvin</dc:creator>
		<pubDate>Tue, 14 Feb 2006 02:00:46 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2006/02/13/software-requirements-process-and-roles/#comment-288</guid>
		<description>I like the following two points:

1.  Part of what matters in the requirements/design debate are the implications for the different roles and skill sets that participate in requirements and design activities.  Effective requirements elicitation and formulation necessitates asking &quot;why?&quot; and being able to sift through customer requests that are often worded as solutions rather than problems to be solved.  UI and software design require very different skill sets.  To dismiss the debate as purely semantic, with no practical consequences, would be naive.

2.  Despite the importance of the distinct concepts and roles, feedback occurs.  You can&#039;t realistically determine which problems you can solve without having some idea of what solutions are feasible.  For this reason, it helps when a skilled requirements analyst has some knowledge of design.  I give an example of this sort of overlap and coordination &lt;a href=&quot;http://cauvin.blogspot.com/2005/07/product-design-example.html&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>I like the following two points:</p>
<p>1.  Part of what matters in the requirements/design debate are the implications for the different roles and skill sets that participate in requirements and design activities.  Effective requirements elicitation and formulation necessitates asking &#8220;why?&#8221; and being able to sift through customer requests that are often worded as solutions rather than problems to be solved.  UI and software design require very different skill sets.  To dismiss the debate as purely semantic, with no practical consequences, would be naive.</p>
<p>2.  Despite the importance of the distinct concepts and roles, feedback occurs.  You can&#8217;t realistically determine which problems you can solve without having some idea of what solutions are feasible.  For this reason, it helps when a skilled requirements analyst has some knowledge of design.  I give an example of this sort of overlap and coordination <a href="http://cauvin.blogspot.com/2005/07/product-design-example.html" rel="nofollow">here</a>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

