<?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 Practical Analyst</title>
	<atom:link href="http://practicalanalyst.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://practicalanalyst.com</link>
	<description>Practical Insight for Business Analysts and Project Professionals</description>
	<lastBuildDate>Thu, 02 Jul 2009 11:07:00 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Could requirements analysis be automated? by JB</title>
		<link>http://practicalanalyst.com/2009/07/01/could-requirements-analysis-be-automated/comment-page-1/#comment-6524</link>
		<dc:creator>JB</dc:creator>
		<pubDate>Thu, 02 Jul 2009 11:07:00 +0000</pubDate>
		<guid isPermaLink="false">http://practicalanalyst.com/?p=1679#comment-6524</guid>
		<description>Interesting stuff, Mark. I&#039;ll take a look at your paper, there.</description>
		<content:encoded><![CDATA[<p>Interesting stuff, Mark. I&#8217;ll take a look at your paper, there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Could requirements analysis be automated? by Mark Norton</title>
		<link>http://practicalanalyst.com/2009/07/01/could-requirements-analysis-be-automated/comment-page-1/#comment-6523</link>
		<dc:creator>Mark Norton</dc:creator>
		<pubDate>Thu, 02 Jul 2009 10:59:23 +0000</pubDate>
		<guid isPermaLink="false">http://practicalanalyst.com/?p=1679#comment-6523</guid>
		<description>Idiom promotes a variation on your theme, using decisioning as the basis and driver of requirements analysis [&lt;a href=&quot;http://www.idiomsoftware.com/pdfs/IDIOM%20Decisioning.pdf&quot; rel=&quot;nofollow&quot;&gt;http://www.idiomsoftware.com/pdfs/IDIOM%20Decisioning.pdf&lt;/a&gt;]

We will be making the Idiom Decision Manager available for free public access this quarter.

We have also built it into a full workbench that we use in collaboration with
partners - product collateral is currently being written up.

The one point I would like to make is that when you can get an automated requirements statement, then you can test it for completeness, consistency, and correctness - after which you can generate the system components that implement it. 

The Idiom Decision Manager produces PDF (English), XML, C#, and Java versions all from the same &#039;requirements spec&#039;.</description>
		<content:encoded><![CDATA[<p>Idiom promotes a variation on your theme, using decisioning as the basis and driver of requirements analysis [<a href="http://www.idiomsoftware.com/pdfs/IDIOM%20Decisioning.pdf" rel="nofollow">http://www.idiomsoftware.com/pdfs/IDIOM%20Decisioning.pdf</a>]</p>
<p>We will be making the Idiom Decision Manager available for free public access this quarter.</p>
<p>We have also built it into a full workbench that we use in collaboration with<br />
partners &#8211; product collateral is currently being written up.</p>
<p>The one point I would like to make is that when you can get an automated requirements statement, then you can test it for completeness, consistency, and correctness &#8211; after which you can generate the system components that implement it. </p>
<p>The Idiom Decision Manager produces PDF (English), XML, C#, and Java versions all from the same &#8216;requirements spec&#8217;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Could requirements analysis be automated? by Kevin Brennan</title>
		<link>http://practicalanalyst.com/2009/07/01/could-requirements-analysis-be-automated/comment-page-1/#comment-6521</link>
		<dc:creator>Kevin Brennan</dc:creator>
		<pubDate>Thu, 02 Jul 2009 02:29:02 +0000</pubDate>
		<guid isPermaLink="false">http://practicalanalyst.com/?p=1679#comment-6521</guid>
		<description>I know of people who are working on automated requirements elicitation tools (using structured surveys to help build business rule or process models), and I believe that something of the sort could be built as an extension of current BPMS systems (many of which already do an excellent job of tracking process metrics--the main addition needed is to integrate with email and similar systems to capture and analyse the informal elements of the process. 
 
I think we will see some of these soon but it&#039;ll be a long time if ever before they&#039;re very good. I have yet to see a requirements management tool that really makes me feel like it lives up to the promise of such tools (to be fair I haven&#039;t tried all the ones on the market), so this, which is a lot more ambitious, seems like it will take a while. 
 
 </description>
		<content:encoded><![CDATA[<p>I know of people who are working on automated requirements elicitation tools (using structured surveys to help build business rule or process models), and I believe that something of the sort could be built as an extension of current BPMS systems (many of which already do an excellent job of tracking process metrics&#8211;the main addition needed is to integrate with email and similar systems to capture and analyse the informal elements of the process. </p>
<p>I think we will see some of these soon but it&#039;ll be a long time if ever before they&#039;re very good. I have yet to see a requirements management tool that really makes me feel like it lives up to the promise of such tools (to be fair I haven&#039;t tried all the ones on the market), so this, which is a lot more ambitious, seems like it will take a while.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Could requirements analysis be automated? by D wright</title>
		<link>http://practicalanalyst.com/2009/07/01/could-requirements-analysis-be-automated/comment-page-1/#comment-6518</link>
		<dc:creator>D wright</dc:creator>
		<pubDate>Wed, 01 Jul 2009 23:22:14 +0000</pubDate>
		<guid isPermaLink="false">http://practicalanalyst.com/?p=1679#comment-6518</guid>
		<description>It would have to be groupware! Stakeholders for one project always come in multiples, with different interests and goals that have to be merged in a way that all will accept the result. </description>
		<content:encoded><![CDATA[<p>It would have to be groupware! Stakeholders for one project always come in multiples, with different interests and goals that have to be merged in a way that all will accept the result.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Structured Analysis &amp; Big, Thick Documents by Kupe</title>
		<link>http://practicalanalyst.com/2009/06/29/structured-analysis-big-thick-documents/comment-page-1/#comment-6514</link>
		<dc:creator>Kupe</dc:creator>
		<pubDate>Wed, 01 Jul 2009 02:13:20 +0000</pubDate>
		<guid isPermaLink="false">http://practicalanalyst.com/?p=1665#comment-6514</guid>
		<description>JB,  Thanks for blogging about what you read.  I look forward to checking it out.  I love the &quot;just enough&quot; concept.  We need to do what adds value to the success of the project. </description>
		<content:encoded><![CDATA[<p>JB,  Thanks for blogging about what you read.  I look forward to checking it out.  I love the &quot;just enough&quot; concept.  We need to do what adds value to the success of the project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Business Analysts: Domain Experts or Generalists? by JB</title>
		<link>http://practicalanalyst.com/2007/07/03/business-analysts-smes-or-generalists/comment-page-1/#comment-6510</link>
		<dc:creator>JB</dc:creator>
		<pubDate>Tue, 30 Jun 2009 21:42:01 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanbabcock.com/2007/07/03/business-analysts-smes-or-generalists/#comment-6510</guid>
		<description>I think of specific systems expertise and general &quot;possibilities of technology&quot;-type knowledge as different rungs on the same ladder. 
 
And I absolutely think it is incumbent on the BA to be able to break down the possibilities of technology in terms that business folk can digest. And to be able to do that, obviously, we have to have some of that knowledge ourselves. </description>
		<content:encoded><![CDATA[<p>I think of specific systems expertise and general &quot;possibilities of technology&quot;-type knowledge as different rungs on the same ladder. </p>
<p>And I absolutely think it is incumbent on the BA to be able to break down the possibilities of technology in terms that business folk can digest. And to be able to do that, obviously, we have to have some of that knowledge ourselves.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Business Analysts: Domain Experts or Generalists? by JB</title>
		<link>http://practicalanalyst.com/2007/07/03/business-analysts-smes-or-generalists/comment-page-1/#comment-6508</link>
		<dc:creator>JB</dc:creator>
		<pubDate>Tue, 30 Jun 2009 21:10:04 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanbabcock.com/2007/07/03/business-analysts-smes-or-generalists/#comment-6508</guid>
		<description>Thanks for the comment, Alex.  
 
Honestly, I am still fleshing out how &quot;I&quot; want to define the various &quot;domains&quot; of BA knowledge/skill - which may be non-standard anyway, so you&#039;re right I&#039;m not sure that my usage of &quot;domain expert&quot; in this context is the best.  
 
I think I&#039;m pretty close to getting my stuff together, though, and if I can get some time this evening after the kids are down &amp; before I crash, I&#039;ll try to post my thoughts. 
 
Re: the differentiation &quot;between between an analyst who focuses on a particular business domain as opposed to one can apply themselves to any domain&quot; in career terms - I think that&#039;s part of where David wants to take the conversation. I&#039;d certainly be interested in hearing everyone&#039;s thoughts on that as well.  
 
Maybe a topic for a round of posts on our respective blogs? </description>
		<content:encoded><![CDATA[<p>Thanks for the comment, Alex.  </p>
<p>Honestly, I am still fleshing out how &quot;I&quot; want to define the various &quot;domains&quot; of BA knowledge/skill &#8211; which may be non-standard anyway, so you&#039;re right I&#039;m not sure that my usage of &quot;domain expert&quot; in this context is the best.  </p>
<p>I think I&#039;m pretty close to getting my stuff together, though, and if I can get some time this evening after the kids are down &amp; before I crash, I&#039;ll try to post my thoughts. </p>
<p>Re: the differentiation &quot;between between an analyst who focuses on a particular business domain as opposed to one can apply themselves to any domain&quot; in career terms &#8211; I think that&#039;s part of where David wants to take the conversation. I&#039;d certainly be interested in hearing everyone&#039;s thoughts on that as well.  </p>
<p>Maybe a topic for a round of posts on our respective blogs?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Business Analysts: Domain Experts or Generalists? by JB</title>
		<link>http://practicalanalyst.com/2007/07/03/business-analysts-smes-or-generalists/comment-page-1/#comment-6507</link>
		<dc:creator>JB</dc:creator>
		<pubDate>Tue, 30 Jun 2009 21:01:05 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanbabcock.com/2007/07/03/business-analysts-smes-or-generalists/#comment-6507</guid>
		<description>I hear what you&#039;re saying on the domain shifts, David. I think there&#039;s a certain degree of technical know-how that you just pick up by working with systems in general over time, too. Regardless of the industry, you&#039;re well served by having a fundamental understanding of architecture, and the way systems work.  
  
The analysis skills are the ones we can&#039;t do without, though. 
 
I think that&#039;s a great suggestion for an upcoming topic, too. I think the vendor/software experience has a lot to do with multiple factors including - consultant vs. perm. BA for a company; consultant in a specific field or technology vs. general business analysis/project management consultancy, etc.  
 
It is a conversation I think it&#039;d be interesting to have. Just need to get my thoughts together on it, first. </description>
		<content:encoded><![CDATA[<p>I hear what you&#039;re saying on the domain shifts, David. I think there&#039;s a certain degree of technical know-how that you just pick up by working with systems in general over time, too. Regardless of the industry, you&#039;re well served by having a fundamental understanding of architecture, and the way systems work.  </p>
<p>The analysis skills are the ones we can&#039;t do without, though. </p>
<p>I think that&#039;s a great suggestion for an upcoming topic, too. I think the vendor/software experience has a lot to do with multiple factors including &#8211; consultant vs. perm. BA for a company; consultant in a specific field or technology vs. general business analysis/project management consultancy, etc.  </p>
<p>It is a conversation I think it&#039;d be interesting to have. Just need to get my thoughts together on it, first.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Business Analysts: Domain Experts or Generalists? by JB</title>
		<link>http://practicalanalyst.com/2007/07/03/business-analysts-smes-or-generalists/comment-page-1/#comment-6506</link>
		<dc:creator>JB</dc:creator>
		<pubDate>Tue, 30 Jun 2009 20:56:47 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanbabcock.com/2007/07/03/business-analysts-smes-or-generalists/#comment-6506</guid>
		<description>I hear what you&#039;re saying on the domain shifts, David. I think there&#039;s a certain degree of technical know-how that you just pick up by working with systems in general over time, too. Regardless of the industry, you&#039;re well served by having a fundamental understanding of architecture, and the way systems work. 
 
The analysis skills are the ones we can&#039;t do without, though. </description>
		<content:encoded><![CDATA[<p>I hear what you&#039;re saying on the domain shifts, David. I think there&#039;s a certain degree of technical know-how that you just pick up by working with systems in general over time, too. Regardless of the industry, you&#039;re well served by having a fundamental understanding of architecture, and the way systems work. </p>
<p>The analysis skills are the ones we can&#039;t do without, though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Structured Analysis &amp; Big, Thick Documents by JB</title>
		<link>http://practicalanalyst.com/2009/06/29/structured-analysis-big-thick-documents/comment-page-1/#comment-6505</link>
		<dc:creator>JB</dc:creator>
		<pubDate>Tue, 30 Jun 2009 20:53:31 +0000</pubDate>
		<guid isPermaLink="false">http://practicalanalyst.com/?p=1665#comment-6505</guid>
		<description>You&#039;re most welcome. Thank YOU for providing all the great material. I love the wiki idea. </description>
		<content:encoded><![CDATA[<p>You&#039;re most welcome. Thank YOU for providing all the great material. I love the wiki idea.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
