FS / FDS

The functional specification states what a system must do to satisfy the user requirements: functions, operating modes, alarms and interlocks, data handling, and the behaviour expected at each boundary. It sits between the requirement, which says what is needed and why, and the design specification, which says how it will be built. Its job is to be testable — a function written so that no test could fail it has not been specified.

Traceability is what makes the document useful rather than ceremonial. Each user requirement should reach one or more functions, and each function should reach a verification. Run backwards, the same trace exposes functions that satisfy no requirement, which are either scope nobody asked for or requirements nobody wrote down; both are worth finding before they are built.

In practice suppliers often write it, which is reasonable and creates a specific risk: a functional specification written from the supplier’s standard offering describes the product rather than the requirement. Reviewing it against the URS, rather than reading it on its own terms, is where that gap is caught.

• —States what the system must do; the design specification states how it will be built.
• —A function that no test could fail has not been specified.
• —Traced forward to verification and backward to the user requirement, in both directions.
• —Reverse tracing exposes unrequested scope and unwritten requirements.
• —Supplier-authored versions describe the standard product until reviewed against the URS.

ISPE GAMP 5 (2nd ed., 2022) specification hierarchy; EU GMP Annex 11 §4 for computerised systems.