システムに対する詳細要件を「Function Specification」（機能仕様書、FS）により文書化しなければならない。 FSは、ユーザ要求仕様書に記載した要求事項を コンピュータシステム設計に対する要求事項として十分なレベルまで定義するものであり、 ユーザとデベロッパとの機能要件に関する合意書である。
システムが「Risk Assessment Report」によってValidationが要求されると判断された場合、 全ての規制要件をFSで定義しなければならない。
新システムに既成パッケージを利用する場合、FSにおいてユーザの要求する機能要件が、 パッケージの機能により実現できるもの、コンフィグレーション（パラメータの設定）により 実現するもの、カスタマイズ（または外部開発）により実現するものの別を記載しなければならない。 FSは、ユーザとデベロッパー（システムを開発する社内外のIT担当部門）との機能要件に関する合意書である。 GAMPによると、FSは外部業者が作成するのが普通であるとしているが筆者はそうは考えない。
システム開発に関する見積りは、FSが承認されてはじめて作成が出来る。 何故ならばカスタマイズの程度、実現しない要求などがFSによって決定されるからである。
FSの承認後、URSとFSの「Traceability Matrix」を作成することによって、 ユーザの要求事項がもれなくFSにおいて定義されたことを保証しなければならない。 また「Traceability Matrix」をもちいて、「Functional
Risk Assessment」（機能リスク調査）を実施すること。
「Functional Risk Assessment」は、要求される各機能が正常に動作しない場合や、導入が実現できない場合の業務に対するインパクトの程度（High、Middle、Low）やリスクの記述を行う。 ここで定義されたインパクトやリスクの程度に応じて、優先順位をつけてOQケースおよびPQ テストのシナリオを作成することになる。 程度がHighとされた機能に関しては、最優先でOQを実施することになり、程度がHighとされた業務プロセスに関しては、 最優先でPQを実施することになる。 FSにおいて、コンフィグレーション（パラメータの設定）により要求機能を実現すると決定した機能に関しては、 別途「Package Configuration」においてその設定値を記載すること。 コンフィグレーションが、CASE ールなどパッケージそのもののGUI等により 行われるものに関しては、その設定（値）の所在を明らかにしておくこと。 また画面のハードコピーを添付することを推奨する。 後続のOQでは、コンフィグレーションにより設定された機能は、設定値の読み合わせのみとしてかまわない。
