Business Requirements Gathering

What is Business Requirements Gathering for BI Analysts?

Business Requirements Gathering (BRG) is how BI Analysts uncover what decisions stakeholders need to make, which metrics matter, and how data should flow to power dashboards and reports. Done well, it reduces rework, clarifies scope, and translates business intent into precise BI specs your engineers (or you) can build.

Why it matters in the BI Analyst role

• Transforms vague requests into measurable KPIs and actionable dashboards.
• Aligns business goals with data sources, refresh schedules, and permissions.
• Prevents scope creep by setting success criteria and change control.
• Accelerates delivery by producing clear, build-ready BI specifications.

Who this is for

• Early-career BI Analysts learning to capture stakeholder needs accurately.
• Data/analytics professionals moving from ad-hoc reporting to systematic BI delivery.
• Product or operations analysts who want to formalize dashboard requirements.

Prerequisites

• Basic SQL (SELECT, JOIN, GROUP BY).
• Understanding of KPI concepts (e.g., revenue, conversion rate, retention).
• Comfort running stakeholder interviews and documenting outcomes.

Learning path

1. Clarify outcomes and decisions
   Deliverable: Decision statements and KPI list with owner and definitions.
2. Map users, roles, and access
   Deliverable: Role matrix (who sees what).
3. Capture use cases
   Deliverable: Dashboard use-case cards (question → decision → action → metric).
4. Trace data-to-metric
   Deliverable: Source-to-metric mapping (tables, fields, joins, owner).
5. Set refresh & latency
   Deliverable: Agreed refresh schedule and SLAs.
6. Define success
   Deliverable: Acceptance criteria and test scenarios.
7. Control scope
   Deliverable: Versioned requirement set and change request log.
8. Write BI spec
   Deliverable: Build-ready BI specification (pages, visuals, filters, metrics, governance).

Worked examples

SELECT d.date, s.plan, s.country, COUNT(DISTINCT s.user_id) AS active_subscribers
FROM dim_date d
LEFT JOIN subs_status_daily s
  ON s.date = d.date AND s.status = 'active' AND s.is_paid = TRUE
WHERE d.date BETWEEN :start AND :end
GROUP BY 1,2,3;

Role            Can View                     Can Drill   Row-Level Filter
Executive       KPI Overview (company)       No          country = ALL
Regional Lead   KPI Overview, Region Detail  Yes         country IN own region
Analyst         All pages + data export      Yes         none (governed workspace)

Use case: Reduce churn in Premium plan
Decision: Which cohorts need proactive outreach this week?
Action: CS sends playbook emails to cohorts with churn risk > 12%.
Metrics: Churn Risk %, Cohort Size, Expected Saves
Filters: Plan, Region, Signup Month
Drill: Cohort -> Customer list (anonymized ID)

Metric: Conversion Rate (Signup -> First Purchase)
Tables: signup_events (s), purchase_events (p)
Join: p.user_id = s.user_id AND p.timestamp between s.timestamp and s.timestamp + 30d
Numerator: COUNT(DISTINCT p.user_id)
Denominator: COUNT(DISTINCT s.user_id)
Owner: Data Engineering (events), Product Analytics (definition)
Data Quality Rules: No duplicate user_id per event type per minute

BI Spec: Sales Pulse v1.2
Pages: Overview, Region, Rep
Tiles (Overview):
  - Total Bookings (Current MTD vs. PY) [KPI Card]
  - Pipeline by Stage [Bar]
  - Bookings Trend [Line]
  - Wins/Losses [Table]
Filters: Region, Segment, Quarter
Row-Level Security: Region filter enforced by user attribute
Refresh: Hourly 07:00–19:00, SLA 20m
Acceptance Criteria:
  - Bookings MTD matches Finance cube within ±0.5%.
  - RLS: A region user cannot see other regions in exports.
  - Load time < 4s p95 on Overview page.

Drills and exercises

• Write three KPI definitions including name, grain, formula, inclusions/exclusions, owner.
• Build a role matrix for two departments and specify row-level filters.
• Convert one stakeholder question into a use-case card (decision → action → metric).
• Map a metric to its source tables and joins.
• Propose a refresh plan with SLA and an alerting rule (UI badge or note).
• Draft five acceptance criteria that are testable and unambiguous.

Common mistakes and debugging tips

• Vague KPI names → Add grain, inclusions, and owner. Ask: "What exactly counts and when?"
• Missing decision intent → Capture "What will you do with this view?" to avoid vanity charts.
• Unowned data sources → Assign data owners and escalation paths.
• Over-frequent refresh → Align to business need; hourly vs. real-time tradeoffs in cost and stability.
• No acceptance criteria → Agree on numeric thresholds, sample checks, and RLS tests before build.
• Scope creep → Version requirements and log change requests with impact on time and effort.

Mini project: From request to BI spec

Scenario: Marketing wants a campaign performance dashboard.

1. Interview two stakeholders; capture decisions they make weekly.
2. Define 4–6 KPIs (e.g., Spend, Impressions, CTR, CPA, ROAS) with precise formulas and grain.
3. Create a role matrix (Marketing Manager, Channel Lead, Analyst) and row-level rules by market.
4. Map data sources (ad platforms, web analytics, CRM) with owners.
5. Propose refresh frequency (e.g., 4× daily) and a clear SLA.
6. Write acceptance criteria (e.g., ROAS within ±1% of finance for last closed day).
7. Draft the BI spec (pages, visuals, filters, RLS, refresh, acceptance).

Practical projects

• Revamp an underused dashboard: re-interview users, rewrite KPIs, cut low-value tiles, add decision notes.
• Create a scope and change log for a live reporting request and simulate two change requests with impact estimates.
• Design a data refresh strategy for three dashboards with different recency needs and justify each choice.

Subskills

• Clarifying KPI Definitions With Examples — Create precise, testable KPI formulas with grain, inclusions, exclusions, and owner.
• Identifying Users Roles And Access Needs — Map user groups to pages, actions, and row-level rules.
• Capturing Dashboard Use Cases And Decisions — Document the decision and action behind each chart.
• Mapping Data Sources And Ownership — Trace metrics to tables, fields, joins, and accountable owners.
• Defining Refresh Frequency And Latency Needs — Set refresh plans and SLAs that match decision cadence.
• Aligning On Success Criteria — Write acceptance tests for numbers, performance, and security.
• Managing Scope And Change Requests — Version requirements; assess and log changes with impact.
• Translating Needs Into BI Specs — Produce clear, build-ready BI documentation.

Next steps

• Pick one active request and pilot this process end-to-end.
• Build a small library of KPI definitions and reuse them across dashboards.
• Schedule short playback sessions to validate use cases and acceptance criteria.

Take the Skill Exam

This exam is available to everyone for free. Your score helps you identify what to review. If you are logged in, your progress and attempts will be saved.