How to Write Testable Control System Requirements

A specification that cannot be tested is not a dependable basis for control software. A useful system requirements specification describes the software’s expected behavior and sets out requirements in clear, verifiable terms. This control system specification writing guide explains how to turn operational needs into statements with defined outcomes and acceptance criteria.

Teams often start with a feature list because it captures what people want the system to do. But without documented assumptions, constraints and dependencies, designers, engineers and testers may interpret the same requirement differently.

Here, you’ll learn how to structure functional and non-functional requirements, define interfaces and reliability expectations, and link each requirement to a verification method. The steps also cover data use and assumptions to resolve before baselining the specification, so it can guide design, implementation and testing clearly.

What is a software requirement?

A requirement states a system need in a form teams can design and verify. Identify stakeholders, intended outcomes and constraints before selecting an implementation. A control system specification writing guide helps organise those needs into a consistent structure.

1. Classify functional and non-functional requirements

   Separate the functions software performs from its quality limits. Functional requirements describe behaviours, such as displaying an alarm when a sensor reports a fault. Non-functional requirements set criteria for performance, security, reliability or usability. Identify operators, maintainers and system owners through interviews or workshops, then record their needs. Structure requirements across system and software levels, keeping each linked to its source and related tests. ISO/IEC/IEEE 29148:2018 is a reference for requirements engineering.

2. Write clear, concise, singular statements

   Write one verifiable idea per statement, using the active voice. Use “shall” for a requirement, “will” for a declaration and “should” for a goal, following NASA guidance. A control system specification writing guide should separate required outcomes from implementation choices. A control system functional design specification should describe functions, operating modes, sequences, alarms, interfaces and user adjustments. Control narratives should state operating conditions and expected responses; sequence-of-operations descriptions should set out transitions in order. Define each interlock by its initiating condition and required system response.

3. Address safety, cybersecurity and regulatory needs

   Identify applicable safety, cybersecurity and regulatory criteria with relevant stakeholders, then express each as a testable system outcome. Specify safe responses to faults, authorised access and required records where the project needs them. Link each criterion to its source and verification method. Vague terms, combined requirements and hidden assumptions can cause conflicting interpretations and missed tests. Avoid prescribing implementation unless a genuine constraint requires it.

Documenting assumptions, constraints, and dependencies

Build the SRS as a controlled record of agreed needs, limits and decisions. Clear documentation helps teams manage changes and make external dependencies and unresolved assumptions explicit.

1. Set the document’s purpose and structure. Define the system boundary, intended readers and relationship between system-level and software requirements. ISO/IEC/IEEE 29148:2018 is a reference for systems and software requirements engineering. It describes expected content and well-formed requirements, whilst allowing flexible section ordering. Use sections that support your project, such as scope, operating context, requirements, interfaces, constraints and verification. Give requirements unique identifiers to support handling and traceability.
2. Record assumptions before baselining. NASA’s requirement-writing guidance recommends confirming assumptions before the requirements document is baselined. For each assumption, record its rationale, owner and affected requirement. For example, if a control function depends on an external sensor providing valid status data, state that dependency explicitly. If the assumption changes, identify which requirements and tests need review.
3. Separate constraints from dependencies. A constraint limits acceptable solutions, such as a required connection to an existing system. A dependency is an input, service or decision needed for a requirement to work. Name the affected subsystem, expected information and consequences of a change. Avoid ambiguous terms such as “standard interface”; describe the required exchange and its purpose instead.
4. Manage requirements through review and updates. Circulate the SRS to stakeholders for feedback and approval, then revise it as requirements evolve. Track each change by its reason, affected identifiers, approval status and related verification work. Use practical examples in reviews, such as a changed alarm condition or an altered external data source. This keeps the document aligned with stakeholder decisions and makes impacts visible before implementation.

Interfaces, maintainability, and reliability

Define how components connect, behave under fault conditions and support future maintenance. Clear technical detail gives design and test teams a shared basis for evaluating the solution.

1. Specify hardware, software and network architectures

   Describe the control system’s hardware, software and network architecture, including each component’s role and connection to adjacent systems. Identify the boundary between controllers, operator interfaces and external equipment. For every interface, define the data exchanged, direction, format and expected response to invalid or lost information. Check that internal and external interfaces are necessary, sufficient and consistent, as NASA’s requirements guidance recommends.

2. Document I/O, instrument data, alarms and setpoints

   Create an I/O list identifying each signal, its source or destination, engineering units and normal behaviour. Record instrument ranges, alarm conditions, priorities, acknowledgement behaviour and setpoint limits. For example, distinguish a sensor fault from a process value outside its operating range. This detail helps engineers trace each signal through the control logic and gives testers observable outcomes to assess.

3. Set measurable maintainability requirements. Specify the diagnostic information required, access for fault investigation and conditions for restoring operation. NASA recommends defining maintainability in measurable, verifiable terms. For example, require a diagnostic display to identify the affected equipment and fault state, rather than saying the system must be “easy to maintain”.
4. Define reliability through operating conditions and failure responses. State the conditions under which the system must continue operating, and describe its response to component or communication failures. An embedded-system example specifies reliable operation from -20C to 50C. Use failure mode and effects analysis to assess severity, occurrence and detectability, then document mitigation for higher-priority risks.
5. Plan for controlled updates. Identify which architecture records, interface descriptions and I/O schedules must change when a component is replaced. Link each proposed update to affected requirements and tests, so a revised instrument or network connection does not leave alarms, setpoints or fault responses inconsistent.

