Q:

Can you suggest good material such as books, research papers and Web resources that can be a guide for writing professional grade data warehouse business requirements? How should analytical requirements be expressed in a language common to business users and to technical people?

A:

Sid Adelman’s Answer: Take a look at Business Intelligence Roadmap, Chapter 4 – "Project Requirements Definition" by Larissa Moss and Shaku Atre and The Data Warehouse Lifecycle Toolkit, Chapter 4 – "Collecting the Requirements" by Ralph Kimball, Laura Reeves, Margy Ross and Warren Thornthwaite.

It’s most important for you to use business terminology whenever possible. Business people hate it when the IT folks confuse them with techie talk. Get and use a business glossary for your industry and if your business people don’t like the glossary definition, use what they like.

Larissa Moss’ Answer: The book I recommend is: Software Requirements and Specifications: A Lexicon of Practice, Principles, and Prejudices by Michael Jackson. Other books that have good chapters on the business requirements:

  • Data Warehouse Project Management by Sid Adelman and Larissa Moss.
  • Writing Effective Use Cases by Alistair Cockburn.
  • e-Data: Turning Data into Information with Data Warehousing by Jill Dyché.
  • The Data Warehouse Lifecycle Toolkit by Ralph Kimball, Laura Reeves, Margy Ross and Warren Thornthwaite.
  • Business Intelligence Roadmap by Larissa Moss and Shaku Atre.

Joe Oates’ Answer: While there are many good books, some by authors in this forum, the most widely used source that I have seen is the "Collecting The Requirements" chapter in The Data Warehouse Lifecycle Toolkit by Ralph Kimball et al. This chapter is very easy to understand for people or organizations that are new to data warehousing. It provides templates and examples on the accompanying CD that can be used "as is."

Many organizations attempt to use their transaction processing approach, which may be developed by or modeled on a transaction processing methodology marketed by a large consulting firm. Many of these requirements approaches result in a requirements document that weighs several pounds and requires a good deal of study to make sense of it.

Kimball’s approach is compact and to the point. It consists primarily of questions that are presented to various positions in the organization. He describes how to organize the questionnaires and resulting "findings."

One thing that I would add to this approach is to add another type of metric deliverable to the list that he presents. That is a "Reporting Metrics Worksheet" which simply lists the metrics or measurements that can be directly lifted from the documented questions or that can be inferred from the documented questions. It is a list of the reporting metric name, a definition of the reporting metric, a formula for the metric (if applicable), the system and data file from which the data to support the development of the reporting metric is to be sourced, a column for each business area involved in the data warehouse project with an "X" for each business area that has the reporting metric as a requirement as well as the priority of the reporting metric by business area and an overall priority (high, medium and low) for each reporting metric. Examples of this kind of metric include average sale price, ratio of revenue to expenses, profitability of marketing campaigns and other information that is usually not easily produced by the source system reporting.

This Reporting Metrics Worksheet provides a concise list of what the management believes can help them make better decisions. The prioritization helps you concentrate on the high and medium reporting metrics that management deems most important rather than spending time on low priority items that take up a huge amount of project time.

Additionally, managers frequently want reporting metrics that cannot be developed from the data produced by their source systems. The Reporting Metrics Worksheet is a good way to let someone know that a particular reporting metric cannot be generated from the source systems before there is great disappointment and political consequences.

Clay Rehm’s Answer: These are good questions and I wish more IT professionals would ask these types of questions and, more importantly, be concerned and interested enough in how to present professional materials that are easy to understand.

The Project Management Institute (PMI) is a great source for the methodology and templates needed for business requirements. I highly recommend you investigate this Web site ( www.pmi.org) and become a member as well.

There is one area that you can win friends with your business partners is when presenting Entity Relationship (ER) diagrams. These diagrams are great for IT folks, but are about the worst thing you can present to non-technical people! Instead of presenting this kind of detail, develop conceptual models instead where the data is at a much higher level of detail (more summarized) and use words that are easy to understand.

Don’t use the word "meeting" when scheduling requirements gathering sessions. Since these are not meetings, (they are brainstorming sessions), put a positive slant on it so your business partners want to come to your sessions!

I am a big believer in diagrams for everything. Put every idea into pictures. Document process flows, data flows, system flows and, most importantly, the strategic vision of how your project fits into the enterprise architecture.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access