Jim,

What a great project to be given to work on! I am truly envious!

If it was me, first off I would ask the people who can sanction to the project to proceed (or kill it) how they will know that the data warehouse project was successful? They will measure some things and if those measures hit some targets then they willbehappy bunnies. What are those things? They will start off with woolly stuff like "we want to make better decisions" and the question to ask is "how will you know you are making better decisions?". Make sure you get all the measures that the project can affect (ie is in scope). These are the project objectives.

Fully define scope at least in terms of

1. context: what systems (and people???) will the warehouse get data from?

2. which people/organsiation units will use the warehouse?

3. processes: are the processes to source the data in scope (ie a change maybe to all systems that supply data)

4. locations: where can the warehouse be accessed from

5. any applications/technologies you know will be utilised

Then you are off in to requirements.

The functional requirements are likely to be

1. be able to define reports

2. be able to run reports

3. be able to control who can create and run reports

4. be able to control who can access which data (data level security if required)

5. maybe etc.

There will be some non-functoinals for each of the above:

1. when is it (the function) avaliable?

2. where is it available?

3. who is able to use it?

4. what response times does it need to have?

5. how many transactions per period must it support?

6. maybe  etc

The data requirements is where the fun will be: a logical data model (recommend erd as most rigourous) of data required to be able to build and run the reports that are in scope (by people, through processes, at locations etc) needed to meet the objectives. Make sure that they way you are proposing to model the data requirements is agreed by the suppliers of your requirements and the people who will develop the solution.

For each entity specify

1. primary key - data element(s)/relationship(s) that uniquely identifies an entity

2. other attributes

3. other relationships

4. who can use the entity (security)

5. how many instances the entity must be capable of supportingover the lifetime of the solution

5. how long the entity needs to be kept for

For each attribute specify

1. definition - exactly what it is

2. what type of data in needs to be able to store

3. size - how large the attribute needs to be to store the data in needs to store

4. domain (optional)

5. data rules (optional)

THIS IS NOT A DATABASE DESIGN. You are still only interested in requirements that satisfy objectives.

Techies can take these requirements and design an elegant database using objects, relational tables, whatever they like.

Data modelling is pretty involved and uses a lot of rules, but is very rigourous and gets users to really think about their requirements (I have never had a user say it is too difficult in case you are wondering - your job is not to get them to understand the data model, just to capture their requirements and play the requirements back to them which you do using the model.)

There are some good books on the subject and a great book called Data Model Resource Book that has a lot of 'first cut' 'get you started' data models in and of course my company runs training courses in practical data modelling.

I hope the above helps and have fun!

Guy

Jim,

Glad you found the response thought-provoking!

To answer your questions:

1. "be able to define reports" is not meant to be vague but specifically state that the solution will deliver the capability to allow users to define their own reports. As to how it will do that - this would be answered once the killer stakeholders have agreed that it is in scope to deliver this functionality and that it helps achieve project objectives to give users that ability. The way to answer how it would be done is to draw up a process model showing how the process gets triggered, how users are validated, how they pick items for their report and so on. Of course, if you are selecting a package like Business Objects that is redundant - you just need to the functional requirement in order to be able to select the package that best allows you to achieve objectives.

2. Should the project have in scope fixing data inconsistencies? Well, if the project objectives include increased accuracy of reports then yes! However, if the project objectives don't have anything about quality of data then no (though I would be uncomfortable about delivering a data warehouse with inconsistent data in it and I would want the killer stakeholders to be aware that is what they are getting - in which case the project objectives would probably change!)

All the best,

Guy