Executive Summary: Part 1 of this guide addresses the fundamental challenge in business intelligence: gathering effective reporting requirements. The article argues that vague reporting requests often stem from BI teams acting as order-takers rather than strategic partners, leading to user dissatisfaction and mistrust in reports. Rather than blaming users for poor requirements, Analytics Business Analysts must adapt their approach by understanding that every reporting request signals deeper organizational needs. The key is to shift focus from merely collecting report specifications (layouts, filters, visualizations) to understanding how reports will create business value. The article introduces three types of requirements as well as an ROI framework based on three factors: number of report users, report value (degree of actionable insights), and frequency of use. Success requires BI managers to promote deeper engagement between Analytics Business Analysts and business stakeholders, transforming reporting requirements from a mechanical specification into an evolving strategic dialogue that truly supports business objectives.

Introduction – Part 1

In the complex landscape of modern business intelligence (BI), the greatest barriers to high value reporting and analytics are good reporting requirements. Reporting requirements are not merely technical specifications; they are roadmaps for increasing operational effectiveness, decision-making and business performance.

When users submit vague reporting requests—”Give me a table of data and a graph” —they are often revealing that they do not fully grasp the potential of business intelligence. Usually this is not the fault of report users but rather is symptomatic of BI teams filling the role of order-taker rather than strategic business partner.

This comprehensive guide will deconstruct the art and science of gathering reporting requirements, transforming what is often perceived as an administrative task into a critical strategic dialogue.

As you delve further into this guide, note that the terms “reports” and “reporting” encompass dashboards, alerts and notifications, paginated reports and other information provided by a business intelligence team.

Types of Requirements

Three distinct types of reporting requirements may be specified for any given report or dashboard. The first two – Value and Trust Requirements – are critical to the successful completion of any report. The last – Adoption Requirements – is ideal to have but may be impractical for smaller reporting investments.

Parts 2, 3 and 4 of this guide will dive into greater detail on types of requirements. In the meantime, each is summarized below.

Value Requirements

Value requirements describe how the report will create value for the business. The value may comprise expected benefits – financial, efficiency, profit, etc. – as well as the manner in which they support an existing business process. Done well, business requirements will quantify the expected ROI or describe in detail how the business process will improve.

Value requirements are critical because they help ensure the reporting can provide lasting value to the business.

Trust Requirements

Trust requirements detail how stakeholders will determine whether the report’s information is trustworthy. The method of verification must be precise and often will refer back to an existing report or dataset.

Trust requirements are critical because they help ensure the report is adopted.

Adoption Requirements

Adoption requirements deal with how the business will be held accountable for adoption of the report. These may articulate compliance and usage measures, training, change management, and enforcement accountability and monitoring.

Adoption requirements help ensure that ROI is achieved post-deployment from reporting investment.

Analytics Business Analyst: Defined

Analytics Business Analysts (ABAs or simply “analysts”) referred to in this guide are the individuals having business-oriented discussions with businesspeople to gather reporting requirements.

Let’s first consider what ABAs are not. ABAs do not need to be highly technical. They are not data analysts who will write SQL and integrate data from multiple sources. Nor are they report developers who will create semantic layers, wire up dashboards, and create sophisticated metric calculations.

Core Skills

The most important skills of an ABA are:

Interviewing Executives & Management. ABAs must be confident interviewing time-limited, highly influential people. This requires a certain amount of ‘presence‘ so they will be respected and listened to. They must also have a sense for the level of detail an interviewee can and is willing to provide.
Communicate with Technologists. The ABA is a bridge between the business need and report developers. She will need to pose technical IT questions to businesspeople in a way that yields a helpful response. Similarly, the IT team will look to the ABAs to clarify requirements, or even better, to anticipate the requirements needed by IT.
Familiarity with BI Tools. While ABAs will not build reports, they must be familiar with how end users can interact with tools so that the analyst can design wireframes and navigation. Most organizations use a primary BI tool, and the ABAs will need to be familiar with its features.
Report and Dashboard Design. Ultimately, the ABA will design reports. She needs to understand the concepts of corporate branding, navigation, filtering, visualizations, and aggregations well enough to wireframe what the report will look like.
Metrics, Formulas and Aggregation. Users need to trust the numbers they see, so getting metrics, formulas and aggregations right are paramount. To be clear, the ABA does not need to know how to code these into reports. However, she must understand the concepts, ask clarifications of end-users and then articulate as reporting requirements.
Business Process. The best ABAs are familiar with the departments and functions in their organization. The more experienced they are with the intricate business processes within those functions, the better. Most importantly, ABAs must be comfortable interviewing stakeholders to define how reports intersect with business processes.
Source Systems. ABAs have an awareness of source systems across the enterprise, and the nuances for how information is entered and maintained. Most businesspeople are only aware of source systems they interact with in their day-to-day jobs, however BI often requires collecting information across many systems.

Role In Testing

In addition to gathering requirements, ABAs will often participate in testing. Testing occurs after the report developers have finished their work and before the report is presented to business stakeholders.