Verifiability, testability, and data usage

Set a verification method and measurable acceptance criteria for every requirement. Then define the data needed to show that each objective has been met.

1. Choose how to verify each requirement. NASA’s requirement-writing guidance recommends testing, demonstration, inspection or analysis. Match the method to the requirement: test a specified alarm response, inspect a configuration record, or analyse performance data. Record the method beside the requirement and link it to its upstream source, so reviewers can follow the rationale.
2. Write acceptance criteria in measurable terms. State the pass or fail conditions, including inputs, operating state and expected response. For example, define the alarm condition and the indication operators should observe. Avoid words such as “quickly” or “reliably” unless you define a measurable threshold and tolerance.
3. Make each test repeatable. Document required equipment, test data, procedure, expected result and evidence format. If a performance value needs tolerance, specify how it is assessed; NASA guidance gives 3 sigma root sum squares as an example. Keep criteria in plain language, then map them to executable tests.
4. Define data use for validation and ongoing operation. Identify each required data item, its source, units, format, quality rules and intended use. State how missing, stale or invalid values affect the result. For instance, a test record should distinguish a genuine control response from one based on invalid input.
5. Manage unresolved values rather than hiding them. NASA’s requirement-writing guidance recommends minimizing TBD values and using a best estimate marked TBR with a rationale, an elimination plan, a responsible person, and a resolution deadline. This keeps assumptions visible and gives requirements management a clear path to closure.

For support turning verification needs into an integrated engineering specification, discuss mission-critical control system design.

AAC LTD | All About Control: SCADA Integration

AAC LTD | All About Control provides SCADA Integration for projects where defined control requirements must become an integrated operational system. Its Mission Critical Control Systems work supports teams translating operational needs into system behaviour, interfaces and verification objectives. Where existing Siemens S5 infrastructure requires modernisation, Siemens S5 to S7 Migration can form part of the project solution; Automation Engineering Consultancy can help resolve requirements and design decisions earlier. Control systems design from RIBA Stage 1 to Stage 5 supports requirements development across the project lifecycle, including commissioning. These offerings are relevant when a specification must align software, operational needs and integration boundaries, rather than address an isolated document alone. Contact AAC LTD | All About Control to discuss your control system requirements and project context.

Carry the specification into delivery

Treat the specification as a working engineering baseline, not a document that becomes dormant after approval. As design decisions develop, keep requirement ownership, change rationale and verification evidence aligned. This gives project teams a clear route from agreed intent to operational acceptance. Use this control system specification writing guide to establish that discipline early and carry it through design reviews, integration and commissioning.

Where the next step involves integrating control platforms, AAC LTD | All About Control offers SCADA Integration and Mission Critical Control Systems. For an existing Siemens S5 installation, its Siemens S5 to S7 Migration offering addresses the transition as part of the wider control-system context. These capabilities are relevant when requirements must inform real engineering decisions, rather than remain isolated statements.

Contact AAC LTD | All About Control to discuss your project’s control-system requirements. A carefully developed specification gives your team a stronger foundation for the work ahead.

Frequently Asked Questions

What Is a System Requirements Specification (SRS)?

An SRS is the controlled reference for the software’s agreed requirements and boundaries. It helps project participants distinguish approved scope from proposals or design choices. For example, a change request can identify the affected requirement before implementation proceeds. Keep the revision status and approval record visible, so teams use the same agreed baseline during design, procurement and testing.

What are some desirable properties of requirements?

Good requirements are necessary, feasible, consistent, complete and verifiable. They should also avoid prescribing a solution unless a genuine constraint demands it. For example, “the controller shall retain the alarm state after a communications interruption” describes an outcome; a separate design decision can define how to achieve it. Review statements for conflicting interpretations, missing conditions and terms such as “appropriate” or “normal”.

Who imposes the requirements?

Requirements come from several interested parties, not one author alone. Operators describe task needs, asset owners set operational objectives, and engineering teams identify technical boundaries. Regulators or contract documents may also establish applicable obligations. For example, an operator may need a clear alarm indication, whilst an owner defines how that event affects plant operation. Record each requirement’s origin to support reviews and change decisions.

What is a control system specification and what should it include?

A control system specification defines the system’s intended behaviour and the conditions for accepting its design. Alongside control functions, it can establish scope boundaries, operating modes, alarm handling, data exchanges and commissioning evidence. Include document ownership and revision control. For example, a change to an operating mode should identify which narratives, interface records and acceptance evidence need review.

What standards apply to control system specifications, such as ISA-5.1 and IEC 61131?

Applicable standards depend on the system scope, project obligations and jurisdiction. ISA-5.1 and IEC 61131 may be relevant references for instrumentation representation and programmable controller systems; determine their role against the project’s actual needs. ISO/IEC/IEEE 29148:2018 provides a reference for systems and software requirements engineering. Identify applicable editions and requirements in the project’s standards register, rather than assuming one standard covers every concern.

How do you gather and document control system requirements?

Combine stakeholder discussions with operational evidence, such as existing drawings, alarm records and maintenance observations. Capture each need in a consistent register, recording its source, rationale, owner and affected system boundary. For example, compare an operator’s description of a recurring event with current alarm records before drafting a requirement. Circulate the draft for review, resolve conflicting needs and retain decisions with the controlled document.