<?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 for The Whirly Pit</title>
	<atom:link href="http://www.whirlypit.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.whirlypit.com</link>
	<description>Drawing stuff, thinking stuff.</description>
	<lastBuildDate>Thu, 01 May 2014 23:06:23 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=3.9.25</generator>
	<item>
		<title>Comment on Requirements Fixation? by Steve Rapaport</title>
		<link>http://www.whirlypit.com/blog/2014/04/30/requirements/#comment-8</link>
		<dc:creator><![CDATA[Steve Rapaport]]></dc:creator>
		<pubDate>Thu, 01 May 2014 23:06:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.whirlypit.com/?p=73#comment-8</guid>
		<description><![CDATA[When you&#039;re designing a bit of software, you have to design in flexibility for expansion. Some expansion will happen even before the first version is delivered, as the clients come up with &#039;new&#039; requirements. Other expansion will happen in the second or subsequent versions.

But like a building, software needs firm support, too, and allowing for infinite expansion in all directions makes the software blobby and untenable. You have to begin with some assumptions for things that WON&#039;T be required later on. This field will NEVER require more than 80 characters. This object will have a finite number of properties, not an infinite number. This other object may expand infinitely, but only in THIS direction.

Without that list of fixed assumptions, the software architecture will become unwieldy.

So the requirements can be used to set up fixed assumptions, but only if they&#039;re ranked somewhat. A good list will be grouped into
MUST HAVE
SHOULD HAVE
CALL US IF YOU CAN&#039;T
WOULD LIKE
MAYBE IF IT&#039;S NO TROUBLE
FUTURE EXPANSION.

Then the architecture can build on those assumptions.]]></description>
		<content:encoded><![CDATA[<p>When you&#8217;re designing a bit of software, you have to design in flexibility for expansion. Some expansion will happen even before the first version is delivered, as the clients come up with &#8216;new&#8217; requirements. Other expansion will happen in the second or subsequent versions.</p>
<p>But like a building, software needs firm support, too, and allowing for infinite expansion in all directions makes the software blobby and untenable. You have to begin with some assumptions for things that WON&#8217;T be required later on. This field will NEVER require more than 80 characters. This object will have a finite number of properties, not an infinite number. This other object may expand infinitely, but only in THIS direction.</p>
<p>Without that list of fixed assumptions, the software architecture will become unwieldy.</p>
<p>So the requirements can be used to set up fixed assumptions, but only if they&#8217;re ranked somewhat. A good list will be grouped into<br />
MUST HAVE<br />
SHOULD HAVE<br />
CALL US IF YOU CAN&#8217;T<br />
WOULD LIKE<br />
MAYBE IF IT&#8217;S NO TROUBLE<br />
FUTURE EXPANSION.</p>
<p>Then the architecture can build on those assumptions.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
