設計仕様書の書き方


<連載 全12回> CSV実践講座(第5回)

CSV実践について研究するページです。

*万が一文中に解釈の間違い等がありましても、当社では責任をとりかねます。
 本文書の改訂は予告なく行われることがあります。

設計仕様書の書き方

1. はじめに

ユーザ要求仕様書(以下、URS)で記載された要求事項は、機能仕様書(以下、FS)により具体的な機能として検討され、ユーザとデベロッパー(開発担当者:社内の情報システム部門やベンダー)の間で合意がなされる。この合意に基づいてデベロッパーは設計仕様書(以下、DS)の執筆を行う。

このように「要求」が「仕様」へと引き継がれる。「要求」と「仕様」は明確に区別されなければならない。
また「要求」に「仕様」を合わせるのであって、けっして「仕様」に「要求」を合わせるようなことがあってはならない。
「要求」と「仕様」が合致していることを、設計レビュによって確認する必要がある。この設計レビュのことをDesign QualificationDQ)と呼ぶ。
テストフェーズにおいて「要求」は PQにより検証される。また「仕様」はIQおよびOQによって検証されることになる。

2. 設計仕様書とは

デベロッパーは、承認されたFSをもとにDSを作成する。
DSには、システムの開発や、その後のメンテナンスを可能にするための十分な詳細情報を記載する。
下記に項目の例を示す。

  1. 設計がどのように要求仕様に対応しているかを説明する
  2. ハードウェアとインフラストラクチャの設計
    コンピュータシステムがどのように構成されているか(ソフトウェアハードウェア、必要に応じてネットワーク)を定義する。また必要に応じてバックアップ構成や拡張性を定義する。
  3. ソフトウェア設計
    パッケージを利用するのか、注文開発を行うのか、またそれらの組合せ(いわゆるカスタマイズ)なのかを定義する。
    またソフトウェアが、どのハードウェア上でどのように実働するかを定義する。
  4. 一般的な操作上の設計を定義する
    画面設計、帳票設計、ユーザインターフェース設計など。
  5. データモデルを定義する
    データの種類、データベース設計など。
  6. コンポーネントモジュールとそれらの関係を特定する
    ライブラリー等を利用するなど。
3. 設計仕様書の内容

DSには、下記の内容を含めなければならない。

  1. 目的
  2. イントロダクション
    コンピュータシステムの目的および得られる事項の簡単な記述をする。
  3. 用語の定義
    該当コンピュータシステムに関連する技術用語、頭文字、略語を定義する。
  4. コンピュータシステム説明・概要
    コンピュータシステムを説明し、十分に詳細まで記載することで、主要な機能が明確に理解される。
    その他のコンピュータシステムとの関係の概略の説明を記載する。
  5. 設計の全般的な説明
    コンピュータシステムの設計方法、構築方法を記載する。
  6. コンピュータシステム構成
    総合的なコンピュータシステム構成の簡単な説明を記載する。
  7. 開発ツール及び関係するアプリケーションユーティリティ
    開発ツール、データベース、言語や、製品名、外部業者名、バージョン番号を記載する。
  8. プラットフォーム構成及び環境
    OS、ネットワークなど
  9. ソフトウェア構成
    ソフトウェアのモジュールとモジュール間の関係について図示し、説明を記載する。
    例:データフロー図、構造チャート
  10. ユーザインターフェース
    ユーザインターフェースの概要を記述する。どのようにユーザコンピュータシステムのユーザインターフェースを利用するかを記載する。
    メニューの構成及び操作順序を記載する。
  11. システムオペレーション仕様
    機能仕様書における下記のそれぞれの項目に関連する要求事項の実現方法を記載する。
    11-1 他のコンピュータシステムへのインターフェース
    11-2 アクセスコントロール要求及びセキュリティ要求
    11-3 パフォーマンス
    11-4 有効性
    11-5 バックアップ・リカバリ
    11-6 障害回復
    11-7 保守の容易性
    11-8 メモリマネージメント
    11-9 並行性/スレッド
    11-10 移植可能性(複数のプラットフォームで稼動させる場合)
    11-11 ネットワーキング
             どのようにネットワーク上のクライアントから、ユーザアクセスを行うのかを記載する。
    11-12 ローカル化
             複数のロケーションで動くのか、どのようにロケーションごとの違いを管理するのかを記載する。
  12. データ
    使用するデータベースまたは、その他のストレージを記載する。
    データベースの各インスタンスを定義し、目的(例:開発、トレーニング、バリデーション、プロダクション)を記載する。
    対象となる電子記録に関しては、21 CFR Part1121 CFR Part11および日本版ER/ES指針を十分に検討すること。
