Chapter 02 · Requirements Engineering: Business Processes, Questions, Metrics, Dimensions, and Grain
Start from Decisions and Questions: Stakeholders, Use Cases, Reports, Explorations, and Data Products
Translate AtlasMart stakeholder decisions and analytical questions into source-grounded requirements before dimensional design begins.
Learning outcomes
AtlasMart has a familiar failure mode: finance asks for “revenue,” sales asks for “channel performance,” operations asks for “late fulfillment,” and a developer responds by opening the ERP schema and sketching tables. That reverses the design problem. Before modeling rows, the team must know which decisions the data supports, who will consume it, what question each metric answers, which slices are required, how fresh the answer must be, and which source event can support it.
Convert vague stakeholder requests into decision-oriented analytical requirements with explicit owners, consumers, freshness, and acceptance criteria.
Distinguish recurring reports, interactive exploration, and governed data products without treating a dashboard layout as the model.
Trace each candidate metric and slice to a business process and source event rather than to a convenient table name.
Identify ambiguity and unsupported requirements before schema design begins.
Produce a requirements matrix that later lessons can transform into grain, dimensions, facts, and tests.
The local verification scripts in this generated chapter were executed with Python 3.13.5 and SQLite 3.46.1. They use only stable standard-library/SQL features. Learners should still record the versions printed on their machine; the exercises prove semantic contracts on the synthetic fixture, not performance of a production warehouse.
1. Start from the decision, not the report layout
A stakeholder request is useful only when it reveals the decision or action the information supports. “Build a sales dashboard” is a presentation request. “The merchandising lead decides which category needs promotion based on paid units and paid merchandise value by day, category, and channel” is a modeling requirement because it names the decision, measurements, slices, and event population.
A report is one consumer surface. An exploration is an open-ended analytical interaction where users may change filters and groupings. A data product is a governed, owned data interface—such as a certified sales dataset or metric layer—with an explicit contract for semantics, freshness, quality, access, and change. The dimensional model should support stable business processes and measurement semantics; it should not be coupled to one dashboard’s current pixels.
2. Stakeholders contribute different parts of the contract
| Stakeholder | Decision / use case | Candidate measurement | Required slices | Freshness / quality need |
|---|---|---|---|---|
| Finance | Close and monitor commercial performance | paid_gmv, paid_order_count, AOV | order date, channel, customer segment | Reconciled; certified changes within 30 min for the case study |
| Sales | Understand channel mix | paid orders, paid GMV | channel, day, region | Trend accuracy; stable channel definitions |
| Merchandising | Assess product/category performance | paid units, paid GMV | product, category, day | Product reference data within agreed freshness |
| Inventory operations | Prioritize replenishment | on_hand_units | snapshot time, product, category | One chosen snapshot; do not sum across snapshots |
| Fulfillment operations | Identify shipping delay | order-to-ship hours, backlog | ship day, carrier, region | Requires shipment milestone evidence that Chapter 01 has not yet onboarded |
3. Requirements matrix: make assumptions reviewable
A useful requirements matrix ties each question to a business
process, metric definition, dimensions, source evidence,
freshness, and status. “Status” matters because not every
desired KPI is source-feasible today. Chapter 01 deliberately
has no shipment milestone source. Requirements engineering
should expose that gap rather than inventing a
ship_ts field.
[ { "id": "R-SALES-01", "owner": "Finance", "decision": "Monitor paid merchandise value and order volume", "question": "What are paid GMV and paid order count by day and customer segment?", "process": "order_capture", "metrics": ["paid_gmv", "paid_order_count"], "slices": ["order_date", "customer_segment"], "source_events": ["erp.order", "erp.order_line"], "freshness_minutes": 30, "status": "supported" }, { "id": "R-FULFILL-01", "owner": "Fulfillment", "decision": "Escalate late shipping", "question": "What is order-to-ship time by carrier and ship day?", "process": "fulfillment", "metrics": ["order_to_ship_hours"], "slices": ["carrier", "ship_date"], "source_events": ["erp.order", "fulfillment.shipment_milestone"], "freshness_minutes": 30, "status": "blocked_source_gap" }]4. Query prototypes test semantics before physical design
A query prototype is not the final warehouse SQL. It is a compact statement of the desired semantics against known source evidence. For the Chapter 01 fixture, four representative questions are executable today and one fulfillment question is intentionally blocked.
| Prototype | Question | Source-feasible now? | Reason |
|---|---|---|---|
| Q1 | Paid GMV + paid order count by order day and customer segment | Yes | Orders, order lines, customers exist |
| Q2 | Paid order count by channel | Yes | Order status/channel exist |
| Q3 | Paid units by product category | Yes | Order lines + products exist |
| Q4 | On-hand units by product category at 2026-09-20 08:00Z | Yes | Inventory snapshot + products exist |
| Q5 | Average order-to-ship hours by carrier and ship day | No | No shipment milestone/carrier event in Chapter 01 source contract |
A blocked requirement is a successful requirements-engineering outcome. It prevents a later model from presenting synthetic or inferred fields as authoritative business evidence.
5. Hands-on lab — stakeholder scenarios to an executable requirement check
Save the script below as check_requirements.py. It
does not design tables. It checks whether each requested
analytical question can be grounded in the source surfaces
already established by Chapter 01.
import json, sqlite3, sysfrom pathlib import Pathprint("Python:", sys.version.split()[0])print("SQLite:", sqlite3.sqlite_version)requirements = [ {"id":"Q1","process":"order_capture","sources":{"orders","order_lines","customers"},"status":"supported"}, {"id":"Q2","process":"order_capture","sources":{"orders"},"status":"supported"}, {"id":"Q3","process":"order_capture","sources":{"orders","order_lines","products"},"status":"supported"}, {"id":"Q4","process":"inventory","sources":{"inventory","products"},"status":"supported"}, {"id":"Q5","process":"fulfillment","sources":{"orders","shipment_milestones"},"status":"blocked_source_gap"}]available = {"orders","order_lines","customers","products","inventory"}for r in requirements: missing = sorted(r["sources"] - available) observed = "supported" if not missing else "blocked_source_gap" assert observed == r["status"], (r["id"], observed, missing) print(r["id"], observed, "missing=", missing)
Expected evidence: Q1–Q4 print supported; Q5 prints
blocked_source_gap with
shipment_milestones missing. Change Q5 to
status="supported"; the assertion must fail.
Restore it and rerun. This negative test proves the requirements
matrix is not merely descriptive—it prevents an unsupported KPI
from quietly entering design.
Cleanup: delete only
check_requirements.py from the disposable lab
directory.
6. Controlled failure: model the dashboard someone already drew
Suppose finance emails a dashboard mockup with cards for “Revenue,” “Customers,” and “Orders.” If the modeling team copies those labels into columns without asking what event population and filters apply, “Revenue” could mean booked order value, captured payment value, invoiced value, net revenue after returns, or settled cash. The schema may be syntactically clean while every dashboard is semantically inconsistent.
The repair is to write a metric contract: event population, formula, exclusions, time basis, currency/unit, aggregation behavior, owner, and source evidence. The dashboard can then consume the metric; it no longer defines it.
7. Production judgment and bridge
A requirement is ready for modeling when its decision owner, business process, measurement event/state, metric semantics, required dimensions, source evidence, freshness, quality expectations, and access sensitivity are explicit enough to challenge. Unknowns should remain visible as unknowns. This is more valuable than prematurely filling every cell.
The next lesson converts the requirements matrix into
process/event boundaries. That step prevents source table names
such as orders or inventory from
becoming accidental fact-table designs.
Knowledge check
Check your understanding
- Why is “build a sales dashboard” weaker than a decision-oriented requirement?
- What is the difference between a report, an exploration, and a governed data product?
- Why is Q5 intentionally marked blocked rather than filled with an inferred ship timestamp?
- Which parts of a requirement must be stable before choosing fact-table grain?
- What does the requirements validator prove, and what does it not prove?
Review the answers
1. It describes a presentation artifact but not the business decision, event population, metric semantics, slices, freshness, or acceptance criteria.
2. A report is a presentation, exploration is interactive analysis, and a data product is an owned contract for data/metrics, quality, freshness, access, and evolution. One model may support all three.
3. Because Chapter 01 has no authoritative shipment milestone source. Inventing one would turn a source gap into false evidence.
4. At minimum the business process/measurement event, intended question/metric meaning, source reality, and required analytical context should be explicit enough to declare grain.
5. It proves that the declared requirements are consistent with the known source-surface inventory. It does not prove business approval, production freshness, warehouse performance, or data correctness.
Summary and next step
Requirements engineering turns stakeholder language into testable analytical contracts. AtlasMart now has four supported source-grounded questions and one explicit fulfillment gap. Keep that gap visible.
Next: identify the business processes and events that create the measurements before designing any tables.
Authoritative references
- Kimball Group — Four-Step Dimensional Design Process — Select business process, declare grain, identify dimensions, then identify facts.
- Kimball Group — Business Processes — Business processes are measurement-generating operational activities and define a design target.
- Kimball Group — Grain — Grain is the binding statement of what one fact row represents and must precede dimensions/facts.
- Kimball Group — Fables and Facts — Explains why dimensional models should focus on measurement processes rather than specific report layouts.
- Kimball Group — Enterprise Data Warehouse Bus Matrix — Provides process-oriented planning context and links business processes to dimensions.
- Python documentation — json — Standard-library JSON handling used by the local requirement validator.