Make the expected behavior clear
Poor: System shall have audit trail.
Better: The system shall record creation, modification and deletion of GxP records, including user, date/time and previous/new values where applicable.
Then define which records and events are covered, how the history is protected, and how an authorized reviewer can retrieve it.
Cover the relevant needs
| Category | Example question |
|---|---|
| Business | Which process or decision must this use support? |
| Functional | What must the system do, prevent or calculate? |
| Data integrity | How will record meaning, completeness and change history be preserved? |
| Security | Which roles may perform each important action? |
| Electronic records and signatures | What record and signature controls apply to this use? |
| Interfaces | What data must move, and how are errors detected and handled? |
Use requirements to support testing and traceability
Give each important requirement an identifier and a measurable expected result. Link it to the function, the relevant risk and the evidence that demonstrates it. Document names can follow your procedure; the useful content matters more than the acronym.
Detailed practice, examples and references
Write requirements a tester and process owner can interpret the same way
“The system shall be compliant” cannot be tested as one behavior. Break the need into functions and controls that can be observed. Include inputs, conditions, outputs, exceptions, and the relevant record.
Example: “When an authorized reviewer rejects a CAPA effectiveness check, the workflow returns the CAPA to the investigation state, preserves the rejection reason, and prevents closure until the required reapproval is completed.”
This statement identifies an event, state change, retained information, and blocked action. The exact roles and transitions must match the approved process.
Worked requirement set: a material-status interface
| ID | Requirement | Useful challenge |
|---|---|---|
| MAT-01 | Transfer lot identifier and disposition without changing their meaning | Similar lot IDs; multiple plants; valid statuses |
| MAT-02 | Prevent material issue when the accepted disposition is quarantine | Screen, import, and interface issue paths |
| MAT-03 | Detect an unrecognized disposition code and route it for resolution | Blank, unknown, and malformed codes |
| MAT-04 | Preserve traceability between source transaction and receiving record | Retry and duplicate transaction |
| MAT-05 | Identify unresolved transfer failures to the responsible role | Alert generation, ownership, escalation, recovery |
Do not test the requirement using itself as the answer
If a system calculates a result, copying that result into the expected-results column proves little. Establish the expected result using an independently checked method, approved specification, or trustworthy reference calculation.
For a workflow, have the process owner confirm the allowed transitions. A developer’s description of how the workflow currently operates may contain the same mistake as the configuration.
Three common gaps
Only the successful path is specified. Add missing inputs, unauthorized actions, cancellation, retry, and recovery where relevant.
The user interface is the only entry point considered. Imports, APIs, scheduled jobs, and administrator tools may alter the same record.
The output is checked without its context. A value of 0.50 is not enough when its sample identifier, unit, specification, or status is wrong.
Example traceability note: “MAT-02 is supported by UI test T-12 and interface test T-13. The supplier test covers standard issue blocking; local T-13 addresses the configured warehouse integration. No conclusion is drawn about interfaces outside the approved scope.”
Common requirement documents
Organizations use different document names: URS, functional requirements specification (FRS), functional specification (FS), design specification (DS), and configuration specification (CS). The label matters less than controlled, testable content. A requirement should identify the required behavior, applicable data or record, operating condition, acceptance criterion, and traceability to risk and test evidence. Supplier specifications may be referenced when they accurately describe the configured function; customer-specific requirements still need to cover local workflow, roles, interfaces, migration, reports, and procedures.
Practitioner guidance by Sandip Thorat · Simplified 17 September 2026. Apply the requirements and approved procedures relevant to your system. Report a correction.
Questions and discussion
Ask a question or share a perspective. Contributions are reviewed before publication.
Loading contribution options…