要件定義の目的

要件定義とは、以下の点を整理し、矛盾がない事を確認し、利用者とシステム開発者が同じ認識を持つ事です。

　　①．システム化の目的
　　②．対象業務
　　③．人、物、時間、場所を明記した業務の流れ
　　④．機能毎の要件
　　⑤．業務が分岐する場合の条件
　　⑥．利用制限
　　⑦．外部設計のインプットとなるだけの項目の定義
　　⑧．シナリオテスト作成のインプット
(2011.07.16追記)
(2011.03.06)

要件定義書の有効期間

要件定義書の有効期間について、様々な考え方があると思いますが、私はシステムが存在している期間は有効であるべきと考えます。 それは、要件定義書のコンテンツが要件定義書にしかないからです。外部設計書、内部設計書を作成してしまえば、システムが完成してしまえば 必要ないものではありません。外部設計書を作成中に機能数が変更になる場合でも、システムが稼働してからでも、要件定義書のコンテンツが 変更になれば、要件定義書を更新すべきです。
(2011.07.16)

要件定義書のコンテンツ

No. サブNo. コンテンツ名 内容
1 プロジェクト概要
1 期待効果 システム化の目的。
プロジェクト発足が経営改革、業務改善等の理由によるものである事を説明し、実現可能なゴールを決める。
2 方針 プロジェクトの進め方。
ウォーターフォール・モデル等の開発全体の進め方や、要件定義を進めていく(きた)中での、予算や期間等への考慮ポイントや、外部設計 以降の考慮ポイント等を記述する。
また、前提とする事項や、重要なリスクに対する考え方についても記述する。
2 スコープ
1 スコープ内 大まかな業務名称と各業務の概要について記述する。
2 スコープ外 スコープ内の記述範囲内で、スコープから外れる対象を記述する。
3 システム利用環境
1 ハードウェア環境 当システムを含む、関連するシステムを稼働させる上で必要なハードウェア構成を記述する。一般的には、図で表現する事が多い。
2 ソフトウェア環境 当システムを稼働させる為のOS等の条件や、利用するソフトウェアを記述する。
また、当システムだけでなく、関連するシステムのソフトウェア環境についても参考として記述する場合もある。
フリーウェア等の利用会社が認めないソフトウェアはクライアント機に導入しない等の制限も、記述すると良い。
4 システム概要図 サブシステムの相関図、業務相関図、外部システムとの相関図を表現する。
マスタデータ、会計データ、在庫データ等、システムが重要とするデータを中心とした図にすると効果的である。
5 重要仕様 システムに登場する重要な業務や項目について、以降に記述する業務フローや機能一覧では表現しきれないものを記述する。
説明文だけでなく、マトリックス図、階層図、状態遷移図などで記述すると、分析結果を適切に表現できる為、積極的に利用すべきである。

マトリックス図：
・条件により動作が異なる場合に、条件に関係する項目と値と動作を2次元の表にまとめたもの。
・横軸に条件となる項目を、縦軸に動作を記述し該当するパターンの組合せを表現するのが一般的であるが、横軸に条件と動作を並べる形式 や、動作は表の中身に記述するといった形式も、表現したい内容に応じて選定する。

階層図：
・項目間またはマスタ間、組織間等で、階層関係にあるものを表現する。

状態遷移図：
・項目がいくつかの状態に変化する場合、値、条件、値の遷移を表現する。
6 対象利用者 当システムを利用する利用者を、部署名や役割名で記述する。個人名で記述する事は避ける。
システム内容によっては、業務別担当者別のマトリックス等で表現すると分かりやすいです。
7 業務フロー 各業務のシナリオとフローを記述する。業務が複雑な場合は、ドリルダウンで表現する。
業務数が多い場合は、各業務に業務番号を付番し、業務フロー一覧を作成すると読み易くなる。
8 機能一覧 分析段階で必要と判断した、入力機能、出力機能、更新機能を一覧化する。
各機能の、入力・出力・更新の区分、インプット、アウトプット、利用者、利用タイミング、機能内容を記載する。
機能数が多い場合は、機能番号を記載すると、これ以降に作成するドキュメントを整理し易くなる。
9 タイムチャート 各業務を横断した、１日または１ヶ月等のスケジュールが把握できるもの。
記述内容が多い場合は、業務フローに記載の業務番号を記載すると、分かりやすい。
10 制約
1 セキュリティ制約 プログラム起動制約、プログラム起動後の機能制約を記述する。
2 運用制約 システム化しない箇所で、運用ルールを徹底してもらう事があれば記述する。
また、フリーウェア等の利用会社が認めないソフトウェアはクライアント機に導入しない等のソフトウェア環境に記述した制限を、ここにも記述する事も 有効である。
11 想定データ量 システムで取り扱う主要データ(マスタやトランザクション)の保有期間、期間あたりの増加量、想定最大件数を記述する。
12 要求応答時間 照会や登録等の基本とするものを先頭に記述し、特別に時間が掛かる機能は個別に記述する。無理難題な要求は、要件定義の最中に、利用 者側と開発者側とで意見の調整をしておく。
13 用語集 プロジェクト外の人にも理解し易くする為に作成する。システムの引継ぎや、外部者のレビュー、システム開発の上流工程の担当者から下流担当者 への情報伝達等に利用できる。特に、システムの引継ぎは開発者側だけでなく、利用部門でも利用できる為、利用者側の用語だけでなく、システム に特化した用語に関しても、一般的でないものは積極的に記述すべきである。
14 補助　移行
1 方針 移行に関する作業を進める上で、利用者側や開発者側の協力体制を得る為に、方針を記述する。移行に関するスケジュール等を記述する のも効果的である。
2 範囲 移行対象範囲を記述する。また、各対象の準備担当者を、利用者側なのか開発者側なのかを明記する。
15 補助　画面・帳票レイアウト(ドラフト) 要件定義内で打合せした結果を記載する。外部設計のインプット情報。項目の配置位置より、項目があるか否かを重視する。

(2011.07.16)
(2011.03.06)