Dashboard Requirements Specification Prompt

Use ChatGPT to convert the supplied dashboard context into a decision-ready requirements specification that business owners, analysts, data engineers, BI developers, security reviewers, and testers can review and implement.

Inputs
- Dashboard objective and scope: [Dashboard objective and scope]
- Users and decisions: [Users and decisions]
- Metric definitions and targets: [Metric definitions and targets]
- Data sources and constraints: [Data sources and constraints]
- Interaction and delivery needs: [Interaction and delivery needs]
- Governance and operational constraints: [Governance and operational constraints]
- Existing artifacts and acceptance criteria: [Existing artifacts and acceptance criteria]

Input and clarification rules
1. Treat the objective, primary users, decisions to support, candidate metrics, and candidate data sources as minimum prerequisites. Named owners, wireframes, data dictionaries, sample extracts, query results, current reports, policies, platform constraints, service levels, and acceptance criteria are useful supporting evidence.
2. If the objective, primary decision, metric intent, or source feasibility is missing or contradictory, ask only the questions that block a reliable specification. Explain why each answer matters. Do not silently choose a business definition.
3. When bounded progress is possible, produce a clearly marked draft and preserve unresolved items in an open-questions register. Use provisional assumptions only when they are reversible and low risk.
4. Classify important statements as supplied fact, observed in an artifact, assumption, proposed requirement, conflict, or unknown. Cite the relevant artifact, page, table, field, query output, or stakeholder statement when that reference is available.
5. Do not infer that similarly named fields or KPIs are equivalent. Surface conflicts involving formula, grain, population, status logic, timezone, currency, fiscal calendar, historical treatment, or source of record.

ChatGPT capability and authority boundaries
- Inspect only text, files, schemas, screenshots, query results, and other materials actually available in the conversation. State when a file, live database, BI workspace, catalog, or external system is unavailable.
- Draft requirements, mappings, test cases, questions, and recommendations. Do not claim to have queried a database, profiled data, tested calculations, changed permissions, configured alerts, published a dashboard, or obtained approval unless direct execution evidence is supplied.
- Do not authorize KPI definitions, source-of-record choices, access rules, privacy classifications, or production releases. Assign these decisions to the appropriate business metric owner, data owner, security or privacy reviewer, and BI product owner.
- Do not reproduce credentials, secrets, or unnecessary personal or confidential records. If source material contains credentials or excessive sensitive data, stop that line of analysis and request a redacted or aggregated version.
- Treat compliance, privacy, financial, and employment-related measures as requiring human review. Recommend least-privilege access, aggregation or suppression where appropriate, and a rollback path for production publication or access changes.

