Back to List

How to Use Report Tables to Model and Analyze BI Requirements

Rachael Wilterdink Rachael Wilterdink  |  
Jun 27, 2019
 
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. Over the next several months, we will be releasing 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements on our blog. Today we will examine the seventh technique: Report Tables (an Interface Model).
 

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:
report prototype
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.
 
top-level report table
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.)
 
field-level report table
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.
 
Next up: Metrics and Key Performance Indicators (KPIs).
 

Free Agile Resources


References:
“IIBA Home.” IIBA | International Institute of Business Analysis, www.iiba.org/.
“PMI.” PMI | Project Management Institute, www.pmi.org/.
 
Business AnalysisBusiness Intelligence

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Pre-Project Components That Can Impact User Adoption
Cory SchmittCory Schmitt  |  
Sep 12, 2019
Does the following situation sound familiar?   You were on a project that rolled out a new application to the organization. You and the team spent many long days (and some nights) building the new application. The team worked hard, and you came in on-time and on-budget. As part of the...
Blog Article
Using Human Hard-Wiring to Create a Strong Agile Experience
Rachel RieckRachel Rieck  |  
Aug 22, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this Trifecta of Greatness blog series is right for you. For more background on the strategies and tactics our Solutions Consulting Director learned from a pivotal agile journey, be sure...
Blog Article
How to Use Prototyping to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Aug 15, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for Business Intelligence projects, this post is for you. This is the tenth and final technique in our blog series on 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI...
Blog Article
Decision Rights, Team Lead Communication, and Smackdowns (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Aug 08, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this blog series is right for you. This is the fifth blog in the Trifecta of Greatness series and highlights a few last habits and techniques. For more background on the strategies and...
Blog Article
How to Use Process Modeling to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Aug 01, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. This is the ninth technique in our blog series on 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements.   What is...