The BI Reporting Requirements Template (7 Fields)
Seven fields for specifying a recurring report: what arrives, when, to whom, and what happens when it fails. Not the same document as a dashboard spec.
Gabriel ThieryAsk a stakeholder what they'll do differently after seeing a dashboard and sometimes they can't answer. That isn't a failed conversation. It usually means they wanted a report, and a report is a perfectly reasonable thing to want.
The mistake is specifying it with a dashboard's requirements doc. A dashboard has to justify a decision. A report has to justify a delivery, and almost none of the fields carry over.
What business intelligence reporting requirements are
Business intelligence reporting requirements define a recurring deliverable: what file or message arrives, in what format, on what schedule, to whom, containing which numbers over which period. They're the spec for something that shows up on its own, repeatedly, whether or not anyone asked for it that morning.
That last part is the whole difference. A dashboard sits there waiting to be opened. A report arrives, and it keeps arriving after the person who requested it changes roles.
Reporting requirements vs dashboard requirements
One field appears in both. Everything else diverges.
Only metrics and definitions is shared, and even that one behaves differently, which is covered below.
The dashboard doc asks what decision this supports, who opens it, how they slice it. The reporting doc asks what arrives, when, to whom, and what happens the morning it doesn't. Filters and drill-through are meaningless in a PDF. Cadence and timezone are meaningless on a screen someone opens on demand.
So if you've been handed the dashboard template and asked to spec a monthly export with it, that's why it feels like the wrong shape. It is the wrong shape.
⬇ Download the reporting requirements template (Markdown) — seven fields, no email required.
The seven fields
1. Deliverable
What physically arrives: format, filename pattern, page or tab count, whether it needs branding.
Formats are not interchangeable, and choosing one is a decision about behaviour rather than aesthetics. XLSX means somebody is going to pivot it, so the row grain matters more than the formatting. PDF means nobody will pivot it, so the formatting matters more than the grain. An email body means it gets read on a phone in about four seconds, so the first line has to carry the whole thing.
2. Recipients
Who gets it, who's CC'd, whether distribution is a hand-maintained list or a directory group, and who administers that group.
The field worth insisting on is accountable for correctness, and it needs a person's name rather than a team's. Reports drift. Definitions shift underneath them, source systems get migrated, a column gets renamed. Whether anyone notices depends entirely on whether noticing is somebody's actual job.
3. Cadence and trigger
Frequency, exact time, timezone, what triggers it, and what upstream job has to finish first.
Write the timezone down explicitly. A "Monday 7am" report specified by someone in Toronto and built by someone in Lisbon arrives on Sunday evening for half its audience, and that gets discovered in production.
The dependency row is the one that causes incidents. If the report can fire before the warehouse load completes, eventually it will, and it will send confidently wrong numbers to a distribution list. Scheduling a report thirty minutes after a load that usually takes twenty is not a dependency, it's a bet.
4. Period and grain
The window covered, what one row represents, the comparison period, calendar or fiscal, and how late-arriving data is handled.
That last one is subtler than it looks. If Tuesday's figures change on Wednesday, you have two options and no third: restate the period so the report corrects itself and contradicts every copy already sent, or freeze it so past reports stay internally consistent and slightly wrong. Both are defensible. Choosing by accident is not.
5. Metrics and definitions
Name, exact calculation, source, rounding, units. Same as a dashboard spec so far.
Here's where it stops being the same. A dashboard can be corrected in place, and once you fix the measure everyone sees the fixed version. A report can't be recalled. Every copy already sent keeps the old arithmetic, sitting in an inbox, being quoted in a meeting six weeks from now.
Which means a definition change to a recurring report isn't a fix, it's a new version of the document. The template has a version row and a line for whose sign-off a change requires. Fill both in, because the alternative is two people citing the same report name and disagreeing about the number.
6. Delivery and failure
Channel, permissions once it lands, whether it carries restricted data, retention, and what happens when the run fails.
On failure is the field most specs skip, and skipping it doesn't avoid the decision, it just moves it to 6am under pressure. Retry, alert, send nothing, or send late are four different answers with four different consequences. Send-nothing and send-late in particular are opposite choices: one risks nobody noticing, the other risks somebody acting on stale figures.
The default when nobody decides is silent failure, which is the worst of the four. A report that quietly stops arriving gets noticed months later, if at all.
7. Review date
A date, a named reviewer, and a line on what would have to be true for the report to stop.
Reports accumulate in a way dashboards don't, because nothing about a working report prompts anyone to ask whether it's still read. A date in this field makes stopping a scheduled event rather than an awkward conversation somebody has to initiate.
The three that actually cause incidents
If you fill in three fields and skip the rest, fill in these:
- Accountable for correctness. A name, so that noticing drift is someone's job.
- Depends on. The upstream job, so the report can't fire early with incomplete data.
- On failure. So the 6am decision is already made.
Everything else on the list is about the report being useful. These three are about it not being actively harmful.
Running the conversation
Same shape as gathering dashboard requirements, and the same rule applies: do it live. Email threads produce incomplete, contradictory requirements. Twenty minutes on a call beats a two-week thread, mostly because the awkward questions get asked out loud instead of politely dropped.
The awkward ones here are worth planning for:
- "Who reads this?" Sometimes the honest answer is that nobody's sure.
- "What happens if it's late?" Often nothing, which is useful to know before you build alerting.
- "When would we stop sending it?" This one produces silence, and the silence is the answer.
Fill the template in with them on the call rather than sending it over for completion. A requirements doc returned by email arrives with the easy fields filled and the load-bearing ones blank.
Common questions
Is a reporting requirements template the same as a BI requirements document? A BI requirements document usually covers a whole initiative: sources, model, security, deliverables. This is narrower. It specs one recurring deliverable, and you'd expect several of them attached to a single BI requirements document.
Do I need this if I'm just using Power BI subscriptions? The mechanism doesn't change what needs specifying. A Power BI subscription still has a cadence, a timezone, a recipient list, an upstream refresh it depends on, and a failure mode. The tool makes delivery easy and makes none of those decisions for you.
What if the stakeholder wants both a dashboard and a report? Common, and fine. They're two deliverables with two specs. The usual pattern is a dashboard for the people making the decision and a report for the people who need the record, and conflating them produces a dashboard with a print button that satisfies neither.
Can I just add these fields to the dashboard template? You could, and you'd have a document where two thirds of the fields are always blank. Separate specs stay shorter, and short specs get filled in.
Take the seven-field template into the next request, and start with the three that cause incidents. If it turns out the thing being asked for is a screen rather than a delivery, the dashboard requirements template is the other document.
Gabriel Thiery
Builder of datawirefra.me. I help BI teams plan dashboards people actually use — before they write a single DAX formula.
Connect on LinkedIn