Requirements development workflow
1. Frame the decision problem. Identify the dashboard purpose, in-scope and out-of-scope decisions, audiences, usage frequency, current workaround, business owner, expected action after viewing, and the cost of stale or incorrect information.
2. Define audience and access needs. Separate viewers, explorers, operators, metric owners, administrators, and approvers. Capture row-level or column-level restrictions, export permissions, regional boundaries, segregation requirements, and accessibility needs.
3. Build the KPI contract. For every KPI or diagnostic measure, define its business question, formula, numerator and denominator where applicable, aggregation behavior, unit, grain, dimensions, inclusion and exclusion rules, status logic, time basis, comparison period, target or threshold, display format, owner, source of record, and known caveats. Flag non-additive measures, ratios, distinct counts, snapshots, and metrics that cannot safely be summed across time or groups.
4. Map data feasibility and lineage. Connect each measure and dimension to source systems, tables or entities, fields, join keys, expected cardinality, transformation rules, history strategy, and owner. Address duplicate keys, nulls, late-arriving records, slowly changing dimensions, deleted records, backfills, timezone conversion, currency conversion, fiscal calendars, and mismatched grains. Mark mappings as confirmed only when supported by supplied evidence.
5. Specify the information architecture. Define pages or views, visual purpose, chart or table choice, grouping, sort order, labels, units, reference lines, explanatory text, default state, and empty, loading, stale, partial, and error states. Avoid visual precision unsupported by the data.
6. Define interaction behavior. Document filter scope and defaults, cascading behavior, date controls, cross-filtering, drilldown and drill-through paths, reset behavior, search, tooltips, export, subscriptions, alerts, bookmarks, and navigation. State what context must persist and how restricted or unavailable detail should appear.
7. Establish refresh and operational controls. Specify source availability, refresh cadence, acceptable data latency, freshness timestamp, failure notification, retry or recovery expectation, ownership, support route, retention, usage monitoring, performance targets, and change-control expectations. Distinguish business freshness from pipeline completion.
8. Resolve trade-offs explicitly. Compare alternatives where requirements conflict, including accuracy versus latency, detail versus privacy, flexibility versus performance, self-service versus governed definitions, historical restatement versus reproducibility, and feature scope versus delivery effort. Recommend an option with rationale, dependencies, and approval owner.
9. Prioritize implementation. Give each requirement a stable identifier, priority, rationale, dependency, accountable owner, acceptance method, and status. Separate minimum viable decision support from later enhancements; do not label unresolved dependencies as implementation-ready.
10. Design verification before handoff. Include calculation reconciliation, source-to-dashboard totals, filter and drill path checks, boundary dates, timezone and currency cases, null and duplicate handling, access-control tests, export behavior, refresh and stale-data behavior, performance, browser or device needs, and accessibility. Each test must state preconditions, test data or evidence, expected result, actual result, and status. If no test was run, record the actual result as unavailable and the status as not run.

Required output
1. Decision and scope brief
- Dashboard objective, supported decisions, audiences, expected actions, scope boundaries, success measures, assumptions, and blockers.

2. Evidence and uncertainty register
- Table with ID, statement, classification, evidence reference, confidence, conflict or limitation, impact, owner, and resolution needed.

3. Stakeholder and access matrix
- Table with audience or role, decisions supported, required detail, permitted interactions, data restrictions, approver, and unresolved access questions.

4. KPI dictionary
- Table with KPI ID, name, business question, precise definition, formula, grain, dimensions, filters, time basis, unit, target, aggregation behavior, source of record, owner, caveats, evidence status, and approval status.

5. Data mapping and lineage specification
- Table with requirement or KPI ID, source system, entity or table, fields, join keys, cardinality, transformation, history treatment, refresh dependency, data-quality rule, owner, and confirmation status.

6. Dashboard behavior specification
- Organize by page or view. For each component, provide its purpose, visual form, measures, dimensions, defaults, filters, interactions, drill path, tooltip content, restricted-data behavior, and empty, stale, partial, loading, and error states. Add a concise text wireframe when no supplied mockup is available.

7. Non-functional and operating requirements
- Cover freshness and latency, performance, accessibility, supported delivery channels, security and privacy, export controls, monitoring, failure notification, recovery, retention, support ownership, and change control. Use measurable thresholds where supplied; otherwise mark the threshold for owner decision.

8. Prioritized requirements backlog
- Table with requirement ID, requirement statement, priority, rationale, dependency, owner, acceptance method, evidence status, and readiness state.

9. Decisions, risks, and open questions
- Separate confirmed decisions from proposed decisions. For each risk or unresolved question, include impact, likelihood where defensible, mitigation or options, decision owner, approval point, and due stage. Highlight privacy exposure, misleading aggregation, stale data, source instability, access leakage, reconciliation failure, and performance risk when applicable.

10. Acceptance and reconciliation plan
- Table with test ID, linked requirement, scenario, preconditions, test data or evidence, procedure, expected result, actual result, status, and responsible reviewer. Include a traceability summary showing whether every high-priority requirement has at least one acceptance test and an owner.

11. Approval and handoff state
- List the artifacts ready for review, unavailable evidence, blocking decisions, required business, data, security, and BI approvals, and the smallest safe next action. Label the overall result draft, blocked, ready for review, or approved only when the corresponding evidence exists. Never describe work as validated, tested, approved, implemented, published, or complete without evidence that the action occurred.