More and more companies are learning the hard way that business requirements for business intelligence (BI) are not something to be taken lightly. After paying hundreds of thousands of dollars in consulting fees for generic BI requirements, or after spending months generating traditional report requirements and functional specifications, major companies in many different industries have discovered that these approaches suffer from three primary deficiencies:

  • They do not provide the basis for a compelling business case that business leaders buy into, one that clearly articulates how BI will be used within specific business processes to improve business performance.
  • They do not provide enough specificity with respect to the kinds of BI applications that are needed, whereas BI is a broad term that encompasses a wide range of applications, from basic reporting and OLAP to sophisticated analytics.
  • They do not provide enough specificity to guide development of the BI databases and applications that deliver the BI or to guide the business process changes that deliver the bang for the buck to the business.

The use of inappropriate and expensive BI business requirements methods leads to failed BI investments and discrediting of BI as a profit improvement tool. This happens just at the time when more sophisticated competitors using business-driven requirements methods are reaping the strategic and financial benefits of BI done correctly.
To avoid dissatisfied business users and unhappy senior executives, it is critical to understand what it means to get BI business requirements right. You must know how to use true BI business requirements to drive definition and prioritization of the BI portfolio as the foundation for a compelling business case, and you must be able to use business requirements to drive development of the BI databases, BI applications and enhanced business processes that create business value. Considering examples from my consulting experience that illustrate incomplete or insufficient BI requirements will set the stage for discussing what it means to get BI business requirements right.

The Weakness of Generic BI Business Requirements

Consultants often run into situations where major companies ask us to help develop a BI strategy, which includes a business case, a BI portfolio and opportunity map, and a BI requirements document. In many cases, the BI team has already taken a stab at a business case and/or a requirements document, which typically contain statements such as:

  • Produce enhanced organizational capabilities to manage data and information as organizational assets.
  • Provide a single version of the truth.
  • Enable consistent and reliable access to accurate corporate-wide data.
  • Provide more sophisticated reporting and analysis, faster turnaround, improved accessibility and enhanced quality.
  • A single touchpoint where detailed financial transaction information can be filtered on user-entered selection criteria, viewed online, downloaded in standard file formats and used to generate real-time reports.

These examples of generic BI business requirements illustrate a key point: they are fine as far as they go, but the business executives and managers we deal with in major companies don’t find these kinds of requirements statements and value propositions compelling. In fact, it is just the opposite - they see no reason to get excited about BI absent a more compelling business case and more concrete BI requirements that relate to the things they do, like conduct marketing campaigns, manufacture and ship products, buy raw materials and provide services to customers. As a result, they underfund BI, which limits its business impact and thereby justifies their skepticism.
Why BI Functional Requirements (Specifications) are Not Enough

In the early days of the computer industry, it was critical to generate a functional requirements document because much of what computers did had to be custom-programmed. If you wanted the monitor to display a table full of business data, you had to capture that as a functional requirement - often expressed as a statement like “the system shall be capable of accepting data inputs and displaying the data in user-defined tabular formats.” In the modern BI world, we run across functional requirements such as:

  • The system shall provide the ability to drill down, drill across, and slice and dice.
  • The system shall provide the ability to specify organizational hierarchies and display performance scorecards for each organizational unit.
  • The system shall enable role-based access to information.
  • The system shall provide capabilities to route alerts to business users according to user-defined parameters.
  • The system shall enable integration of data from multiple disparate sources.

Unlike the world of custom systems development, BI functional requirements like those listed are standard features of commercially available BI tools. While it is important to know what your company needs BI tools to do, BI functional requirements typically say little about the kinds of business information, analytic techniques and decision support that are required or the specific core business processes that the company seeks to improve via BI. And yet, when teaching BI requirements courses at conferences, I am confronted on a regular basis by companies whose BI requirements approach is centered around capturing BI functional requirements like those illustrated previously. While these are necessary to a degree, they are far from sufficient for creating BI applications that satisfy business users’ needs.
Data Element Listings

A third common approach is using the data element listing as a proxy for BI business requirements. The predominant logic here is that the company is not sure about how it wants to use BI, so it seeks to prepare for any eventuality by creating a list of all the data elements it might need for all the major subjects of the business that it might need to know something about. A typical data element listing might include:

  • Customer first name,
  • Customer last name,
  • Customer account number
  • Customer street address,
  • Customer city,
  • Customer state,
  • Customer ZIP code and
  • Customer phone number.