4. 設計の確からしさの検証(DQ報告書

URSに対して、設計の妥当性を評価・検証することをDQDesign Qualification)と呼ぶ。すなわち、設計を適切にレビュし、DQ報告書にその結果を文書化するのである。

DQは、体系的な調査を行い、結果を理解しやすく文書化し、設計要件の妥当性や、その要件を満たす設計の有用性を評価し、問題を特定するものである。ハードウェアを購入し、ソフトウェアのコーディングを行うなど、コストをかける前に問題を解決しておくことは非常に有益である。

FDAは「General Principles of Software Validation; Final Guidance for Industry and FDA Staff」(2002.1.11)において、この設計のレビュを重要視している。設計がユーザ要求に一致していることが重要であるとしているのである。つまりユーザが利用する環境、業務に適応した設計になっていなければ、障害が発生し、しいては事故につながる懸念がある。
一般にDQは、トレーサビリティマトリックスを利用して行う。またDQは、机上で PQを実施することに相当する。すなわち実稼動を想定し、正しくユーザ業務が当該システムで遂行できるかどうかを、事前に検証するのである。つまり「仕様は満たしている」が「使えない」システムの作成を事前に防止する必要があるのである。
したがって、DQを実施するためには、業務の知識はもとより、コンピュータシステムの性能、必要となる記憶容量、ネットワークの設計にいたるまで、幅広い経験が必要となる。
ひらたく言えばDQでは、「設計」が「要求」を満たしているかどうかを検証する。何故ならば「仕様」は「要求」を完全に具現化したものでなければならないからである。

DQ報告書は、承認されたDSに対して作成する。
通常、製薬会社のユーザ部門はDSの執筆に関与することはない。またそのレビュに関しても、専門文書であることから困難であろう。しかしながら、何らかのかたちで設計をレビュしなかった場合、開発後、テストフェーズで不具合が発見される可能性があり、投資が無駄になるリスクがある。ユーザ部門では、最低限トレーサビリティマトリックスを用いて、URS→FS→DSがもれなく継承されていることを検証する必要がある。

5. DQ報告書の内容

DQ報告書には、下記の内容を含めなければならない。

  1. 目的
  2. イントロダクション
    コンピュータシステムの目的および得られる事項の簡単な記述をする。
  3. 用語の定義
    該当コンピュータシステムに関連する技術用語、頭文字、略語を定義する。
  4. 要求事項および設計文書
    本セクションでは、デザインレビュにおいてレビュされたすべての要求事項、設計仕様書のバージョンを記載すること。
    またコンフィグレーションベースラインを明記すること。
  5. デザインレビュ結果
    5-1 欠陥/異常の結果
           認識されたあらゆる欠陥/異常などのデザインレビュ実施作業の結果を記述する。
    5-2 欠陥/異常の解決
           あらゆる認識された欠陥/異常の解決方法またはフォローアップの方法を記述する。
    5-3 トレーサビリティマトリックス
           トレーサビリティマトリックスが作成されていれば、ここで特定すること。
           以下のチェックはデザインレビュ実施作業中に実施され、DQ報告書に文書化しなければならない。
    5-4 要求事項
           設計仕様書で記述された要求事項。
    5-5 トレーサビリティ
           設計仕様書中の要求事項へのトレーサビリティは、バリデーションマスタープランに定義された
           トレーサビリティ方法を使って実行していること。
    5-6 整合性
           設計仕様書の整合性が完全であることを記述する。
    5-7 デザインレビュの終了
           すべての設計仕様書のデザインレビュが終了していること。
    5-8 パッケージコンフィグレーション
           パッケージコンフィグレーションの設計が完成していること。
    5-9 コンフィグレーションベースライン
           設計要素のすべてのコンフィグレーションベースラインを採用していること。
6. おわりに

GAMPガイドでは、DQは「設計適格性評価」と訳されている。またDQという用語は最近導入されたものであると紹介されている。
筆者がコンサルテーションを実施するなかで、設計仕様書の書き方やDQ報告書にの書き方については、多く質問を受けるところである。
本文中にも述べたとおり、これらの文書は専門家でなければ執筆が困難なものである。しかしながら、稼動直前になって「こんなはずじゃなかった。」ということがないように、十分に検証しておくことは重要である。
次回は、「テスト仕様書の書き方」の書き方について解説する。

参考