Bob Lambert

Jazz on the harmonica

Business Intelligence Requirements: The Payoff’s in the Details


A technique for reporting requirements has emerged as the de facto standard in the business intelligence community. The technique, which emerged in the mid-2000s, is new enough to be as yet unacknowledged Fact Qualifier Matrixby the requirements analysis powers that be. David Loshin describes how it works in this 2007 post:

  • Start with a business question about how to monitor a business process using a metric, like “How many widgets have been shipped by size each week by warehouse?”
  • Identify the business measure requested in the business question, in this case “count of widgets shipped”, and the qualifiers by which the measure is classified: week and warehouse.
  • Do that for a set of similar business questions, and arrange the results into a “Fact/Qualifier Matrix”. To create a Fact/Qualifier Matrix, first number the business questions, then create a spreadsheet with one row for each qualifier and a column for each fact. Put business question numbers in each applicable fact/qualifier intersection cell. So a Fact/Qualifier Matrix showing Loshin’s example may look like the example shown, assuming our business question is number 1.

By defining facts and qualifiers, and showing which business questions they apply to, the analyst has gone most of the way toward defining information needs. However, one step remains: Facts and qualifiers defined in terms useful to the business may leave questions of interpretation in the hands of designers.

In order to fully define business needs without risk of misinterpretation the analyst should ensure that facts and qualifiers are defined as data elements. Although data modelers have discretion in how they use them in design, the list of data items serve as firm business specifications grounded in business questions. In order to serve this purpose effectively the process should result in well-formed data elements.

A data element may also be called a data item or an “attribute”. Attribute is a data modeling term that reflects the role of data modeling’s study of objects and events of interest to the business, like employees, accounts, or sales transactions. These objects and events are called “entities” in data modeling parlance. The items that describe those objects and events, like employee salary, account balance, or sales quantity, are called “attributes” of those entities.  Attributes may be thought of object/event characteristics, and of course also as data items.

A data item is also called a data “element” because it is both primitive and atomic.

  • A primitive data item exists independently of other data items and it is not derived from any other data items. For example, salary of an employee is a primitive, while average salary of all employees is derived.
  • An atomic data item expresses only one concept. Strictly speaking, year of birth is an atomic data element, while birthdate might be considered non-atomic because it embeds year, month, and day.

Driving to detail by expressing facts and qualifiers is a great way to express detailed business intelligence requirements in a form that business people can understand and evaluate. It also provides an explicit guide to BI developers of exactly what the business wants.

Update 2/27/14: Astute reader John noted that our FQM was missing the size dimension, so size is crossed out of the relevant business question



, ,


3 responses to “Business Intelligence Requirements: The Payoff’s in the Details”

  1. Hi Bob,

    The business question posed was “How many widgets have been shipped by size each week by warehouse?”

    You show qualifiers (a.k.a. dimensions) for week and warehouse. Should there also be a qualifier for size?

Leave a Reply

Your email address will not be published. Required fields are marked *