Such data element listings can be helpful, and it is important to understand what business information is needed as a core expression of BI business requirements, but the listing alone says nothing about how the information will be used or how it might need to be integrated with information about products, manufacturing locations, store locations, organizational units and other organizational information. Further, BI capabilities built on top of large stores of unintegrated subject data elements run the risk of spawning inconsistent BI depending on how development teams and/or power users choose to integrate data for their specific purposes. In other words, simple data element listings don’t provide enough specificity to guide development of the BI databases and applications that deliver BI or to guide the business process changes that deliver the bang for the buck to the business.
Business-Driven BI Requirements

So far, I have illustrated common approaches to BI business requirements and discussed how they are somewhat useful but certainly not sufficient. In contrast, a well-structured set of BI business requirements:

  • Establishes a clear linkage between business strategies, the core business processes via which the strategies are executed and BI-driven business improvement opportunities (BIOs), which are the basis for a BI business case that is compelling to the business stakeholders;
  • Identifies and clearly describes what business information, analytic tools and techniques, and decision support is required by the business to realize BI-driven improvement opportunities regarding management processes, customer processes and/or operational processes;
  • Provides the essential input to the process of defining specific BI projects and prioritizing those projects based on key criteria such as business impact and time to market;
  • Provides the means of aligning BI, business process improvement and balanced scorecard initiatives;
  • Drives key data architecture decisions;
  • Provides the basis for end-to-end traceability between BI requirements approved by business users and the delivered data stores and BI applications; and
  • Provides a key baseline against which the performance of the BI initiative can be measured.

Many companies have seen the shortcomings of traditional requirements approaches for BI purposes, and they can easily relate to the characteristics of business-driven BI requirements listed previously. Therefore, if creating a well-structured set of BI business requirements is the goal, the next challenge is how to get it right. While much more is involved than can be addressed in a short article, I can provide a high-level overview to get you started. The first step is BI opportunity analysis, as shown in Figure 1.


The goal of BI opportunity analysis is to identify - in business terms for business executives, managers and analysts - the main ways that BI can be used to improve business results. The outcome of the analysis is documented in a qualitative BI business case that describes potential BI-driven improvement opportunities in three broad areas: management processes, customer processes and operating processes. The BI opportunity analysis and the resulting business case are key inputs to the next step, as shown in Figure 2.

The business-driven process of defining the BI portfolio explicitly links BI and one or more targeted business processes. In the center of Figure 2, we see that when we talk about defining BI-driven BIOs, we get very specific about the BI and how it will be used to improve business results. This approach overcomes the weaknesses of traditional approaches to BI requirements and establishes the basis for the last step in the process of developing a well-structured set of BI requirements, shown in Figure 3.

The last step in getting BI business requirements right is becoming more specific about the requirements for business information, analytic tools and applications, and decision support - all in relation to previously defined BI-driven business improvement opportunities. For example, a management process such as performance management may have a requirement for specific business information in the form of metrics and key performance indicators, perhaps in a scorecard format. A customer process such as cross-selling may have a requirement for an analytic application that uses a data mining technique like collaborative filtering to identify product recommendations for customers at a company Web commerce site. An operational process such as manufacturing may have a requirement for decision support in the form of alerts to executives when the cycle time for three consecutive orders to a major customer is outside of established targets. Armed with a specific understanding of the BI requirements for each BIO, we are then in a position to develop a comprehensive BI requirements document that can drive development of the BI databases, BI applications and enhanced business processes that create business value.

Short of a major faux pas with a key customer, committing a social gaffe in the executive suite or consistently missing performance targets, nothing will derail a promising business or IT career like being associated with a high-profile initiative that fails. And BI is increasingly high profile because of the costs of doing it right and the strategic and financial consequences of doing it wrong. Most professionals I work with want to be part of successful initiatives because such initiatives help the company, provide a sense of professional accomplishment and satisfaction and help careers.

In the BI world, the odds of success go way up if we get BI business requirements right. While there are a host of other issues that go into BI success, they don’t matter much if we build the wrong things or the things we build aren’t used. A well-structured set of business-driven BI requirements helps avoid those scenarios and sets the stage for delivering successful BI projects.

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