Functional Requirements Specification (FRS) in Pharma CSV: Template

What does a usable FRS look like in pharma CSV?

A usable functional requirements specification identifies the system behavior, its source URS, a unique FRS ID, a measurable acceptance criterion and the planned verification. The example below shows how to write those elements for an electronic deviation workflow.

"QA must approve a deviation before closure" is a reasonable user requirement. It is not yet a test. Can the initiator close the record? What if the approval is cancelled? Those answers belong in the functional detail.

What an FRS needs to specify

A user requirements specification (URS) states the outcome the process needs. A functional requirements specification (FRS) describes the software behavior that delivers it: permitted roles, input rules, workflow transitions, recorded data and how the system responds when an action is rejected. Good functional requirements let a tester observe a result without guessing what the writer intended.

Is a standalone FRS required? Not in every case. EU GMP Annex 15, section 3.2, describes a URS and/or a functional specification. Annex 11, sections 4.4 and 4.7, addresses traceable user requirements and appropriate test scenarios, including limits and error handling. Documentation and verification should be justified by intended use, GMP impact and risk. See Annex 15 and Annex 11.

Example system: A GMP deviation workflow

Consider a fictional electronic deviation system. It has two roles, Initiator and QA Reviewer, and three states: Draft, Pending QA Review and Closed. In this example, a deviation needs a Title, Event Date and Description. QA closes a submitted record using an authenticated electronic approval. These are assumed configuration rules, not mandatory field names or a description of GoVal.

URS-001: Initiators must be able to submit complete deviation records for QA review.
URS-002: Only designated QA Reviewers may approve and close submitted deviations.
URS-003: Changes to GMP-relevant data and electronic approvals must remain attributable and retrievable.

FRS template: Numbered requirements and acceptance criteria

OQ IDs refer to planned tests.

FRS / URS / OQ	Functional requirement	Measurable acceptance criteria
FRS-001.01URS-001 · OQ-001	Require Title, Event Date and Description.	Missing field: reject submission, show field error, retain values and Draft.
FRS-001.02URS-001 · OQ-002	Submit complete Draft to QA.	Keep ID and values; set Pending QA Review.
FRS-002.01URS-002 · OQ-003	Prevent Initiator approval or closure.	Deny all requests, including direct ones; leave record unchanged.
FRS-002.02URS-002 · OQ-004	Require QA electronic approval for closure.	Cancelled/failed: pending; approved: Closed.
FRS-003.01URS-003 · OQ-005	Audit edits to Title, Event Date and Description.	Keep user, time, field, old/new values, reason and history.
FRS-003.02URS-003 · OQ-004	Bind QA signature to its deviation.	Show signer name, time and meaning in record/export; prevent relinking.

Illustrative excerpt, not a complete specification; other controls depend on risk.

Map URS to FRS to OQ without losing coverage

User requirement	Linked functional requirements	Planned tests
URS-001	FRS-001.01, FRS-001.02	OQ-001, OQ-002
URS-002	FRS-002.01, FRS-002.02	OQ-003, OQ-004
URS-003	FRS-003.01, FRS-003.02	OQ-005, OQ-004

OQ-004 is linked to two requirements because it must check both closure and signature information. An ID link is only planned coverage; execution results and evidence references belong in the traceability record. See GoVal's requirements traceability matrix guide for the broader RTM approach.

Two OQ test cases built from the FRS

OQ-001: Reject an incomplete deviation

Run: As Initiator, use Draft DEV-T-001 with Title "Label discrepancy", Event Date "15 Oct 2026" and Description "Issue noticed during line setup". Attempt submission with each required field blank in turn.

Pass / evidence: Every attempt names the missing field, blocks submission and preserves entered values and Draft status. Capture each rejection and status. FRS: FRS-001.01.

OQ-004: QA signature and closure

Run: QA_TEST_01 (QA Reviewer) opens pending DEV-T-002. Cancel approval, then complete the configured electronic signature for "Approval". Check record, export and signature linkage.

Pass / evidence: Cancellation leaves the record pending; approval sets Closed. Record and export show signer name, date/time and meaning. Retain status, signature and linkage-test evidence; export alone does not prove secure linking. FRS: FRS-002.02, FRS-003.02.

For applicable electronic signatures, 21 CFR 11.50 addresses signature details and 11.70 addresses record linkage. These tests do not establish full Part 11 compliance.

Three FRS mistakes that surface during testing

Using a compliance claim as a requirement. "The system is Part 11 compliant" provides no testable response. Specify the relevant behavior and its acceptance criteria; assess applicability separately.
Writing only the successful path. The fact that QA can approve does not prove that an Initiator cannot. Include rejected actions and boundary conditions where the risk warrants them.
Updating the FRS but not its tests. A changed closure rule can invalidate earlier evidence. Reassess the linked URS, risks, OQ steps and traceability before reusing test results.

Frequently Asked Questions

Is an FRS mandatory for pharmaceutical computer system validation?

Not as a separate document in every case. EU GMP Annex 15 describes a URS and/or functional specification. A company's procedures may require a standalone FRS, but the regulatory question is whether required functions are adequately defined, traceable and verified under the approved validation approach.

What is the difference between URS and FRS in pharma CSV?

A URS states the user need, such as QA approval before deviation closure. An FRS defines the behavior that delivers it: who may approve, what must be checked, when the status changes and what the application records. The two may be separate or combined, depending on the documentation approach.

How do you write measurable FRS acceptance criteria?

Name the starting condition, action and observable result. Instead of "the system prevents incomplete records," identify the mandatory fields and state that submission is rejected, a field-specific message appears and the status remains Draft. A tester should be able to record pass or fail without interpretation.

Can one URS map to multiple FRS requirements and OQ tests?

Yes. One user need often implies several system behaviors. QA-controlled closure, for example, needs a permission rule, an approval action and a status change. Each behavior should have appropriate verification. One OQ test can cover multiple requirements when its steps and expected results explicitly assess each one.

Does every functional requirement need its own OQ test?

No. The validation plan should allocate verification using intended use, risk and suitable evidence. One OQ test may verify several related requirements; some may be evaluated in another lifecycle activity. The important point is justified coverage, traceable results and an explanation of any requirement not tested directly in OQ.

Keep requirements and test evidence connected

Explore how GoVal supports validation requirements, execution and traceability in one workflow.

Contact GoVal