Dashboard Requirements Specification Prompt

Public field comparison

Dashboard Requirements Prompt

Dashboard Requirements Specification Prompt

Define dashboard users, decisions, KPIs, data sources, refresh rules, filters, and drilldowns.

Turn dashboard goals, user decisions, KPI definitions, data sources, interactions, and governance constraints into an implementation-ready requirements specification.

—

Use this prompt to define a decision-focused dashboard, resolve KPI and data ambiguities, document controls, and prepare a verifiable handoff for BI and data teams.

Requirements Clarification
Output Quality Review
Review Checklist Building
Implementation Planning

Converting stakeholder needs into a governed dashboard requirements specification
Defining KPI calculations, grain, ownership, and source-to-metric lineage
Preparing an implementation handoff for BI and data engineering teams
Reviewing dashboard readiness through traceable acceptance and reconciliation tests

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

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

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In ChatGPT, replace every bracketed variable with your dashboard context. Provide available evidence such as stakeholder notes, KPI definitions, data dictionaries, schemas, sample or redacted extracts, query outputs, current reports, wireframes, access policies, platform constraints, refresh logs, and acceptance standards. Then run the prompt and route unresolved definitions, controls, and approvals to the named human owners.

Use this when you need a production-ready dashboard result in Data Analysis, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A revenue operations team needs a regional pipeline dashboard. They provide sales-stage definitions, CRM schemas, fiscal-calendar rules, sample query results, access restrictions, an existing spreadsheet, and target refresh times. ChatGPT produces a KPI dictionary, source-to-metric mappings, filter and drilldown behavior, row-level access requirements, stale-data handling, a prioritized backlog, and reconciliation tests without claiming that the data or dashboard has already been validated.

Advanced

Advanced

ChatGPT

ChatGPT

dashboard

dashboard

chatgpt
data-analysis
dashboard
metrics

chatgpt
data-analysis
dashboard-requirements
business-intelligence
kpi-governance
data-lineage

Dashboard Requirements Prompt | AMO.ng

Dashboard Requirements Prompt | AMO.ng

Define dashboard users, decisions, KPIs, data sources, refresh rules, filters, and drilldowns.

Create an implementation-ready dashboard specification covering users, decisions, KPIs, data lineage, interactions, controls, and acceptance tests.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Data Analysis specialist using ChatGPT. Your task is: [Goal or task].
+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.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+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]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "Dashboard Requirements Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+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.
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+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.
 
−Do not give generic advice. Optimize for a production-quality dashboard outcome.
+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.