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
20 Ways to Adapt Agile Best Practices to Remote Work
Rachael WilterdinkRachael Wilterdink  |  
Mar 24, 2020
The author of our Basic and Advanced Agile Transformation eBooks shares how you can adapt agile best practices to enable your workforce to be effective working remotely from home, the beach, or anywhere in the world (with reliable internet).   With COVID-19 disrupting nearly every aspect...
Blog Article
6 Real Truths About Project Leadership Learned from Trial & Error
Kari VondracekKari Vondracek  |  
Mar 17, 2020
About the author: Kari Vondracek (MBA, CSM, PMP, PSM I) is a project manager at Skyline Technologies. Since 1996 she has been leading projects in a variety of industries. When I was a young, know-it-all, 25-year-old, I was put into my first managerial position. I was a fresh college...
Blog Article
Agile User Story Splitting by User Roles
Rachael WilterdinkRachael Wilterdink  |  
Mar 10, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!   Different users of your...
Blog Article
Agile Story Splitting by Happy/Unhappy Paths & Operations (CRUD)
Rachael WilterdinkRachael Wilterdink  |  
Mar 03, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!   #3 - Happy / Unhappy Path or FlowGood...
Blog Article
Agile Story Splitting by Capabilities/User Goals & Workflow Steps
Rachael WilterdinkRachael Wilterdink  |  
Feb 18, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!   #1 - Capabilities/User Goals ...