千石君：それでは、今後の進め方について確認です。経営会議での計画変更案了承を前提に、「要件の合意」アクティビティに進みます。並行して「要件の記録」アクティビティも実施します。
製造部門代表：具体的に説明してください。
千石君：はい。次のタスクは、主に業務要件について要件定義の結果をまとめてステークホルダーにフィードバックし、全ステークホルダーの合意を取り付けることです。これまでも個々の項目については関係するステークホルダーに確認してきましたが、今回の目的は、項目間の関係などに見落としや矛盾がないか、全体を通して再確認することです。
製造部門代表：続けてください。
千石君：はい。みなさんは、あらかじめ定めた分担に従って、これまでにこのプロジェクト会議で議論して合意した内容と文書様式を、わが社の「システム開発標準」に照らして今一度確認してください。本日の会議で確定した部分は、早急に定義文書を更新してください。
この作業で重要なことは、各ステークホルダーからの要求に対し、採用したもののみならず、不採用としたものについても、その理由とともに記録しておくことです。この記録を再確認し、整理してください。
経営部門代表：不採用の要求も記録して整理するのか。それ、必要ないんじゃないですか？
千石君：いいえ。これらの記録は、ステークホルダー要求のベースラインとなり、構築するシステムのライフサイクルを通して維持されます。その間、たとえば変更要求や追加要求が生じた場合に、この記録に基づいて検討することになります。
販売部門代表：そうか。この記録があれば、今回涙を呑んで削減したわれわれの要求についても、その復活時の検討が効率的にできるんですね。
経営部門代表：なるほど。さすがシステム部門ですね。よく考えられている。
千石君：ありがとうございます。実は、これらのことはみんな、わが社の「システム開発標準」に規定されているんです。さらに、これらの記録は、ビジネスニーズとシステム構成要素をひも付ける、いわゆる“トレーサビリティ”の維持にも必要です。…実を言うと、僕もこのプロジェクトを手掛けるまで知りませんでした。
| 要件定義文書種別 | 分担部門 | |
| 各要求元 | システム | |
| ビジネスプロセス関連図 | ○ | △ |
| 業務機能構成表 | ○ | △ |
| ビジネスプロセスフロー（業務フロー） | ○ | △ |
| 画面／帳票レイアウト | △ | ○ |
| 業務処理定義書 | ○ | △ |
| 概念データモデル（ER図） | △ | ○ |
| エンティティ定義書／データ項目定義書 | △ | ○ |
| CRUD図 | △ | ○ |
| 統合テスト計画書 | ○ | ○ |
| システム移行計画書> | ○ | ○ |
| 運用・操作要件書 | ○ | ○ |
| 非機能要件書 | △ | ○ |
経営部門代表：よくわかりました。
千石君：次に、設計部門に渡す要件定義文書全体がまとまったら、最終の要件定義レビューを行います。このレビューでは、複数のシステム設計担当と運用担当にも加わってもらい、特にシステム要件まわりを中心に問題がないか確認します。
