Business Requirements Document

Does anyone have a sample or template business requirements document for a DW/BI project? I was looking to see what sections others are including and how they are structuring the document as I am just starting a new project.

Thanks!

This site has some good templates, although they are not specific to data warehousing:
http://www.construx.com/Page.aspx?nid=204

This guy literally wrote the book on software requirements:
http://www.processimpact.com/goodies.shtml#reqs

Kimball's Lifecycle Toolkit has a CD with various templates for requirements definition and such.

Frankly, I do not find generic requirements (ie those that are not DW/BI specific) documents particulary useful. Common practice and methodologies for requirements definition of software to implement a business process (i.e. OLTP applications) are significantly different and overblown for data warehouse requirements.

Hmm,

My copy of Raplh's DW Lifecycle Toolkit (2nd Ed) makes no mention of a CD, and I can't find any such template on his Web site, only a business requirements questionnaire. When did the CD come out?

It was the original version... I haven't seen the 2nd edition.

Dare I suggest that traditional and formal business requirements just don't work for BI/DW developments? All too often the real content only comes to light when the work begins. However, a really, really useful tool is the Kimball 2x2 grid where proposed subject areas or business processes are ranked by you and your business colleagues in terms of business impact and feasibility. I've used this twice and it is a fantastic, simple and effective tool to work out what to work on at a very high level.
In terms of working out what to do, when it should be done and who should do it, I would urge anyone embarking on a BI/DW project to consider using an agile development method. Scrum is the one we and a growing number of sites use. I've blogged a fair bit about it in the past and wrote some discussion responses up the other day here.
There is the makings of a very interesting collaborative project just getting off the ground - a book on the application of agile to BI/DW projects - again you can read more about that and even sign up to be part of the process here.

robhale wrote:Dare I suggest that traditional and formal business requirements just don't work for BI/DW developments?

Agree with you 110% The beauty of a dimensional approach is that it is inherently incremental in its implementation. All it takes is a little bit of forethought in identifying integration points (conforming dimensions).

i agree that Business requirements for a BI/DW project are very differents from transactional projects.

The templates of business requirements depend on the BI maturity of your company, but still are grouped into two major categories :
- olap templates ( for multidimensional analysis )
- Reporting templates

For the Molap Template, a good starting point is the Datawarehouse(datamart) matrix, which represents facts in rows and dimensions in columns, very usefull to depicte your fact tables and your dimensions. In a BI Mature company, this kind of matrix could be filled by the end users easilly, in contrario you have to assist them in the first iteration...

About the reporting template, for each report we define the header ( the name of the report, the refreshement cycle, the type of the report :list, chart, pie..., the destinations of it will be sent by email....). We also define the report template body, which is composed of the column business name, a short description, a formula to calculate the column if it's calculated...

These are the basic templates, you probably also need templates for the scorcarding and perhaps for data mining...

Once we gattered all this documents, we can start our dimensional modelling ...

hope this help.

I agree with those who suggest that waterfall PM methods do not work well for BI projects. If you want to build a data mart, or even a data warehouse, what is needed is a light-weight approach to tackling each mart as a prototype. The goal should be to work with a small team who is willing and able to get their hands dirty with the data, and use their feedback to refine the design as lessons learned become apparent. Gathering requirements "up front" simply does not work as well, because of the simple truth that the users likely will not know what they want until afterthe project gets started. Also, "requirements" discussions tend to bog down when there isn't anything to look at. Imagine if you spent the time building the no-brainer data marts, with atomic data, in clean star schema structures. All you would need to do is build some simple charts to get people to engage in useful discussion (assuming you had the right people in the room). You could also start working at the bus level, but this is hard for users to grasp in early stages, so I typically play that by ear.

I believe that agile is optimized for delivering presentation layer features, and breaks down rapidly if the project in question is tasked with both front room and back room tasks. Even when using agile for the right type of project, you have to take care that you don't move too fast. Delivering value is not the same as delivering code. If the team is simply operating in a vacuum, or if the client/users are "somewhat" engaged, the results will likely disappoint over time.

So the way I think of these two methods is much like thesis (waterfall) vs. antithesis (agile). What most projects need is a way to blend the two approaches together (synthesis). Sure, there are exceptions. If you work for a solutions firm, then it really is about the code being published quickly; or, maybe the culture at your organization simply can't grok anything not waterfall, etc. In either case, you're stuck, at least for a while.

Project management is crucial to any serious project that involves coordination of people, time, and resources. But what is really missing is project leadership. The Kimball methods articulate the beauty of the incremental approach, and that each small project can be a building block to something greater than the sum of its parts. If you really want to build a DW then each project needs to have that goal in mind. Otherwise, you are doing custom development. Which, is fine, but something different than building a data warehouse. A project leader needs to be able to make this distinction.

Anyway, I think there should be a rethinking of waterfall and how it is used.

A requirements document is not only used in waterfall development methods, and Agile methods all state that there should be up-front discussions and documentation of user needs.

A 300 page document isn't needed to do prototyping, and even the most stringent Department of Defense mandated process allows for prototyping. But if you don't know what the user wants, how are you going to go ahead and prototype it?

You can't, you implicitly need a grasp of the user needs in order to develop a prototype.


As an incredibly experienced former co-worker used to say "Spiral development is just a waterfall wrapped around an axis."

I have read all the reviews and though given by the readers. After finishing, i am totally agree with CK Stevenson that "A 300 page document isn't needed to do prototyping, and even the most stringent Department of Defense mandated process allows for prototyping. But if you don't know what the user wants, how are you going to go ahead and prototype it?"