「要件定義書」とは、要件定義での決定事項をまとめ上げたシステム仕様書です。パソコンソフトに添付されているマニュアル本と同じような位置づけで、システムハウスが持ち込んだ書式に沿って記述・構成されます。

作成はシステムハウスが行ない、納品物件として検収の対象となります。検収が済めば、システムはユーザーに引き渡され、以降、自分達の責務で運用することになります。

いつまでも開発メンバーが近くにいて、サポートを継続してくれるとは限りません。システムの構成が誰でも理解できるよう、（仮にサポート契約を結んだとしても）引継ぎ資料としての役割も与えなければなりません。使える要件定義書として、最低限必要と思える情報を記しておきます。参考まで。

要件定義書の最小構成

概要

システム導入の目的

時間の経過とともに本来の目的がぼやけ、習慣化されたオペレーションだけが後世に残されていくなんて寂しいですよね？要件定義書を開けば最初に目に触れ、システムの目的を認識した上で、個々人の役割を意識付けできるようにします。

適用（影響）範囲

システム化によって、どの業務（組織）に影響を及ぼすのか記載します。例えば、個人レベルでの作業内容変更という小さなものから、組織変更を伴う大規模なものもあるでしょう。システムが適用される範囲を、新旧の業務フローや組織図などを作成し、分かりやすく対比できるようにします。

体制図

ユーザー及びシステムハウスの開発担当者を一覧化しておきましょう。システムに疑問を抱いた後人が、開発メンバーに質問することはよくあることです。文書に残っていない生の声は、疑問を解消する上でのヒントが多分に含まれています。

補記

例えば除外された要求の経緯や、二次開発の有無、ペンディング事項など、補足情報があれば明記しておきます。

資産管理

ハードウェア管理

サーバー、パソコン、プリンター、ネットワーク機器ほか、今回投入した資産を一覧化しておきます。型番、ＯＳ・ファームウェアのバージョン、使用（管理）者などを管理します。また償却資産として、経理部門への情報提供も考慮します。

外部設計書

データフローダイアグラム（データフロー図）

データの「流れ」と「蓄積」に注視し、システムの骨格を明らかにします。システム設計の第一歩ですね。

ネットワーク構成図

サーバーやパソコン、プリンター、ネットワーク機器をどのように繋ぐのか、分かりやすく図解にしてもらいましょう。特に、施設やフロアを跨いで敷設する場合、有線か無線か、専用回線かＶＰＮかなどの情報は、詳細な記載を求めましょう。

ユーザーインターフェース設計書

全ての画面・帳票のデザインイメージと、出力内容（項目説明書）の定義書です。画面遷移図やアクセス権、帳票の出力日時や保管要領などの情報も必須です。要件定義書のコアコンテンツですね。

データチェック仕様書

エラーコードを目次として、データチェック要領を記載します。有効値の設定、関連項目、エラー修正方法まで、エラーコード単位に詳細に記述します。データチェックはシステムの精度を高める重要な機能です。全ての入力項目を対象として、「ここまでやる？」と思えるところまで徹底しましょう。

データベース定義書

データベースの構造設計書と依存関係を図解したデータベースストラクチャを表紙に、データベース個々の保有項目とその項目内容を定義したものです。他データベースとの関連性や履歴を含めたデータの持ち方などの情報も付加しておきましょう。

システム間インターフェース設計書

他システムとの間でデータ受渡がある場合、データレイアウトや項目内容、タイミング、運用上の注意事項など明確にしておきます。上記データフローダイアグラムと重なる部分もありますが、トラブルを起こしてしまうと組織外へも波及します。細心の注意が必要ですね。

内部設計書

＊厳密にいえば要件定義書には含まれないと思いますが、内部設計書の役割を知らしめるために記載しておくことにしました。

ライブラリー一覧

プログラムソースやバッチファイル（スクリプト、ＪＣＬ）、コンパイラー等々、システムは様々なファイル群で構成されています。各ファイルが格納されているフォルダー（ディレクトリ）を一覧化し詳細を記します。本番環境で使用するか否かの色分け、ファイルへのアクセス権など、運用関連情報も載せておきましょう。

プログラム仕様書

プログラマーは、渡されたプログラム（モジュール、クラス）仕様書をもとにコーディングに入ります。内容は機能説明（実装指示）をメインに、ファイル（データベースや一般ファイルなど）へのアクセス有無、他プログラムとの連携（パラメータ設定要領他）などが日常語で書かれています。プログラム言語が分からなくても、読めば誰でも理解できるよう、記述することが望まれます。日常語をプログラム言語へ読み替え実装するのはプログラマーの仕事です。

ファイル設計書

データベースを含めたマスターファイルや、受注データなどのトランザクションファイル以外にも、システム内部では多種多様なファイルを保有しています。例えば、バッチ処理でプログラムとプログラムを結びつける中間ファイル、画面情報を保存しておくファイルなどが挙げられます。システム内で使われる全てのファイルについて、データレイアウトや項目説明書などを定義します。

ジョブフロー図

バッチ処理の流れをフローチャートとして記載します。処理のタイミング（日次や月次など）、他ジョブとの依存関係などもあわせて記載します。

保守管理手順書

本番／テスト環境の切り替え方法

いきなり本番環境のソースに手を加えることは通常ありえません。テスト環境で十分な検証を行なってから本番環境へ反映させるなど、運用ルールを明記し、手順を徹底させましょう。

システム、データのバックアップ＆リカバリー方法

ハードウェアの故障やプログラムのバグ、運用ミスなどにより、システムがダメージを受けた場合を想定し、データ及びファイル群を定期的にバックアップします。どんな状態からでも元に戻せるよう、無駄がなく、漏れのないバックアップ要領と、容易で確実なリカバリー方法を熟慮・設計します。

その他

ユーザーがオペレーションに関わる処理は全て、手順書としてまとめておきましょう。例えば「営業の締め日は、システム日付ではなくユーザーの意思で切り替えたい」など。人が介入して制御する仕様は少なからずありますので、ユーザーが直接運用に関わる場合の仕方、注意事項などは、運用マニュアルとして整備しておきます。