How to Write Testable Requirements and Acceptance Criteria for a GxP System

Most requirements documents are readable. Few are testable. The difference only becomes visible at the point someone tries to write a test script against them, discovers the requirement describes an intention rather than a condition, and either invents the missing detail themselves or escalates back to the business analyst weeks into execution. By then the requirement has already been reviewed, approved and traced. The defect is in a document everyone signed off.

A requirement earns the description "testable" when a tester with no access to the requirement's author could design a test that unambiguously passes or fails. If two competent testers could reasonably disagree about whether the system met the requirement, it is not finished.

What testable actually means

A testable requirement names three things explicitly:

1. The condition: the state, input or trigger under which the requirement applies.
2. The action or behaviour: what the system does in response.
3. The expected outcome: the observable result, including any tolerance, format or timing constraint that would let a reviewer distinguish pass from fail.

"The system shall support role-based access control" fails this test. It describes a capability, not a condition-outcome pair. A tester cannot design one test case for it, because it does not say which roles, which objects, which actions or what a correct denial looks like.

"When a user without the QA Reviewer role attempts to approve a Change Control record, the system shall prevent the approval action and shall not create an approval audit trail entry" is testable. It names the actor, the trigger, the blocked action and the negative evidence (no audit entry) that confirms the block was real rather than merely hidden by the interface.

Requirement levels and where testability breaks down

GAMP 5's lifecycle separates user requirements, functional requirements and design detail, and testability is usually lost at the transition between them rather than within a single level:

• User Requirements Specification (URS). States business and regulatory need in the user's language. A URS item may legitimately be broader, such as "the system shall restrict Change Control approval to authorised roles", provided it decomposes cleanly into testable functional requirements below it.
• Functional Requirements / Design Specification. This is where testability is mandatory, not optional. Every functional requirement should be independently verifiable without needing to interpret intent.
• Test cases. Each test case should trace to one or more functional requirements and exercise a specific condition, including negative and boundary cases the requirement implies but does not always spell out.

A common defect pattern is a URS-level statement copied unchanged into the functional specification. It survives review because it reads sensibly at the business level, then fails at test-script-writing time because no one converted it into a bounded condition.

Writing the acceptance criteria

Acceptance criteria are the explicit, falsifiable statement attached to a requirement: the thing a test script is actually built from. A useful structure is condition, action, expected result, and exception:

• Given [a defined starting state or precondition]
• When [a specific action or event occurs]
• Then [an observable, checkable outcome follows], within [any relevant tolerance, such as timing, precision or format]
• Otherwise [what happens when the condition is not met, or the input is invalid]

The "otherwise" clause is the one most often missing, and it is usually where a system's real weaknesses live. A requirement that only specifies the happy path, such as "the system shall calculate the expiry date from the manufacture date and shelf-life period", says nothing about what happens with a missing shelf-life value, a manufacture date in the future, or a shelf-life expressed in a different unit than expected. Each of those is a plausible production condition and each deserves its own acceptance criterion, not an assumption that "the system will handle it sensibly."

For requirements involving calculations, reports or thresholds, state the tolerance explicitly. "The system shall calculate the potency result to two decimal places, rounding half-up, and shall flag any result outside the validated assay range of 90.0–110.0% as Out of Specification" is testable and leaves no discretion to the person writing the script. "The system shall calculate an accurate potency result" is not, because "accurate" has no independently checkable threshold.

Common ambiguity patterns to eliminate

A short list of wording patterns reliably signals an untestable requirement:

• Unbounded adjectives: "user-friendly," "robust," "efficient," "appropriate." None of these can be measured without a separate definition, and that definition is usually never written.
• Compound requirements joined by "and": a single requirement covering multiple conditions makes partial pass/fail impossible to record cleanly. Split it; a test that is 60% correct is not a pass.
• Implicit "or" logic: "the system shall notify the reviewer or the approver" leaves open who is actually required to receive the notification and what happens if neither responds. State the actual decision rule.
• Passive voice hiding the actor: "the record shall be reviewed before approval" does not say who reviews it, under what role, or what evidence of review must exist. GxP requirements should generally name the responsible role explicitly.
• Requirements that describe configuration rather than behaviour: "the system shall be configured with three approval levels" describes a setting, not a verifiable outcome. The testable requirement is the behaviour that configuration is meant to produce: what happens at each level, and what happens if a level is skipped.

Traceability: connecting the requirement to risk, test and evidence

FDA's general principles for software validation treat traceability of requirements through to test evidence as a basic expectation of a defensible validation package, not an optional artefact. A traceability matrix linking each requirement to its originating risk, the functional specification that implements it, the test case that exercises it and the evidence that confirms the result gives an inspector, and more usefully the project team itself, a way to answer "how do we know this works" without re-reading the whole test protocol.

Two properties of the matrix matter more than its format:

• Completeness. Every requirement traces to at least one test case; every test case traces back to at least one requirement. An orphaned test case (testing something no requirement asked for) is often evidence that a requirement was never written down; an untraced requirement is a gap the test protocol will not catch.
• Risk linkage. A requirement's risk classification should determine the rigour of its evidence, not the reverse. If a requirement was assessed as high risk because it controls patient safety, product quality or data integrity, its acceptance criteria should be written with enough precision that no risk-relevant behaviour is left to tester discretion. Low-risk, standard-functionality requirements can tolerate less exhaustive acceptance criteria without weakening the validation package's overall defensibility.

A worked example

Vague version: "The system shall send a notification when a deviation is overdue."

Testable version:

> When a deviation record's target closure date has passed and the record's status is not Closed or Cancelled, the system shall send an email notification to the deviation owner and their line manager within 24 hours of the target closure date, containing the deviation ID, title and number of days overdue. If the deviation owner's account is inactive, the notification shall additionally be sent to the process area's designated Quality contact. No notification shall be sent for records already in Closed or Cancelled status regardless of target closure date.

This version supports at least four distinct test cases without further interpretation: an overdue open deviation triggering the standard notification, an overdue deviation with an inactive owner triggering the fallback recipient, a closed deviation past its target date correctly generating no notification, and a cancelled deviation correctly generating no notification. Each is independently pass/fail. The vague version supports none of them without the tester inventing the missing detail. At that point the tester, not the business analyst, has effectively authored the requirement.

Practitioner failure modes to watch for

• The requirement that can't fail. If every plausible system behaviour would satisfy the wording, the requirement is not adding assurance; it is decoration. Rewrite until a wrong answer is describable.
• Acceptance criteria written after the test script, not before. When acceptance criteria appear only inside the test protocol and never in the requirement itself, the requirement was effectively unreviewed at the point of approval; whoever wrote the test script silently decided what "correct" means.
• Requirements that reference "as per SOP-XXXX" without stating the operative rule. This can be appropriate where the procedure genuinely governs judgement, but where the SOP itself contains a testable rule (an approval sequence, a numeric threshold, a mandatory field), restate that rule in the requirement so the test case does not depend on a document under separate change control.
• Silence on negative and boundary cases. A requirements set that only ever describes success paths under-tests the system precisely where regulated processes most need control: what happens at the edge, on invalid input, or when something is supposed to be blocked.

Sources

• U.S. Food and Drug Administration, General Principles of Software Validation; Final Guidance for Industry and FDA Staff.
• European Commission, EudraLex Volume 4, Annex 11: Computerised Systems.