SCADA system requirements specification: how to write
A SCADA system requirements specification is the core attachment of a tender and technical contract—it converts monitoring scope, functional boundaries, data conventions, alarm strategy and acceptance criteria into verifiable clauses, and decides whether the project closes on schedule or drifts into scope disputes.
What chapters a SCADA requirements specification should cover
A specification usable directly as a tender or contract attachment is usually organized in the following order, and every chapter should end in verifiable clauses rather than generic capability statements:
- Background and objectives: the list of monitored objects (workshops, pump stations, power rooms), the operating problems to solve, and the relation to existing systems
- System boundary and interfaces: where SCADA responsibility ends, and who owns the interfaces to PLC, MES and video systems
- Functional requirements: monitoring, control, alarms, trends, reports, permissions and redundancy listed item by item, each with a priority
- Data requirements: point table size, sampling cycles, history retention period, archiving and export methods
- Non-functional requirements: availability targets, refresh and response limits, concurrent clients, cybersecurity and audit requirements
- Acceptance and delivery criteria: FAT/SAT items, test conditions, documents and training, warranty responsibilities
The order of chapters can be adjusted, but each chapter must answer one question: how will acceptance prove it? A clause with no verification method should either get criteria added or be removed—such clauses are where disputes start at acceptance time.
How to write the key fields: from capability wording to testable clauses
Functional and data requirements are the core of the specification. The key is to phrase every requirement as input–processing–observable result. The table below contrasts frequent sections:
| Section | What to write | Example clause | Common gap | Why it matters |
|---|---|---|---|---|
| Functions | Observable behavior of each screen and operation | Pump station screen refreshes all telemetry within 2 s; status echoes within 1 s after an operation | "Real-time monitoring" with no time limit | Without limits nothing can be tested |
| Points and data | Point count, sampling and storage conventions | About 5,000 points; analog 1 sample/s; change-of-value storage for digitals | Retention and compression undecided | Drives storage sizing and cost |
| Communication | Protocol, direction and failure behavior | Modbus TCP / OPC UA acquisition; buffered backfill after reconnect | Backfill after outages omitted | Lost data during outages is a classic dispute |
| Alarms | Tiering, notification chain, acknowledgment | Three tiers; escalation from crew to workshop to dispatch; acknowledgment and reset logged separately | Only "abnormal alarms" written | Alarm floods usually originate here |
| Permissions and audit | Role matrix and operation trail | Every operation, edit and acknowledgment logs user and time | Audit log retention undefined | A hard requirement in compliance audits |
Give each requirement a unique identifier and a priority (mandatory, expected, optional), and let acceptance test cases reference those identifiers directly. During FAT/SAT the checklist then maps one-to-one, with nothing skipped and nothing re-interpreted.
Common gaps and red lines: the expensive mistakes at contract stage
Reviews of delivered monitoring projects show that specifications rarely miss feature clauses—they miss boundaries and conventions. These gaps appear often and cost the most to fix later:
- Boundary gaps: control authority between SCADA and PLC not defined—who issues setpoints, whether local or remote takes priority, and how fail-safe acts
- Data gaps: history retention and export format not agreed—years into operation the plant cannot satisfy an audit trace
- Communication gaps: protocol names without failure behavior—reconnect, buffered backfill and time synchronization each lack clauses
- Alarm gaps: no tiering or suppression strategy—after go-live alarms flood the screen and operators miss critical ones
- Acceptance gaps: criteria written as "stable operation"—no quantified indicators or test conditions, so each side interprets freely
The fix is a counter-question list per gap type: ask "who holds control authority" in the boundary chapter, "how long is data kept and how is it exported" in the data chapter, "what happens when the link breaks" in the communication chapter, "who receives which alarm at what time" in the alarm chapter, and "which test conditions prove it" in the acceptance chapter. When all five have answers inside the document, the specification is ready to serve as a contract attachment.
Summary
One criterion decides whether a SCADA requirements specification is ready for a contract attachment: every clause states an observable result and a verification method. The chapter framework, the field-by-field table and the five-question checklist can be applied directly to your next tender, settling boundaries and conventions before work starts.
Request an on-site diagnosis
An experienced engineer will review your monitoring scope, point conventions and acceptance criteria with you, so the requirements specification is settled before tender and contract. An English-speaking contact is available throughout for cross-border projects.
Contact Us