June 27, 2019

How to Use Report Tables to Model and Analyze BI Requirements

Post by: Rachael Wilterdink

If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you.

What is a Report Table?

Having worked on Business Intelligence projects for several years as a consultant, I wish I’d known about this technique before. I ended up coming up with my own version of this, but I’m glad to see this is a model that has been formalized in the Project Management Institute’s (PMI) Business Analysis Practice Guide.

This is the one technique in this blog series that is not an official technique of the International Institute of Business Analysis (IIBA®), but it is acknowledged by PMI®, which says, “A report table is a model that captures the detailed level requirements for a single report.” – Business Analysis Practitioners Practice Guide (PMI®)

This technique includes three different components, all of which are necessary to produce a single report:

  1. Report prototype
  2. Report table – top level
  3. Report table – field level

What is Included in Each Report Table Component?

Report Prototype

This is a mock-up of what the finished report would look like. It includes all of the elements that will be visible on the report, but may be low-fidelity (not pretty and polished). Prototypes include desired placement of the items either on the screen or on a printed version of the report.

Here is a sample from the BA Practice Guide:

Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®
Typical components of a report might include:

  • Report Title
  • Report Subtitle
  • Reporting period or Report Run Date/Time
  • Column Headings
  • Row Headings
  • Report totals
  • Report subtotals
  • Report Groupings
  • Etc.

Report Table – Top-level

The top-level Report Table will include the high-level information about the report, including answers to typical “who, what, why, where, when” type questions, such as:

  • Who should be able to view the report?
  • What information will be included?
  • How often should it be delivered?
  • What will trigger the report to be sent?
  • Why is it needed?
  • How will the report be accessed?
  • Etc.

Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®

Report Table – Field Level

The field-level Report Table defines:

  • Data manipulation options (if the report is viewed on a computer), such as:
    • Filtering
    • Sorting
    • Ordering
  • Parameters (such as a date range, min/max, etc.)
  • Which fields should be visible on the report
  • Which fields should be calculated, and how they will be calculated
  • Formatting rules (such as rounding, number of decimals, dates, etc.)

Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®

By combining these three components, it provides all the requirements needed to build a report. NOTE: there may be a set of required items or designs (such as Brand Guidelines) at an organizational level that may need to be adhered to.

Pros

As I mentioned, I wish that I had known about this technique years ago. It would have saved me many headaches when approaching how to identify the requirements for Business Intelligence reports.

This approach allows you to separate the components into logical layers and specify them independent from one another. From my experience, it can take a LONG time to identify the source data for a report and get it into a location where you can use it. Therefore, it’s advantageous to figure out what data you need before you start designing a report.

If you’re using an agile approach, you might start with the barebones version of the report, and then progressively elaborate on it as you discover more from your end users.

Cons

With this approach, there is a tendency to think you have to know everything to start. If you know the key business question that the report intends to answer, you can start from there.

Since three separate pieces are required to create a single report, it can be constraining. Again, if you’re taking an agile approach, it would be preferable to take a thin vertical slice through all the layers so your requirements would include all of the minimal elements needed to deliver something of value. In this case, the heaviest lifting would probably be done during the first iteration, and subsequent iterations would add on to the first version.

Conclusion

Regardless of your development approach, this technique can be used to create robust reports that consider all possible aspects of the report. It enables you to collaborate with your stakeholders and ask them the right questions to develop the right report.

References:
“IIBA Home.” IIBA | International Institute of Business Analysiswww.iiba.org/.
“PMI.” PMI | Project Management Institutewww.pmi.org/.

Relevant Insights

Are You Falling into the Cloud Conversation Gap?

Most conversations about migrating services to the cloud focus on migration of application workloads and data. The vision is often...

How Aggregation Tables Improve Performance for Power BI Reports

In this blog, Marcus Radue, Solution Architect, offers high-level guidance in the advantages of aggregation tables in Power BI. For a...

Getting Started with Azure DevOps – Views

Like most Microsoft products, there are many ways to look at or perform the same activities. Azure DevOps is no...
X