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
Data Lake vs Data Warehouse: Avoiding the Data Swamp
Scott HietpasScott Hietpas  |  
Jul 16, 2019
In this blog series, Scott Hietpas, a principal consultant with Skyline Technologies’ data team, and Matt Pluster, the Data Analytics and Data Platform director, respond to some common questions on data warehouses and data lakes. Previous installments covered pros and cons of each solution,...
Blog Article
Roles and Responsibility Activity (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Jul 11, 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 third blog in the Trifecta of Greatness series. For more background on the strategies and tactics our Solutions Consulting Director learned...
Blog Article
10 Communication Tips for Business Analysis and Project Success
Brian LaehnBrian Laehn  |  
Jul 09, 2019
I am often asked what is the most essential skill that a Business Analyst (BA) should possess. 100% of the time my answer is that a BA must demonstrate the ability to communicate effectively with their project team and all project stakeholders.   Communication, when performing...
Blog Article
Data Lake vs Data Warehouse: What’s the Best Configuration?
Scott HietpasScott Hietpas  |  
Jul 02, 2019
In this blog series, Scott Hietpas, a principal consultant with Skyline Technologies’ data team, responds to some common questions on data warehouses and data lakes. For a full overview on this topic, check out the original Data Lake vs Data Warehouse webinar.   In my previous blog...
Blog Article
Seeds of Vulnerability (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Jun 20, 2019
My last blog (Introduction to Team Delta) talked about a project team I was on called Delta that was very successful. In this blog, and the ones following, I'm going to talk about the characteristics and the foundation that we found was key to our success, as well as what was different from...