<?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: Elicitation Techniques for Processes, Rules, and Requirements</title>
	<atom:link href="http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/</link>
	<description>Software product success.</description>
	<lastBuildDate>Thu, 18 Mar 2010 20:39:50 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: When Rules Meet Requirements &#171; Commercial Intelligence</title>
		<link>http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/comment-page-1/#comment-250513</link>
		<dc:creator>When Rules Meet Requirements &#171; Commercial Intelligence</dc:creator>
		<pubDate>Thu, 03 Jan 2008 18:53:54 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/#comment-250513</guid>
		<description>[...] Consider managing rules and requirements outside a BRMS using requirements management software or as discussed here. Also consider the functionality of requirements management software (e.g., Rational) or BRMS that is not provided by an unassisted word processor or spreadsheet (e.g., as Ruleburst still presents here).  [1] i.e., any form of waterfall development (e.g., iterative or spiral) where implementation is required after rules or requirements are captured or modified [2] Achieving ROI with Rational Requirements Management Tools [3]Note that the limitations of BRMS discussed here are even worse for Complex Event Processing vendors since ease of authoring is much less advanced in the CEP market. [4] Classification and Representation of Business Rules [5] Methods for Managing Business Rules with Haley Authority [6] A roadmap for the elicitation of business rules in information systems projects [7] Elicitation Techniques for Processes, Rules, and Requirements [8] The Unified Process Inception Phase: Best Practices in Implementing the UP (page 99 and here) [9] Blinded by Requirements - Don&#8217;t Miss those Business Rules [10] 1 MORE thing CIOs should know about requirements [11] ISO 9126 re Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability [12] ISO 9126 plus Flexibility, Clarity, Resilience, Generality, Reusability and Economy [13] Functional Requirements and Use Cases [14] Requirements vs Process and Rules [15] Requirements, business process and business rules [16]OMG&#8217;s Business Motivation Model (BMM). [17] as in the Web Ontology Language (OWL) [18]Note that OWL and SBVR address some of these issues but not vocabulary. Ruleburst does not address the issues discussed here. [19]OMG&#8217;s Semantics of Business Vocabulary and Rules (SBVR)&gt; [...]</description>
		<content:encoded><![CDATA[<p>[...] Consider managing rules and requirements outside a BRMS using requirements management software or as discussed here. Also consider the functionality of requirements management software (e.g., Rational) or BRMS that is not provided by an unassisted word processor or spreadsheet (e.g., as Ruleburst still presents here).  [1] i.e., any form of waterfall development (e.g., iterative or spiral) where implementation is required after rules or requirements are captured or modified [2] Achieving ROI with Rational Requirements Management Tools [3]Note that the limitations of BRMS discussed here are even worse for Complex Event Processing vendors since ease of authoring is much less advanced in the CEP market. [4] Classification and Representation of Business Rules [5] Methods for Managing Business Rules with Haley Authority [6] A roadmap for the elicitation of business rules in information systems projects [7] Elicitation Techniques for Processes, Rules, and Requirements [8] The Unified Process Inception Phase: Best Practices in Implementing the UP (page 99 and here) [9] Blinded by Requirements &#8211; Don&#8217;t Miss those Business Rules [10] 1 MORE thing CIOs should know about requirements [11] ISO 9126 re Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability [12] ISO 9126 plus Flexibility, Clarity, Resilience, Generality, Reusability and Economy [13] Functional Requirements and Use Cases [14] Requirements vs Process and Rules [15] Requirements, business process and business rules [16]OMG&#8217;s Business Motivation Model (BMM). [17] as in the Web Ontology Language (OWL) [18]Note that OWL and SBVR address some of these issues but not vocabulary. Ruleburst does not address the issues discussed here. [19]OMG&#8217;s Semantics of Business Vocabulary and Rules (SBVR)&gt; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2007-09-15 &#171; D e j a m e S e r</title>
		<link>http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/comment-page-1/#comment-150840</link>
		<dc:creator>links for 2007-09-15 &#171; D e j a m e S e r</dc:creator>
		<pubDate>Sat, 15 Sep 2007 15:21:20 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/#comment-150840</guid>
		<description>[...] Elicitation Techniques for Processes, Rules, and Requirements &#124; Tyner Blain (tags: requirements) [...]</description>
		<content:encoded><![CDATA[<p>[...] Elicitation Techniques for Processes, Rules, and Requirements | Tyner Blain (tags: requirements) [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