Testing is the discipline – indeed, it requires exceptional self-discipline to do well – of verifying that the report meets all of the requirements gathered. This means comparing numbers from external trusted sources, such as trusted operational reports and ERP screens. It also involves testing navigation and filtering behavior in the report.

Beyond testing numbers, the ABA must also test whether the report delivers the expected business value in the manner prescribed in the requirements. She must understand the business context and needs well enough to anticipate how the report optimally will be used to make decisions.

In summary, the Analytics Business Analyst is non-technical person who is comfortable interacting with business stakeholders and can bridge communication with the report developers.

In practice, organizations may have a dedicated ABA or the role may be covered by a business-aware architect, report developer or data analysts. Either way, the requisite skills listed above still apply.

Source of Analyst Frustration

Business Intelligence analysts commonly are frustrated by the lack of guidance from those who request reports. The question frequently asked by analysts, “what do you want your report to look like?” either goes unanswered or is met with generalities. Pressing for clarification annoys business stakeholders. Left with scant details, the only option is to forge ahead and make it up as you go.

Missed Expectations

Why are we surprised when, once reports are delivered, we hear the users’ refrain “this isn’t what I asked for”? It often is not what they asked for, nor what was needed to support the business.

We then hear “we don’t trust the reports,” and BI teams take it personally. They have invested hours of analysis and testing to ensure underlying data – be it a data warehouse or other source – is accurate and complete.

It’s easy to assign blame to the report requesters. After all, they could have cooperated more with providing requirements. And we verified that the data is “accurate.” Users can seem downright ungracious at times! It is no wonder that there is often tension between BI teams and their users.

Uncomfortable Truth

However, there is an uncomfortable truth to be acknowledged here: businesspeople are doing nothing wrong and ABAs are the ones who need to improve. In this case, improving means acknowledging the inherent strengths and weaknesses of report requesters, and then adapting our approach as experts in the field of business intelligence.

By applying the techniques in this guide, your BI team will deliver reporting that delights users while contributing greater value to the organization. Let’s stop asking “what do you want in your report” and acknowledge that a new strategy is needed.

Struggle for Clarity

Every reporting request is a symptom of a deeper organizational need. A seemingly simple dashboard request might signal complex underlying dynamics: leadership uncertainty, performance management challenges, or strategic realignment. It may be surprising that, given the importance of having quality reporting, users find it difficult to convey what they want in a report.

Business User Expertise

Let’s look at it from the users’ perspective. Most users know their jobs extremely well. They have carved out a niche in the organization and are responsible for ensuring their business function is performed with excellence. They are experts at their department and its role in the company.

While those people are operational experts, reporting requires them to step back from discrete business processes and think analytically about the big picture. They need to anticipate where there is something noteworthy to learn from the data.

This means anticipating the best way to slice data, the best way to visualize trends, how data should be filtered and refined, and what paths are presented to answer more detailed questions. These are not inherently obvious features. Creating high value reporting relies on both analytical and technical skills which must be mastered over time.

Analytics Business Analyst Expertise

Unfortunately, those skills do not intersect with users’ operational expertise. The person who knows how to manage a shipping and receiving department is often not equipped to comprehensively analyze its performance. It is no wonder that users struggle to articulate what they want to see in a report.

They do their best to figure out what they need and then convey it to analysts. Lacking familiarity with tools and options for presenting information, users define table layouts and charts that they think will help.

ABAs must develop a new set of muscles to explore the business applicability of reports. They need to understand business context and how value from reporting is derived. These are skills that transcend mere dashboard design, instead focusing on genuine decision support.

Delivering Business Value

How do BI teams move from order-taker to value-creator? First, we must distinguish between reporting requirements and report specifications.

Specifications vs. Requirements

Report specifications address layout, navigation, filters, tables and visualization. This is the report definition that can be handed to developers to build. It is worth noting that many BI teams incorrectly consider report specifications to be the requirements.

For comparison, consider that you would like to improve the landscaping around your home. When you visit a landscape designer the last thing you want is to be asked, “how should your flower beds, trees and ornamentals be arranged?” or “what lighting do you want?” If you already knew the answers, you could save the design fee and just pay a greenhouse crew to install everything.

Rather, you would expect the landscape designer to ask insightful questions such as how will you use your patio space? Does your landscaping need to be low maintenance? Do you have pets or kids who will play in the yard? A good landscape designer tries to understand how the landscaping supports your lifestyle, home, desires and needs.

Once the landscape designer has that information, they can develop the landscaping specifications, i.e., requirements. They should tell you what variety of flowers to purchase and how they should be planted. They should tell you what kind of lighting to use, how it should be installed and aimed. They should recommend patio designs with a selection of pavers.

Analytics Business Analyst Focus

Similarly, ABAs must become experts in designing the report based on how it is expected to create value. The corollary is that ABAs must become experts at uncovering how reporting enhances a business function, process or decision. How will the report make someone’s job better, faster, more efficient? Once ABAs understand the business need, they can specify the reporting and analytics to fulfill that need.

