Foundation guide

Requirements — Describe observable behavior

“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.

Editorial previewTechnical review and author byline approval pending

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

IDRequirementUseful challenge
MAT-01Transfer lot identifier and disposition without changing their meaningSimilar lot IDs; multiple plants; valid statuses
MAT-02Prevent material issue when the accepted disposition is quarantineScreen, import, and interface issue paths
MAT-03Detect an unrecognized disposition code and route it for resolutionBlank, unknown, and malformed codes
MAT-04Preserve traceability between source transaction and receiving recordRetry and duplicate transaction
MAT-05Identify unresolved transfer failures to the responsible roleAlert 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.”