A data requirements gathering template (with examples)

A blank document is the enemy of good scoping. This template gives you a fixed set of questions to answer before every analysis, dashboard, or data project, with filled-in examples so you know what "good" looks like.

This is the companion to our framework on how to gather requirements as a data analyst. The framework explains the thinking. This article gives you the document to fill in.

Why use a template at all

Most analysts skip the document and go straight to querying. Then halfway through they realize the stakeholder meant something different by "active user", or that the date range was wrong, or that a key source has been broken for weeks. Rework is the single most expensive habit in data work, and almost all of it traces back to a scope that was never written down.

A template fixes three things at once. It forces you to ask the questions you would otherwise skip. It creates a written record you can point back to when scope quietly changes. And it gives the stakeholder something concrete to react to, which surfaces misunderstandings while they are still cheap to fix.

The data requirements template

Copy this into a doc or ticket and fill it in during your first conversation. Each section maps to one thing that derails projects when it is left vague.

The order to fill it in

Do not fill the template top to bottom. Fill it in the order that protects you from building the wrong thing. The sequence matters more than the form.

1. 1

   Start with the decision, not the request

   The stakeholder will hand you a solution ("a churn dashboard"). Write down the decision behind it first. If nobody can name a decision, the project has no real requirement yet.

   Questions to ask

   • What decision will this analysis support?
   • What happens differently depending on the answer?
   • Who acts on it, and by when?
2. 2

   Lock scope and granularity in writing

   Ambiguous scope is the number one cause of rework. Pin the boundaries down before you touch the data, including what you are deliberately leaving out of this iteration.

   Questions to ask

   • What date range, and why that one?
   • Daily, weekly, or monthly?
   • Which segments are in, and what is explicitly out?
3. 3

   Define every metric in plain words

   This is where days disappear. Write each metric definition as a sentence, not a name, and check it against what already exists so you do not ship a third version of "revenue".

   Questions to ask

   • What exactly counts as a sale, a user, an active account?
   • How are refunds, cancellations, and test accounts handled?
   • Does this match the definition already in the BI tool?
4. 4

   Map sources and owners

   Never assume you know where the numbers come from. Note the owner for each source so you have someone to ask when something looks wrong.

   Questions to ask

   • Which systems hold this data?
   • Who owns each one?
   • How fresh is it, and are there known issues?
5. 5

   Capture the business knowledge

   Context that lives in people's heads, not the database, is what separates a correct chart from a misleading one. Ask for it before you draw conclusions.

   Questions to ask

   • Any campaigns, migrations, or org changes that moved the numbers?
   • Any known gaps or quality issues?
   • Anything unusual about this segment versus others?
6. 6

   Confirm and date it

   Send the filled template back, get an explicit yes, and record the date. Now you can build.

   Questions to ask

   • Does this match what you had in mind?
   • Anything missing or misunderstood?
   • Are you comfortable with this scope?

A filled-in example

Here is the same template completed for a realistic request, so you can see the level of detail to aim for. The stakeholder asked for "a dashboard to track marketing performance". That is a request. Below is the requirement.

Notice what changed. A vague visual request became a decision (which channels to scale), a precise scope (three paid channels, monthly, 12 months), defined metrics (CAC and ROAS, with organic and test excluded), an owner, and a deadline tied to a real business moment. That is a requirement you can build against without guessing.

Adapt it, do not worship it

This template is a starting point, not a compliance form. A one-hour ad-hoc analysis needs three lines, not six sections. A new company-wide metric needs all of it plus a review with the data owners. The skill is knowing how much rigor the project deserves, and that judgment comes from reps.

If you want to build that judgment on real briefs instead of clean toy datasets, that is exactly what the data analyst path on D8A is built around. And if you are still deciding which data role fits you, start with DA, DS, DE, BA: what's the actual difference.