The Kimball Group has frequently written about the importance of focusing on business requirements as the foundation for a successful DW/BI implementation. Design Tip #110 provides a crisp set of dos and don’ts for gathering requirements. However, some organizations find it difficult to land on the right level of detail when documenting the requirements, and then leveraging them to define the scope of a DW/BI development iteration.
Many organizations have formalized rules of engagements for major IT development efforts including a set of structured deliverables used in the development process. This often includes a document such as a functional specification for capturing business requirements. Unfortunately, these documents were originally intended to support operational system development efforts and are typically ineffective for capturing the requirements to build a BI system. It’s often difficult to translate DW/BI business requirements into the type of scenarios and detail called for in these templates. In addition, DW/BI requirements are often fuzzy rather than specific; they may be captured in statements such as “measure sales volume every which way” or “slice and dice claims at any level of detail.”
Sometimes DW/BI requirements are captured as a set of representative analytic questions or a set of predetermined reports with caveats surrounding required flexibility to support ad hoc reporting capabilities. Such requirements make it hard for the business representatives and DW/BI project team to agree on the exact requirements that are in scope or out of scope.
To confront this challenge, organizations should develop the data warehouse bus matrix (see Design Tip #41) and logical dimensional model as deliverables before looping back to finalize the business requirements and scope sign-off. The bus matrix clearly identifies the business processes and associated dimensions that represent the high level data architecture required to support the business requirements. The bus matrix alone can help define scope. The logical dimensional model then describes the details of the DW/BI data architecture: dimension tables, columns, attributes, descriptions, and the beginnings of the source to target maps for a single business process. Including the logical model allows the business representatives to concur that their requirements can be met by the proposed data model. Likewise, it is important that the DW/BI project team commit to the business users that they understand the required data, have performed the necessary technical evaluation including data profiling, and agree that they can populate the logical dimensional model with the anticipated data. Gaining this agreement will enable both the business community and DW/BI project team to reach a common understanding of the business requirements and scope as documented by the logical data model. Once the model has been agreed to, then any business requirement that can’t be resolved by the data represented by the logical data model is clearly out of scope. Likewise, any business requirements that can be resolved by the logical data model are in scope.
The logical dimensional model should be developed jointly by representatives from all interested groups: business users, reporting teams, and the DW/BI project team. It is critical that the appropriate individuals are represented on the dimensional data model design team as described in Design Tip #103 for this strategy to be effective. Be sure to incorporate thorough reviews of the proposed data models with a wide set of business users and DW/BI project team members to assure that all the business and technical requirements and challenges have been identified (see Design Tip #108).
