Requirements, Specification, and Design
What this domain tests
Requirements, Specification, and Design tests whether you can turn a stakeholder need into a testable, traceable specification and a design that can be built and verified. Expect functional vs non-functional requirements, URS/FDS/SDS structure, acceptance criteria, traceability, and design artifacts such as P&IDs, cause-and-effect matrices, sequence charts, and alarm philosophy.
Core rules and concepts
- A requirement is testable if an independent tester can decide pass/fail with stated conditions, inputs, and tolerances. Fast and user-friendly are not requirements; a 2 s screen refresh at the 95th percentile under 50 concurrent clients is.
- Separate functional requirements (what the system does) from non-functional requirements (availability, throughput, accuracy, environmental ratings, cybersecurity, maintainability).
- Use a traceability matrix: stakeholder need to requirement to design element to test case. Every requirement needs a verification method.
- Write the URS in user/process language; FDS in functional terms; SDS in implementable detail. Do not let the SDS invent requirements not in the URS.
- Design for safe states: define failure response, interlocks, bypass handling, and operator recovery. Use ISA-101 for HMI hierarchy and ISA-18.2 for alarm rationalization.
Worked example
A stakeholder says: The filler must be fast and reliable. That is not verifiable. Rewrite as two requirements: R1: With 500 mL bottles and standard caps, steady-state throughput shall be at least 120 bottles/min over a 30-minute run, measured by the discharge counter, with no more than 1% rejects. R2: Availability shall be at least 98% during a 30-day production window, excluding planned maintenance. Trace R1 to a FAT test that runs 30 minutes and records counter and rejects; trace R2 to historian availability data over 30 days. Reasoning: each requirement names condition, metric, threshold, and measurement method. If the process changes to 1 L bottles, the requirement must be renegotiated; 120 bottles/min may not be physically achievable.
Traps that cost marks
- Writing compound requirements such as the system shall start, stop, and alarm, which cannot be tested as one item.
- Omitting acceptance criteria and assuming the vendor knows what reliable means.
- Over-specifying vendor hardware in the URS, which blocks competitive design.
- Adding safety requirements after the design freeze.
- Losing traceability when requirements change; no impact analysis.