<?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: Separating Business Rules From Requirements Increases Agility</title>
	<atom:link href="http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/</link>
	<description>Software product success.</description>
	<lastBuildDate>Tue, 22 May 2012 20:46:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/comment-page-1/#comment-123850</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Sat, 21 Jul 2007 04:09:26 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/#comment-123850</guid>
		<description>Y&#039;all are both right - and welcome to Tyner Blain, and thanks for reading and commenting!

There are some interesting things to think about, especially with implicit rules.  If we abstract the rules out of the requirements, then we need a way to reference those rules.  But what about &quot;implicit rules&quot; like Roger mentions in the discussion on another article.

For example - a rule that specifies that steps in a use case must happen in a particular order (user is authenticated prior to transaction processing).  We should make sure we capture that as well - even if it only prevents a violation of the rule during a future revision of the requirements.</description>
		<content:encoded><![CDATA[<p>Y&#8217;all are both right &#8211; and welcome to Tyner Blain, and thanks for reading and commenting!</p>
<p>There are some interesting things to think about, especially with implicit rules.  If we abstract the rules out of the requirements, then we need a way to reference those rules.  But what about &#8220;implicit rules&#8221; like Roger mentions in the discussion on another article.</p>
<p>For example &#8211; a rule that specifies that steps in a use case must happen in a particular order (user is authenticated prior to transaction processing).  We should make sure we capture that as well &#8211; even if it only prevents a violation of the rule during a future revision of the requirements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gina</title>
		<link>http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/comment-page-1/#comment-122393</link>
		<dc:creator>Gina</dc:creator>
		<pubDate>Wed, 18 Jul 2007 02:33:59 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/#comment-122393</guid>
		<description>I totally agree. The fact that breaking down tasks into smaller pieces makes the process easier, gives this idea a strong point. We don&#039;t have to involve everything on the process if it doesn&#039;t need it.</description>
		<content:encoded><![CDATA[<p>I totally agree. The fact that breaking down tasks into smaller pieces makes the process easier, gives this idea a strong point. We don&#8217;t have to involve everything on the process if it doesn&#8217;t need it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Helen</title>
		<link>http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/comment-page-1/#comment-121899</link>
		<dc:creator>Helen</dc:creator>
		<pubDate>Tue, 17 Jul 2007 06:01:30 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/07/12/business-rules-yield-agility/#comment-121899</guid>
		<description>You make a good point about separating business requirements from business rules. Having less effort and less time to change are great benefits of separating those two..</description>
		<content:encoded><![CDATA[<p>You make a good point about separating business requirements from business rules. Having less effort and less time to change are great benefits of separating those two..</p>
]]></content:encoded>
	</item>
</channel>
</rss>

