FSFunctional Specification

The Functional Specification describes the system's functional behaviour from the user's perspective. For every URS line item it specifies the visible behaviour — what screens exist, what fields they contain, what validations fire, what calculations run, what records are written, what signatures are required, what reports are generated, what integrations are invoked, what permissions apply. It deliberately stops short of describing internal implementation: the database schema, indexes, code modules, infrastructure and APIs all belong to the Design Specification (DS).

GAMP 5's V-model places FS between URS (the business-side requirements) and DS (the supplier's technical design). The right arm of the V mirrors this: OQ test scripts are written to verify FS behaviour, just as PQ is written to verify URS satisfaction in the live process. Each test on the right is traceable back to a spec on the left via the traceability matrix — and that is the artefact every Annex 11 / 21 CFR Part 11 inspector navigates the system through.

• URS → FS — "the system shall record every weighing event" becomes "the Weigh screen captures lot, vessel, gross, tare, net, target, tolerance, balance ID, operator, timestamp; commits to weighings table on signature".
• FS → DS — "commits to weighings table on signature" becomes the schema definition, the foreign-key constraints, the audit-trail trigger, and the RLS policy.
• DS → Code/Config — the actual implementation, ready for IQ.

1. Document control header — version, status, supersedes, author, reviewer, approver, effective date.
2. Scope statement — modules in scope, modules explicitly excluded, configurations covered.
3. System overview — block diagram of major functions and their data flow.
4. Functional descriptions — one numbered section per functional area (master data, workflow, calculations, integrations, reporting, administration, security).
5. Screen / interaction specifications — wireframes or screen lists with fields, types, validations, default values, error messages.
6. Business-rule catalogue — calculations, decision tables, state transitions, expiry rules, alarm thresholds.
7. Electronic-record / e-signature behaviour — what gets written, who can sign, what reason codes apply, how challenge-on-print is handled (21 CFR 11.10 / 11.50 / 11.70 / 11.200).
8. Audit-trail behaviour — what fields are audited, what before/after captured, retention.
9. Integration interfaces — message types (e.g. EDI 856, IDoc, REST), payload structure, frequency, failure handling.
10. Reports — list of regulated reports, the data they include, the snapshot/live behaviour.
11. Security and roles — role catalogue with permissions per function.
12. Performance / non-functional expectations — throughput, response time, concurrency.
13. Open issues and assumptions.
14. Traceability matrix — URS-ID → FS-section.

Under GAMP 5 Category 4 (configured products like an MES, LIMS or eQMS — V5 sits here) the FS is owned by the supplier. The supplier publishes a baseline FS that describes the product's out-of-the-box behaviour; the customer layers a configuration spec on top that captures the deltas — industry profile choices, signature workflows enabled, integration endpoints, label templates, report headers.

For Category 5 bespoke development, the FS is fully customer-owned (often co-authored with the developer). For Category 3 non-configured products, a supplier datasheet plus a one-page customer addendum is usually enough. The right approach is set by the GAMP 5 risk classification, not by tradition.

• Atomic — one behaviour per line. "The system shall calculate and display the corrected weight and alert the operator if out of tolerance" is three lines, not one.
• Testable — every line must be expressible as a Pass/Fail OQ check. "User-friendly screen" is not testable; "Field accepts 1–999.999 kg, rejects negatives with message E-014" is.
• Implementation-neutral — describe behaviour, not data structures. "Stored in the audit_logs table" belongs in DS.
• Cross-referenced — every line traces back to a URS ID.
• Versioned — change control covers every revision; rollback to any historical version must be possible.
• Reviewed by users, not only by engineers — the people who will use the system must have signed off on the workflow before code is cut.

An FS for any GMP-relevant system must explicitly describe electronic-record and electronic-signature behaviour. Inspectors expect to see:

• Which records are designated regulated records and therefore subject to Part 11.
• What audit-trail captures: who, what, when, why, before/after, with an unforgeable timestamp.
• Signature manifestation: name + date/time + meaning of the signature ("performed by", "reviewed by") on every record view and printout.
• Two-person signature flows where regulations require them (formula approval, batch release, deviation closure).
• How signatures are bound to records (signature cannot be transplanted to another record).
• Open-system controls where applicable (encryption, digital signatures, integrity verification).

• FS describes the database schema ("the weighings table shall have columns…") — that's DS.
• FS line written as "system shall do X — see code module Y" — implementation leakage.
• Calculations described as "as per Excel master" instead of being written out — auditors can't follow the spreadsheet.
• No version control on the FS — reviewers don't know which version they signed.
• FS authored by the developer alone — business-process gaps are baked in.
• FS does not describe audit-trail / signature behaviour — Annex 11 §9 finding.