Lastly, it is important to point out that there is a lifecycle to gathering report requirements. Just as the landscape designer presents their initial design to the homeowner, ABAs must do the same for their users. Users will almost always suggest improvements or have a revelation about the requirements that were not at first apparent. Several refining conversations may be needed.

In summary, reporting requirements are not a single specification of design, but an evolving conversation about the business need.

BI Managers On The Hook

Business intelligence managers must recognize that their role also will evolve. Rather than simply manage a mechanical software development lifecycle, they need to be present “in the field” among business executives, promoting a new way for the business to interact with the BI team.

Throwing requests over the transom may have achieved an “okay” result in the past, but a modest level of engagement with ABAs will dramatically improve the quality of reporting. Businesspeople must be prepared to give deeper context into how reports will be used and how value is derived.

ABAs can step up their game, but business stakeholders will need to respond in kind.

Return On Investment

One of the hardest questions to answer is, “what is the return on investment from business intelligence?” Business investments are wisely based on having a clear path from expenditure to profit. BI defies the quantification of ROI because the value is often speculative.

The Formula

Nevertheless, there are useful ways to think about reporting ROI that advise how we think about reporting requirements. The return on investment for a BI investment can be mathematically represented as:

ROI ~ (Report Users) × (Report Value) x (Frequency of Use)

In English, the ROI is proportional to the number of Report Users multiplied by the value delivered by the report, i.e., Report Value, multiplied by report Frequency of Use. On the surface we talk about reporting, however the investment, assessed comprehensively, includes data warehousing, infrastructure, QA, training, etc.

While the entire investment counts, the only way to achieve meaningful ROI by optimizing these three factors. Sacrificing any one factor will tank your ROI.

Report Users

Consider the ROI of a report designed to benefit the Sales VP versus a report designed to benefit each individual salesperson. If each report takes the same effort (investment) to build, the organization is likely to benefit more from the report that improves individual performance of each salesperson. This does not detract from the value to the Sales VP; it’s simply a matter of scale.

Where possible, the BI team should look for opportunities to impact more people at a deeper operational level in the organization. Controlling this can be difficult for BI teams viewed as a cost center / order-taker. However, a strong BI manager may be able to influence the organization to prioritize these types of reports.

Report Value

A report’s value is regarded as the degree that the report advises steps to improve business performance.

Let’s again consider a Sales VP report. Which would have a higher value, a report that shows the summary of sales by region versus a report that shows each sales region’s performance compared to the prior year with the lowest growth regions listed at the top? How about a report that shows the top customers versus a report that shows the customers whose changing order levels indicate they may have begun purchasing from other distributors?

Notice that the latter examples offer insights that beg for action. The Sales VP can focus on coaching reps in regions that are losing ground. She can have sales reps target discounts at specific customers to win back their business.

Report value is important to consider because it is highly dependent on understanding what challenges might exist in the business and how business stakeholders might be alerted.

Frequency of Use

A dashboard referenced once per month in an executive meeting can deliver benefit once per month. A weekly report advising sales reps on key client opportunities can deliver benefit each week. Which will likely deliver the greater ROI?

Just as driving a car requires input and response every few seconds, steering a business benefits from more frequent awareness and action. If an employee can make daily adjustments, then the ROI will be higher than if adjustments are made quarterly.

Reinforcing ROI

When developing report requirements, ABAs should continually ask themselves: who benefits from the report, how does it provide value, and how often will it be relied upon?

If any one of these is sacrificed, then ROI is diminished. Unfortunately, diminished ROI reflects negatively on the BI team even when business stakeholders bypass the requirements gathering phase, so it is up to the ABAs to be diligent.

In summary, in their ongoing quest for relevance BI teams should ask themselves, “how can I get more people to rely on this report to perform their jobs?”

Conclusion – Part 1

BI teams can position themselves as strategic partners by recognizing that reporting requests are more than mere technical specifications. The key is to focus on business needs – underlying business motivations, contexts, and value drivers – rather than final report design.

Delivering value demands a multi-faceted commitment:

Analytics Business Analysts must evolve from order takers to strategic business interviewers, developing skills that allow them to probe deeper into the organizational context behind each reporting request.
Business users must be prepared to engage more substantively, providing rich context about how reports will be applied and the specific decision-making challenges they aim to address.
BI managers must create a culture of collaborative requirement gathering, positioning their teams as engaged solution designers rather than passive order-takers.

By expanding user engagement and demonstrating tangible business value, BI teams can dramatically increase their return on investment and organizational impact.

In an increasingly data-driven world, the most successful organizations will be those that view reporting not as a technical function, but as a strategic capability focused on improving the performance of the business.

Part 2 of this article will explore in detail the steps Analytics Business Analysts should take to capture BI requirements.

Jeff Kanel is the Founder and President of Arch City Analytics. He has served as a corporate executive and analytics expert with over 15 years of management consulting leadership. Throughout his decades-long career Jeff has guided countless executive leaders to achieve a data-driven culture through analytics and AI.