<?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: Yikes! What about the data?</title>
	<atom:link href="http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/</link>
	<description>Connecting Business Requirements to Technology</description>
	<lastBuildDate>Wed, 28 Jul 2010 20:41:26 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Kerber</title>
		<link>http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/comment-page-1/#comment-1065</link>
		<dc:creator>Kerber</dc:creator>
		<pubDate>Wed, 19 Sep 2007 00:08:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/#comment-1065</guid>
		<description>Well Angie, over here we work very close to the system analysts and we can fell the heat when things are not well modeled from the beginning. Maybe the path to reach a good environment is the knowledge of the whole process and each part</description>
		<content:encoded><![CDATA[<p>Well Angie, over here we work very close to the system analysts and we can fell the heat when things are not well modeled from the beginning. Maybe the path to reach a good environment is the knowledge of the whole process and each part</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig</title>
		<link>http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/comment-page-1/#comment-1061</link>
		<dc:creator>Craig</dc:creator>
		<pubDate>Mon, 17 Sep 2007 11:48:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/#comment-1061</guid>
		<description>There are plenty of tools to make sure your requiremenst capture data as well as everything else.  Personally I like the Method H model provided at &lt;a href=&quot;http://www.projectperfect.com.au/info_method_h.php&quot; rel=&quot;nofollow&quot;&gt;Project Perfect&lt;/a&gt;

From the story above I presume the real problem was too many people involved in requirements management. Managing complexity is often proxy for managing lots of people.

Craig @ &lt;a href=&quot;http://betterprojects.blogspot.com&quot; rel=&quot;nofollow&quot;&gt;Better Projects&lt;/a&gt;
&lt;a href=&quot;http://www.modernanalyst.com&quot; rel=&quot;nofollow&quot;&gt;Modern Analyst&lt;/a&gt; - Core Member</description>
		<content:encoded><![CDATA[<p>There are plenty of tools to make sure your requiremenst capture data as well as everything else.  Personally I like the Method H model provided at <a href="http://www.projectperfect.com.au/info_method_h.php" rel="nofollow">Project Perfect</a></p>
<p>From the story above I presume the real problem was too many people involved in requirements management. Managing complexity is often proxy for managing lots of people.</p>
<p>Craig @ <a href="http://betterprojects.blogspot.com" rel="nofollow">Better Projects</a><br />
<a href="http://www.modernanalyst.com" rel="nofollow">Modern Analyst</a> &#8211; Core Member</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Angie</title>
		<link>http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/comment-page-1/#comment-1060</link>
		<dc:creator>Angie</dc:creator>
		<pubDate>Sat, 15 Sep 2007 00:56:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/#comment-1060</guid>
		<description>Thank you for your responses. Yes - Chris- they really did design the UI without any thought to what was going to happen to the data once it was collected. Edmundo, great user questions, especially in an agile environment - - thank you. I have also noticed that many people in IT do not seem to comprehend the importance of data requirements. Sounds like Kerber is the one working in an enlightened place that truly understands the benefits of documenting and analyzing data requirements. With our core training we love to get our BAs excited about how much they can learn about the business through elicitation of the data requirements. There is hope for the rest...</description>
		<content:encoded><![CDATA[<p>Thank you for your responses. Yes &#8211; Chris- they really did design the UI without any thought to what was going to happen to the data once it was collected. Edmundo, great user questions, especially in an agile environment &#8211; - thank you. I have also noticed that many people in IT do not seem to comprehend the importance of data requirements. Sounds like Kerber is the one working in an enlightened place that truly understands the benefits of documenting and analyzing data requirements. With our core training we love to get our BAs excited about how much they can learn about the business through elicitation of the data requirements. There is hope for the rest&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kerber</title>
		<link>http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/comment-page-1/#comment-1064</link>
		<dc:creator>Kerber</dc:creator>
		<pubDate>Fri, 14 Sep 2007 14:49:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/#comment-1064</guid>
		<description>I don&#39;t know if it happens because I work close to the system analysts but our process involves the modeling of the entity classes by the business analyst, this model includes the relationships, multiplicities, generalizations and of course, properties. But it doesn&#39;t end here. Every use case objective is to change the properties of one or more entities. That means that there&#39;s always a direct relation between the use case description and the entity classes diagram. For each use case we describe, we attach the affected classes and&nbsp;their affected properties and it reduces the chance to forget about some data to zero. That&#39;s also a good reason to treat reports as use cases because if you want to report something, it&#39;s got to be somewhere, and you have to show where it is. Kerber ITBA - Digitro Technology www.digitro.com &lt;a href=&quot;http://www.kerber.com.br/&quot;&gt;www.kerber.com.br&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p>I don&#38;#39;t know if it happens because I work close to the system analysts but our process involves the modeling of the entity classes by the business analyst, this model includes the relationships, multiplicities, generalizations and of course, properties. But it doesn&#38;#39;t end here. Every use case objective is to change the properties of one or more entities. That means that there&#38;#39;s always a direct relation between the use case description and the entity classes diagram. For each use case we describe, we attach the affected classes and&#38;nbsp;their affected properties and it reduces the chance to forget about some data to zero. That&#38;#39;s also a good reason to treat reports as use cases because if you want to report something, it&#38;#39;s got to be somewhere, and you have to show where it is. Kerber ITBA &#8211; Digitro Technology <a href="http://www.digitro.com" rel="nofollow">http://www.digitro.com</a> <a href="http://www.kerber.com.br/">http://www.kerber.com.br</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Edmundo</title>
		<link>http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/comment-page-1/#comment-1063</link>
		<dc:creator>Edmundo</dc:creator>
		<pubDate>Thu, 13 Sep 2007 14:50:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/#comment-1063</guid>
		<description>As someone on the DBA side of the house who is more interested in the housing and care of data than the newest features of the DBMS, there are several questions that you can ask to get to data requirements.  (Mind you, I&#039;m just trying to get to understanding how to formalize data requirements myself).

1. If your story has the user doing any kind of data entry, ask if the user or anyone else will ever expect to see that data again.

2. Assuming yes to 1, how soon do others after the user clicks OK to persist data do others need to see this data?  (Often if it is some kind of master data, it needs to be pushed to another system).

3. Will the users have any ability to set preferences in the system?  Some examples could be an email address to get alerts, frequency of certain events, whether they use IE or Firefox for their browser.

4. If this is a subscription service or an internal application, who will manage the users of the system?

5. For any of 1, 2 and 3, who will manage the data?  Typically, application support (especially off-shore) consists of programmer types who don&#039;t really understand the business and the data rules.  If a user says they entered a change on Friday but they don&#039;t see it, who will know the data enough to analyze it?  Often figuring out who will own the data is a tough decision for an organization.

Those are some starter thoughts.  I have found that even in a very large organization with very experienced Software folks, the majority of the folks in IT don&#039;t care about data.  Ergo, of course, data requirements are frequently given minimal attention.</description>
		<content:encoded><![CDATA[<p>As someone on the DBA side of the house who is more interested in the housing and care of data than the newest features of the DBMS, there are several questions that you can ask to get to data requirements.  (Mind you, I&#8217;m just trying to get to understanding how to formalize data requirements myself).</p>
<p>1. If your story has the user doing any kind of data entry, ask if the user or anyone else will ever expect to see that data again.</p>
<p>2. Assuming yes to 1, how soon do others after the user clicks OK to persist data do others need to see this data?  (Often if it is some kind of master data, it needs to be pushed to another system).</p>
<p>3. Will the users have any ability to set preferences in the system?  Some examples could be an email address to get alerts, frequency of certain events, whether they use IE or Firefox for their browser.</p>
<p>4. If this is a subscription service or an internal application, who will manage the users of the system?</p>
<p>5. For any of 1, 2 and 3, who will manage the data?  Typically, application support (especially off-shore) consists of programmer types who don&#8217;t really understand the business and the data rules.  If a user says they entered a change on Friday but they don&#8217;t see it, who will know the data enough to analyze it?  Often figuring out who will own the data is a tough decision for an organization.</p>
<p>Those are some starter thoughts.  I have found that even in a very large organization with very experienced Software folks, the majority of the folks in IT don&#8217;t care about data.  Ergo, of course, data requirements are frequently given minimal attention.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 'Chris</title>
		<link>http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/comment-page-1/#comment-1062</link>
		<dc:creator>'Chris</dc:creator>
		<pubDate>Wed, 12 Sep 2007 19:57:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.b2ttraining.com/2007/09/10/yike-what-about-the-data/#comment-1062</guid>
		<description>If I understand your story correctly, the UI was designed to accept the data, but nobody took the time to analyze the data being collected by the UI? This seems like an obvious miss. I absolutely agree that somebody should be analyzing every single piece of data required for the new system. Who does that and when may vary based on the analysis process being used for the particular project. I&#039;ve seen some projects where Business Systems Analysts define the data (not the structure of the database), and others where a dedicated Data Analyst or Data Team defines the data only asking the Business Systems Analyst to do additional analysis when necessary. - Chris Modern Analyst, Core Member www.modernanalyst.com</description>
		<content:encoded><![CDATA[<p>If I understand your story correctly, the UI was designed to accept the data, but nobody took the time to analyze the data being collected by the UI? This seems like an obvious miss. I absolutely agree that somebody should be analyzing every single piece of data required for the new system. Who does that and when may vary based on the analysis process being used for the particular project. I&#8217;ve seen some projects where Business Systems Analysts define the data (not the structure of the database), and others where a dedicated Data Analyst or Data Team defines the data only asking the Business Systems Analyst to do additional analysis when necessary. &#8211; Chris Modern Analyst, Core Member <a href="http://www.modernanalyst.com" rel="nofollow">http://www.modernanalyst.com</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
