The primary goal of a Business Intelligence (BI) application is to answer key business

questions for end-users while the answers are still relevant to the business. Business Analysts (BA) can reduce the risk of misinterpretation of BI requirements by capturing these business questions, metrics, and dimensions in the requirements phase of a BI project.

The BI Requirements Challenge

A large company with more than 30,000 employees attempted to implement a BI application as a means of shielding end-users from the complexity of its centralized data warehouse. Following the project kick-off, a requirements gathering session was conducted at which the primary business users provided the reporting and analytic needs. Although the requirements appeared to be clear at the time of sign-off, the users' interpretation of the solution was very different from the application that was built.

The project was plagued with challenges including data quality and lack of active business participation, and there were fundamental problems with the requirements which led to further issues. The following summarizes the top two challenges uncovered.

• The user requirements did not align with sponsor's vision. The sponsor's expectations and high-level business questions were not captured with sufficient detail. As a result, only a high-level project description was passed to the project team. This allowed the business users to shape the project into a solution so specific to them, that the ability to deliver on the sponsor's overall vision was lost.
• The documented requirements were ambiguous. Although the requirements were understood in the requirements session, the language used in the Business Requirements Document (BRD) was sufficiently vague to allow for misinterpretation by the developers. This led to re-work as the problems associated with the BRD did not surface until a significant amount of object development and data modeling was completed. To assist with the development of requirements documentation, use the Info-Tech Advisor, "Business Requirements Template."

Supplementing BI Requirements with Business Questions

Whether through a report, alert or dashboard, BI applications provide answers to key business questions to the users. Capturing these questions at the time of gathering requirements can reduce the risk of a developer misunderstanding the requirements and provide an aid for building the test cases later in the project.

Considering that users do not always understand how to go about providing business questions, it is important for a BA to assist by prompting the users for the key metrics and dimensions. If high-level business questions were provided from the initiation phase of the project then use those to guide the discussion when identifying the metrics and dimensions. For more information about the project initiation phase, refer to the Info-Tech Advisor research note, "Optimize the BI Project Initiation Step."

The following is an example of the MDG. Include the completed grid as an attachment in the business requirements document.

Key Takeaways

1. Use high-level requirements from the project sponsor to guide the requirements phase. The high-level requirements and benefit distribution captured in the initiation phase of the project provides an excellent guide for building an MDG. Using this will ensure alignment between the project requirements and sponsor's expectations thereby increasing the overall chance of success for the BI project.
2. Identify the key metrics. As part of the requirements gathering session, identify the metrics that are required for tracking and decision making. These are usually calculated values such as Key Performance Indicators (KPIs), percentages or record counts and can range from very simple to very complex. It is also useful to note the user definition for each metric and include them in the BRD.
3. Identify the dimensions. List all the different ways by which the metrics will be viewed. Dimensions are the components used for drilling or slicing the metrics into specific views and can include any entity of business significance. Common examples are Customer, Product, Region, Salesperson, etc.
4. Use the metrics and dimensions to capture the business questions for the BI application. The metrics and dimensions represent the most important components of any BI application. Together they provide the content that will drive the decision making process. The metrics in particular can be used to determine the complexity of the application. The more complex the metrics, the more complex the application. In addition, identifying the business questions will provide a means for the developer to understand the context of the requirements as well as give the users an easy way to tell if the requirements are accurate.

Bottom Line

Traditional business requirement documentation can allow for ambiguity when capturing requirements for BI applications. Business Analysts can supplement the requirements document with an MDG and reduce the risk of misinterpretation by developers and users.