A BI requirement should state who makes which decision, using what measures and dimensions, at what cadence, with what evidence and resulting action. “Build an executive dashboard” describes a format, not the decision problem.
Start from a real management review and trace each question back to data authority. Then define exploration, freshness, quality, access and action. The visual design comes after the decision model.
Choose one decision cadence
Observe a weekly, monthly or event-driven decision. Record participants, questions, options, constraints and what action follows. Collect the spreadsheets, reports and explanations currently used.
A BI programme becomes manageable when it starts with a bounded operating cadence rather than an enterprise wish for “better insight.”
Write a decision requirement
| Element | Question |
|---|---|
| Decision | What choice or intervention must be made? |
| Owner/cadence | Who decides and when? |
| Measures | Which evidence changes the choice? |
| Dimensions | How must results be segmented? |
| Threshold | What condition triggers investigation? |
| Action | Where is the outcome assigned and reviewed? |
Define measures completely
Specify business meaning, formula, grain, time basis, currency, population, inclusions, exclusions, owner and source. Pair a performance measure with quality or risk guardrails.
Record examples at boundaries. “Active customer,” “on time” and “margin” often have several legitimate definitions.
Map dimensions and drill paths
List the first comparison and likely diagnostic path: region to location, product family to item, total cost to supplier or cycle time to exception type. Define hierarchies and slowly changing structures.
Do not promise unrestricted drill-down. Protect sensitive or statistically misleading detail and make aggregation rules visible.
Trace data authority
For every measure and dimension, identify source system, object, identifier, transformation, steward and quality control. Show the lineage needed by users to trust or challenge an answer.
Where sources disagree, record the decision rule and remediation owner. BI should expose unresolved authority, not conceal it in a calculation.
Specify freshness from action
Determine the latest useful arrival based on when action can occur. A daily decision may not need streaming data; a risk event may. Define source latency, refresh, failure notification and stale-data display.
Test late and partial loads. Users should recognise when a result is incomplete before acting.
Define exploration boundaries
State which users can filter, create measures, combine data, publish and certify. Separate personal analysis, team content and governed outputs. Define how useful exploration becomes reusable content.
Self-service needs training and stewardship. Otherwise every analyst creates a different definition and the organisation loses the comparison it sought.
Include data-quality requirements
Set checks for completeness, validity, uniqueness, consistency, timeliness and reconciliation according to decision impact. Display relevant limitations alongside the measure.
Define who investigates and whether the decision pauses, proceeds with warning or uses a fallback when quality fails.
Test the analysis journey
Provide a real question and representative data. Ask users to detect change, segment it, investigate a driver, trace a record and explain action. Add a changed definition and failed refresh.
Record exports and manual calculations. They reveal requirements for explanation, workflow or data that the dashboard itself does not meet.
Connect insight to action
Define where decisions, owners and due dates are recorded and how the next review sees the result. Avoid a dashboard that produces screenshots and conversations with no closed loop.
Measure decision lead time, repeated preparation, model reuse, unresolved quality issues and actions completed—not page views alone.
Define access by decision role
Map who can see aggregate, detailed and sensitive attributes and who may build or publish analysis. Test row-level access, changed roles, exports and shared links. A certified measure does not make every underlying record appropriate for every manager.
Include service identities and support access. Retain evidence where reporting contributes to a controlled decision.
Prototype with a thin vertical slice
Use one decision, a small authoritative dataset, core measures, a diagnostic path and action record. Validate it with the management forum before building an enterprise model. This tests meaning and habit while change is inexpensive.
Do not use a visually polished prototype with manually corrected data as evidence of production feasibility. Show lineage, refresh and exception handling.
Specify lifecycle and change
Define development, test and production workspaces; version and peer review; refresh deployment; measure change approval; usage review; and retirement. Identify who communicates a definition change and whether historical results are restated.
BI content is software and business policy together. A change can affect decisions even when the dashboard still loads successfully.
Plan support and literacy
State how users learn definitions, investigate responsibly, report data issues and obtain help. Train with the decision scenario and common misinterpretations rather than a catalogue of controls.
Assign model, data and forum owners. Requirements are incomplete if nobody can operate the analytical service after implementation.
Package the requirements
Retain decision cards, measure dictionary, dimensional model, lineage, quality rules, access roles, freshness, scenarios, operating owners and open assumptions. Prioritise mandatory decision journeys before presentation preferences.
The package should guide product evaluation, data design, acceptance and later change without reducing BI to a list of chart types.