A dashboard procurement brief lets different suppliers estimate and quote against the same scope. Define at least the project goal, page inventory, metric definitions, APIs, design and device conditions, deployment and security, deliverables, and acceptance evidence. List unconfirmed interfaces, data, and environments as assumptions or open items; do not bury them in vague phrases like “real-time,” “intelligent,” or “high-tech.”
The more verifiable the brief, the easier it is to compare quotations and decide whether a later change belongs to the original scope or is new work.
Define the use case and users first. Showroom reporting, management review, production monitoring, park operations, and emergency command require different page structures, refresh rates, and interaction depth. Start the brief with background, primary users, target displays, desired launch date, and first-phase goal so several directions do not become one oversized project.
For each page, list its name, purpose, main modules, interactions, and target device. “Build a data dashboard” is not enough: a single display and a full system of overview, topic, detail, and admin pages represent very different workloads.
| Page | Main content | To confirm |
|---|---|---|
| Overall overview | Core measures, trends, geographic or business distribution, and risk signals | First-screen priority and target resolution |
| Business topic | Sales, production, energy, project, or equipment topic | Filters, drilldowns, and detail scope |
| Alerts and events | Severity, location, time, state, and response record | Whether maps, video, or work orders are linked |
| Administration | Accounts, permissions, content settings, and data maintenance | What the customer must be able to maintain independently |
Identical metric names do not guarantee identical calculations. Sales may be counted on contracts, invoices, or receipts; equipment availability may use an instantaneous state or a period. Record each core metric's business meaning, formula, time range, filter conditions, data source, refresh rate, and approving owner. Mark unknown definitions “to be confirmed” instead of asking developers to guess.
For each source system, document connection method, field scope, authentication, refresh rate, test environment, and owner. If an API is not open yet, provide de-identified sample sheets and field definitions, plus a date for confirming the production interface and a rule for reassessing major field changes.
| Data item | What to record | Why it matters |
|---|---|---|
| Source systems | ERP, MES, CRM, WMS, IoT platform, or database | Identify system count and integration owners |
| Connection method | API, database, file, message queue, or manual entry | Determine technical route and access conditions |
| Update frequency | Real-time, minute, hourly, or daily | Define refresh and caching strategy |
| Error handling | Display behavior for timeouts, nulls, disconnection, or missing fields | Avoid blank screens after launch |
Attach brand colors, reference pages, screen dimensions, and viewing distance. Specify whether maps, 3D models, video, motion, carousels, filters, drilldowns, exports, or multiple device layouts are required. Reference images communicate direction; they do not confirm every feature. Interactions and media types that affect delivery must appear in the inventory.
State whether deployment is on the public internet, a cloud server, or the enterprise intranet. Note HTTPS, allowlists, permissions, logs, backups, security-level compliance support, and domestic-platform adaptation if required. Assign who provides the servers, purchases third-party licenses, and maintains certificates and API accounts after launch.
| Requirement ID | Acceptance prerequisite | Test action | Expected result | Evidence retained | Owner and status |
|---|---|---|---|---|---|
| Pages and devices | Page list, target resolution, browsers, and devices agreed | Review every page for content, interactions, overflow, empty states, and errors | Matches the approved design and scope; differences are recorded | Screenshots, test logs, and discrepancy list | Customer approves; implementer fixes or explains |
| Metrics and data | Formula, period, filters, source, update time, and owner agreed | Compare selected core metrics with source data or approved reports | Results can be recalculated; missing data, delays, and conflicting definitions remain visible | Definitions table, reconciliation, and exception records | Business and data owners approve together |
| APIs and permissions | Test accounts, API environments, data scope, and error conditions available | Test normal calls, denied access, timeouts, empty data, and recovery after disconnection | Access matches authorization; error and recovery behavior is clear | Request logs, permissions matrix, and error test records | System owner, implementer, and security owner approve |
| Deployment and handover | Servers, certificates, backups, and deliverables list frozen | Deploy and restore from documentation; inventory code, configuration, and instructions | Reproducible in the agreed environment; omissions and third-party dependencies disclosed | Deployment and restore records, signed handover list | Owner specified in the contract signs off |
| Vague phrase | More useful wording |
|---|---|
| The pages should look high-tech | Provide brand colors, visual references, use case, and target screen; agree on a visual-direction review round |
| All data should be real-time | Specify refresh frequency per item and whether source systems can supply it |
| Support multiple devices | Name which of large display, desktop, tablet, and phone are in this phase |
| Easy to extend later | Identify configurable metrics, pages, accounts, and data sources and the limits of extension APIs |
Download the on-site CSV template and fill in project background, page scope, key metrics, data sources, interactions, permissions, deployment, and acceptance. It supports internal discussion before procurement and can be a starting attachment for a quotation request.
Download the dashboard requirements checklist
When turning the requirements list into a procurement technical annex, also use the dashboard tender technical parameters and acceptance matrix (Chinese) to map each requirement to an acceptance environment, method, and evidence.
GB/T 9385-2008, Computer Software Requirements Specification Standard This can inform the organization of a software requirements specification. The fields here are a practical dashboard project checklist, not the standard's text, and they do not replace legal advice on procurement, tendering, intellectual property, or contracts. Procurement, business, technical, and legal owners should approve formal annexes and contract terms for the specific project.
The first procurement round should at least define pages, core metrics, data sources, and main interactions. Ordinary charts can leave room for design, but maps, 3D, video, drilldowns, and administration affect effort and should be stated.
Yes, if you identify expected source systems, sample data, and owners, and document the formal API confirmation milestone and limits of subsequent change.
Ask each vendor to itemize the same page, API, administration, deployment, and handover list, marking included, optional, and excluded items.
Typical gaps are metric definitions, error states, target resolution, permissions, deployment materials, and source-code or documentation boundaries.
Related service:Custom data visualization dashboards (Chinese). Continue reading:Tables and APIs to prepare before a project, Dashboard quotation scope and cost factors, Dashboard project acceptance criteria.