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 have no answer. That silence is useful. They wanted a report, and a report is a reasonable thing to want.
The mistake comes one step later, when somebody specs the report with a dashboard's requirements doc. A dashboard justifies a decision. A report justifies 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 schedule, whether or not anyone asked for it that morning.
That last part carries 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 appears in both columns, and it behaves differently on the report side.
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.
If somebody handed you the dashboard template and asked you to spec a monthly export with it, the shape felt wrong before you could name why. It was the wrong shape.
⬇ Download the business intelligence reporting requirements template (Markdown). Seven fields, no email wall.
I don't gate it, and I think gating one is a mistake at both ends. A template behind a form is invisible to Google, which is why the competitors hiding theirs don't rank for the people searching for one. It's also a poor trade for the reader, who came for a table and left with a nurture sequence.
The seven fields
1. Deliverable
What physically arrives: format, filename pattern, page or tab count, whether it needs branding.
Formats are not interchangeable, and picking 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 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 on whether noticing is somebody's job.
3. Cadence and trigger
Frequency, exact time, timezone, what triggers it, and what upstream job has to finish first.
Write the timezone down. A "Monday 7am" report specified in Toronto and scheduled in Lisbon lands at 2am for the people who asked for it, 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 a bet on the word usually.
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 next send carries the corrected number and contradicts every copy already out there. Or freeze it, so past reports stay consistent with each other 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.
Correction is where the two part company. You fix a dashboard measure in place, and from then on everyone sees the fixed version. You cannot recall a report. Every copy already sent keeps the old arithmetic, sitting in an inbox, being quoted in a meeting six weeks from now.
A definition change to a recurring report therefore produces a new version of the document rather than a corrected one. The template has a version row and a line for whose sign-off a change requires. Fill both in, or two people end up 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. Skipping it moves the decision to 6am, where somebody makes it under pressure with a distribution list waiting. Retry, alert, send nothing, or send late are four answers with four different consequences. Send-nothing and send-late are opposites: one risks nobody noticing, the other risks somebody acting on stale figures.
When nobody picks, the report fails silently, which is the worst of the four. A report that stops arriving without announcing itself 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 a working report gives nobody a reason 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 start.
The three fields that 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 makes the report useful. These three keep it from doing harm.
Running the conversation
Same shape as gathering dashboard requirements, and the same rule holds: do it live. I think requirements gathered over email are worthless. A thread produces contradictory, half-specified answers that twenty minutes on a call would have settled, and the awkward questions get dropped instead of asked out loud.
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 the thing being asked for is a screen rather than a delivery, the dashboard requirements template is the other document.
Sketch the report layout before you build it → (opens in a new tab)
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