How to gather requirements as a data analyst

Requirement gathering is the first step of every data project, and the step most analysts quietly struggle with. The good news: it's a learnable skill, not a talent. Here's a repeatable framework.

Why requirement gathering is so hard in data

A question that comes up constantly in the D8A community: "How do you gather requirements for an analysis or dashboard? Do you have a framework?" And it's not just juniors asking. Data analysts with three or four years of experience realize at some point that they've been guessing at the problem instead of truly scoping it.

The difficulty is structural. Stakeholders often don't know what they want. They know they have a problem, they suspect data might help, and they're hoping you figure out the rest. Meanwhile, you're trying to translate a vague business concern into a concrete analysis scope without making the wrong assumptions.

The four things you always need to scope

Before any analysis, dashboard, or data project, you need clarity on four dimensions. Miss one and you will either build the wrong thing or hit a wall halfway through.

A practical framework for scoping any data project

This is the sequence experienced analysts follow even if they don't always name it. Making it explicit is what turns it from a talent into a repeatable process.

1. 1

   Understand the business problem, not the data request

   Most stakeholders come to you with a proposed solution ("a dashboard of sales by region"), not the problem. Your first job is to get behind it.

   Questions to ask

   • What decision will you make with this information?
   • What's happening right now that's making this urgent?
   • What would a good outcome look like?
   • Who else is going to use this, and how?
2. 2

   Map the data sources and owners

   Never assume you know where the data comes from. Sources change, systems get deprecated, and new tools get added without announcement.

   Questions to ask

   • Which systems or tools contain the relevant data?
   • Who is the data owner for each source?
   • How often is the data refreshed, and what's the lag?
   • Are there known reliability issues with this data?
3. 3

   Align on definitions before touching the data

   This is where most analysts lose days. You and the stakeholder use the same word ("revenue", "active user") meaning completely different things. Define metrics explicitly before you build.

   Questions to ask

   • What exactly counts as a sale or an active user?
   • How do you handle cancelled orders, refunds, test accounts?
   • Does this metric match what already exists in the BI tool?
4. 4

   Establish scope, date range, and granularity

   Ambiguous scope is the number one cause of rework. Lock these down in writing before you start.

   Questions to ask

   • What time period does this cover, and why?
   • Daily, weekly, or monthly detail?
   • Which markets, teams, products, or segments are in scope?
   • What's explicitly out of scope for this iteration?
5. 5

   Surface the company knowledge, not just the data

   Historical events, business decisions, and one-off anomalies change how numbers should be read. This knowledge lives in people's heads, not your database.

   Questions to ask

   • Any events that affected the data (campaigns, migrations, org changes)?
   • Any known data quality issues or gaps to flag?
   • Anything unusual about this market or team versus others?
6. 6

   Write it down and confirm

   Send a short written summary back before building. Not bureaucracy, protection: it catches misunderstandings early and creates a paper trail.

   Questions to ask

   • Does this match what you had in mind?
   • Anything I've missed or misunderstood?
   • Are you comfortable with these constraints and scope?

Company knowledge: the thing no database contains

Data analysis is not just a technical job. A huge part of what makes a senior analyst effective is their accumulated understanding of the business context: what happened, why numbers look the way they do, and what comparisons are actually fair to make.

A junior analyst looking at a sudden drop in orders in March might conclude there's a problem. A senior analyst who knows the company ran a massive promo in February, pulling demand forward, reads the same chart completely differently.

You can't learn this from a course. But you can systematically extract it from the people around you during requirement gathering, if you ask the right questions. Make it a habit to ask about exceptions, anomalies, and historical context before you draw any conclusions.

The most common requirement gathering mistakes

A scoping template to use before every project

Use this as a starting point for any analysis, dashboard, or data project. Fill it in during or right after your first stakeholder conversation, then send it back for confirmation before you build.

The key is understanding the business, not the data

Every tool, every framework, every question here is in service of one thing: understanding the business well enough to know what the data should show, and what it actually shows.

The analysts most effective at requirement gathering are not the ones who ask the most questions. They're the ones who have developed genuine curiosity about how the business works (its revenue model, its growth levers, its operational constraints) and who bring that understanding into every conversation.

That business knowledge is what turns a data request into a real insight. And it's something you build over time, project after project, by asking the right questions and paying attention to the answers.