<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Leaving technology out of requirements gathering</title><link>http://blogs.msdn.com/nickmalik/archive/2008/05/15/leaving-technology-out-of-requirements-gathering.aspx</link><description>I'm going to suggest a minimal way to gather requirements, one that produces a (minimum) requirements document in an iterative and agile manner. A little background In the systems space, it is common to write up a "requirements document" that attempts</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: Leaving technology out of requirements gathering</title><link>http://blogs.msdn.com/nickmalik/archive/2008/05/15/leaving-technology-out-of-requirements-gathering.aspx#8509435</link><pubDate>Fri, 16 May 2008 00:25:59 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8509435</guid><dc:creator>Hesham A. Amin</dc:creator><description>&lt;p&gt;Good post. Leaving technology out of requirements is an important aspect of the quality of requirements document, however I disagree with :&lt;/p&gt;
&lt;p&gt;-[Requirements should describe the &amp;quot;things that technical people need to know&amp;quot; in order to assist in problem solving and empowering business change.]&lt;/p&gt;
&lt;p&gt;I don't believe this is the only purpose, requirements document is a way to keep both business and technical staff are aligned, it also be a way to facilitate communication. Also testers should find enough details that help them create good test cases that cover possible scenarios. Unless you mean that this is going to be only in early iterations.&lt;/p&gt;
&lt;p&gt;-Another point: this process to get No instead of Yes seems OK when IT builds software for companies they are part of, ISVs may think in different way, they should try to (sell) features. Or did I miss something?&lt;/p&gt;</description></item><item><title>re: Leaving technology out of requirements gathering</title><link>http://blogs.msdn.com/nickmalik/archive/2008/05/15/leaving-technology-out-of-requirements-gathering.aspx#8509663</link><pubDate>Fri, 16 May 2008 01:11:03 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:8509663</guid><dc:creator>NickMalik</dc:creator><description>&lt;p&gt;Hi Hesham,&lt;/p&gt;
&lt;p&gt;This post is six hours old, and I'm already thinkng of taking it down or updating it substantially. &amp;nbsp;My first problem with the idea is that I diagrammed a solution (BPM) connected to business problems with no rationale for making that connection. &amp;nbsp;In effect, I started with a solution and went looking to justify it. &amp;nbsp;BAD. &amp;nbsp;&lt;/p&gt;
&lt;p&gt;As far as your objection: well taken. &amp;nbsp;I think I intended to say what you expected to hear, but I failed to be clear. &amp;nbsp;I DON'T think that a requirements document is a useful mechanism for technical folks to communicate to the business. &amp;nbsp;It is essentially a one-way document. &amp;nbsp;A different mechanism (the solution concept) is used to communicate from technical side to the business.&lt;/p&gt;
&lt;p&gt;I agree that ISVs think of the problem space differently. &amp;nbsp;I'm am only talking about IT within a company. &amp;nbsp;IT is on the side of the business, not the ISV, so even if they never write a line of software, they need to insure that the requirements are written in a way that reflects the things that they need, not the things that someone sells them. &amp;nbsp;&lt;/p&gt;
&lt;p&gt;--- Nick&lt;/p&gt;
</description></item></channel></rss>