June 27, 2019

How to Use Report Tables to Model and Analyze BI Requirements

If you’re involved in eliciting, modeling, analyzing, or consuming requirements for Business Intelligence (BI) projects, then 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/.

Subscribe to our Newsletter

Stay informed on the latest technology news and trends

Relevant Insights

Should You Disrupt Yourself to Accelerate Digital Transformation?

It has been interesting to watch Microsoft transition from a company that makes its money via licensing to one that...

Cybersecurity Myth Busted: Tools Are the Solution

When thinking about security, people often gravitate towards implementing various security tools, solutions, or products. If you bring up a...

Time to Reconsider MP-BGP EVPN for Your Datacenter Network?

VxLAN was defined in 2014 by RFC 7348 and has been used as a component in several SDN (software defined...
X