A procurement promise to “support integration” needs specific objects, data direction, field definitions, update conditions, permissions, recovery behavior and test records. Verify source-vendor access and authorization first, then link each interface to pages, deployment and deliverables. This guide retains the full dashboard brief and adds a worksheet for technical integration discussions.
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 |
For each integration requirement, record the business object, data direction, fields, update conditions, authorization, error behavior and acceptance evidence. Listing ERP, MES or IoT is insufficient for estimating scope. Read-only summaries, historical migration and approval write-back from the same source are different work items.
| Requirement field | Project conditions to specify | Acceptance evidence |
|---|---|---|
| Source and direction | System, API version, objects, read/write scope and source owner. | Approved access method and a jointly confirmed object list. |
| Definitions | Types, units, unique IDs, timestamps, nulls and deletion rules. | Field mappings and recalculable normal/error samples. |
| Update conditions | Separate source updates, collection and page refresh; set achievable targets. | Source/page timing records and late/stale states. |
| Permissions and environment | Test/production access, roles, network approval and vendor authorization. | Authorized-role tests and denied-access tests. |
| Failure and recovery | Timeouts, duplicates, outages, credential expiry, retries and owners. | Fault-injection or an agreed equivalent test record. |
| Dependencies and changes | Sample readiness, contact owners, changed fields and new scope. | Readiness list, impact review and retest records. |
Hypothetical wording: “Read equipment ID, operating state and source timestamp through an approved read-only platform API. Field meanings follow the jointly approved point-list version. Refresh targets depend on source capability. Timeouts show stale data rather than normal operation. Authorized tests retain inputs, source times, page outputs and recovery results.” This illustrates technical scope; actual objects and conditions must be added before it becomes part of a project agreement.
Confirm that the source vendor provides the interface, who pays any associated fees, when environments become available and who accepts joint tests. Record unknowns as dependencies, with a method to pause affected tests or reassess scope. For displays and site networks, use the command-center responsibility checklist.
An April 2026 public procurement notice for a decision platform separates integrated dashboards, application scenarios and back-end support, including page integration and metric/data interfaces. It is an example of decomposing procurement scope; its budget and schedule are not benchmarks for other projects, and this worksheet does not replace procurement documents.
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.
Checked on October 15, 2026: the national standards portal lists GB/T 9385-2008 as current. This is an independently organized procurement worksheet, not a clause-by-clause reproduction of that standard.
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.