|
|
 | | From: | mlittle84 at hotmail.com | | Subject: | Specifying Data Requirements in the Business Requirements Document... | | Date: | 8 Jan 2005 09:49:31 -0800 |
|
|
 | Hello,
Hello I am business analyst, who has mainly been involved in capturing
data requirements via use cases, but now I am working on a large
business intelligence system development project and this is one area
that I have been a little weak in the past. I was wondering if some-one
could help me?
1. This might be a very basic question, but in the business requirement
document, what is the best way to specify the high level data
requirements and the low level data requirements?
In the document that I am writing, I have numered each high level data
requirement with an unique number, and for each low level data
requirement I have specified it as:
1.1 Unique reference number
1.2 Name of data item such as Company Name;
1.3 Description of data item;
1.4 Priority of data item;
1.5 Example of data item;
1.6 Special Requirements for the data item, such as busines/validation
rules.
A question comes to mind, should I also specify other items such as
data type, size of data, whether nulls are allowed or not, and the
relationships to other data and their multiplicity?
2. If one is gathering data requirements, what other pieces of
information should I also gather? Do I also include the queries that
would use these data items [as it is for a business intelligence
system...]
3. Also I am looking for a newsgroup specifically for Business
Analysts, or even a list server, does some-one where I can find one.
Best Regards, and a happy new year to all!
|
|
| | From: | Jerry Gitomer | | Subject: | Re: Specifying Data Requirements in the Business Requirements Document... | | Date: | Sun, 09 Jan 2005 21:52:57 GMT |
|
|
| mlittle84@hotmail.com wrote:
> Hello,
> Hello I am business analyst, who has mainly been involved in capturing
> data requirements via use cases, but now I am working on a large
> business intelligence system development project and this is one area
> that I have been a little weak in the past. I was wondering if some-one
> could help me?
>
> 1. This might be a very basic question, but in the business requirement
> document, what is the best way to specify the high level data
> requirements and the low level data requirements?
>
> In the document that I am writing, I have numered each high level data
> requirement with an unique number, and for each low level data
> requirement I have specified it as:
> 1.1 Unique reference number
> 1.2 Name of data item such as Company Name;
> 1.3 Description of data item;
> 1.4 Priority of data item;
> 1.5 Example of data item;
> 1.6 Special Requirements for the data item, such as busines/validation
> rules.
>
> A question comes to mind, should I also specify other items such as
> data type, size of data, whether nulls are allowed or not, and the
> relationships to other data and their multiplicity?
>
> 2. If one is gathering data requirements, what other pieces of
> information should I also gather? Do I also include the queries that
> would use these data items [as it is for a business intelligence
> system...]
>
> 3. Also I am looking for a newsgroup specifically for Business
> Analysts, or even a list server, does some-one where I can find one.
> Best Regards, and a happy new year to all!
>
In addition to the items Alan mentioned I like to develop How
Used/Where Used data. From a business standpoint you should
know everyplace in the organization that can create a data item,
everyplace that can change a data item, everyplace that can
delete a data item, everyplace that can view the data item and
how they use it. When you finish building your How Used/Where
Used data make sure it matches your data flow and ERD.
|
|
| | From: | Major Kong | | Subject: | Re: Specifying Data Requirements in the Business Requirements Document... | | Date: | 10 Jan 2005 15:02:36 -0800 |
|
|
| Thanks Guys, I have had a fair bit of experience in terms of ERD [as I
studied it back at uni, but my diagrams always wound up looking like a
new design for an Intel Microprocessor...]and even lookied into UML for
database design, and I have had a lot of experience in gather
functional requirements and capturing the data requirements in a use
case with nicknames, but this is my first business intel project, so I
have have had to gather the data requirements separately from the use
cases in a business requirements document.
|
|
| | From: | Alan | | Subject: | Re: Specifying Data Requirements in the Business Requirements Document... | | Date: | Sat, 8 Jan 2005 14:12:15 -0500 |
|
|
|
wrote in message
news:1105206570.976914.284010@c13g2000cwb.googlegroups.com...
> Hello,
> Hello I am business analyst, who has mainly been involved in capturing
> data requirements via use cases, but now I am working on a large
> business intelligence system development project and this is one area
> that I have been a little weak in the past. I was wondering if some-one
> could help me?
>
> 1. This might be a very basic question, but in the business requirement
> document, what is the best way to specify the high level data
> requirements and the low level data requirements?
>
> In the document that I am writing, I have numered each high level data
> requirement with an unique number, and for each low level data
> requirement I have specified it as:
> 1.1 Unique reference number
> 1.2 Name of data item such as Company Name;
> 1.3 Description of data item;
> 1.4 Priority of data item;
> 1.5 Example of data item;
> 1.6 Special Requirements for the data item, such as busines/validation
> rules.
>
> A question comes to mind, should I also specify other items such as
> data type, size of data, whether nulls are allowed or not, and the
> relationships to other data and their multiplicity?
>
> 2. If one is gathering data requirements, what other pieces of
> information should I also gather? Do I also include the queries that
> would use these data items [as it is for a business intelligence
> system...]
>
> 3. Also I am looking for a newsgroup specifically for Business
> Analysts, or even a list server, does some-one where I can find one.
> Best Regards, and a happy new year to all!
>
Data requirements are captured many ways- actually a combination.
* A data flow diagram (DFD), which shows how data moves from one place to
another (place being a system, form, person, department, report, etc.). It
is created by starting at a very high level, and then decomposing the steps
until you reach the level at which flows can no longer be decomposed into me
aningful smaller steps. Many organizations do not use DFDs, and eventually
find out that when one department requests a change in a system, another
department's data gets messed up.
* An Entity Realtionship Diagram (ERD). This shows the relationships among
the data, and is crucial to a properly designed database. Except for very
small systems, you _always_ need this. You aboslutely need this for this
project. Contact a DBA if you need help. Do not proceed without one.
Whatever you come up with will be wrong without one.
* A data dictionary, which is the last step in the process. You have made
the common mistake of starting with it. You will also need data type and
size for it.
HTH
If you don't know what these things are, you are probably not adequately
prepared to do the job properly.
|
|
| | From: | -P- | | Subject: | Re: Specifying Data Requirements in the Business Requirements Document... | | Date: | Tue, 11 Jan 2005 23:40:47 -0500 |
|
|
| "Alan" wrote in message news:34apnpF495iifU1@individual.net...
>
> wrote in message
> news:1105206570.976914.284010@c13g2000cwb.googlegroups.com...
>> Hello,
>> Hello I am business analyst, who has mainly been involved in capturing
>> data requirements via use cases, but now I am working on a large
>> business intelligence system development project and this is one area
>> that I have been a little weak in the past. I was wondering if some-one
>> could help me?
>>
>> 1. This might be a very basic question, but in the business requirement
>> document, what is the best way to specify the high level data
>> requirements and the low level data requirements?
>>
>> In the document that I am writing, I have numered each high level data
>> requirement with an unique number, and for each low level data
>> requirement I have specified it as:
>> 1.1 Unique reference number
>> 1.2 Name of data item such as Company Name;
>> 1.3 Description of data item;
>> 1.4 Priority of data item;
>> 1.5 Example of data item;
>> 1.6 Special Requirements for the data item, such as busines/validation
>> rules.
>>
>> A question comes to mind, should I also specify other items such as
>> data type, size of data, whether nulls are allowed or not, and the
>> relationships to other data and their multiplicity?
>>
>> 2. If one is gathering data requirements, what other pieces of
>> information should I also gather? Do I also include the queries that
>> would use these data items [as it is for a business intelligence
>> system...]
>>
>> 3. Also I am looking for a newsgroup specifically for Business
>> Analysts, or even a list server, does some-one where I can find one.
>> Best Regards, and a happy new year to all!
>>
>
> Data requirements are captured many ways- actually a combination.
>
> * A data flow diagram (DFD), which shows how data moves from one place to
> another (place being a system, form, person, department, report, etc.). It
> is created by starting at a very high level, and then decomposing the steps
> until you reach the level at which flows can no longer be decomposed into me
> aningful smaller steps. Many organizations do not use DFDs, and eventually
> find out that when one department requests a change in a system, another
> department's data gets messed up.
>
> * An Entity Realtionship Diagram (ERD). This shows the relationships among
> the data, and is crucial to a properly designed database. Except for very
> small systems, you _always_ need this. You aboslutely need this for this
> project. Contact a DBA if you need help. Do not proceed without one.
> Whatever you come up with will be wrong without one.
>
> * A data dictionary, which is the last step in the process. You have made
> the common mistake of starting with it. You will also need data type and
> size for it.
>
> HTH
>
> If you don't know what these things are, you are probably not adequately
> prepared to do the job properly.
>
I find a CRUD matrix very handy as well. It's a matrix with data entities listed along one axis, and business processes
listed down the other. In the intersecting cells, you specify whether the process (C)reates, (R)eads, (U)pdates, or
(D)eletes the entity in question.
Processes that don't interact with any entities, or entities that aren't used by any processes should be examined more
closely...
--
Paul Horan
Sr. Architect
VCI Springfield, Mass
www.vcisolutions.com
|
|
|
