要件定義書のテンプレートと例文をご紹介します。
要件定義書とは？
要件定義書はシステム開発を行う際に、クライアント（システム利用者）の要件をドキュメント化した文書になります。システムには詳しくない依頼者であっても、その内容を読むことで、期待したシステムが開発されることを確認できる必要があります。また、開発側ではこの後のフェーズである基本設計、詳細設計などを行う上でのベースとして、開発メンバーが情報を共有できることが期待されます。
要件定義書の目的
要件定義書はシステム開発の依頼者、開発者の間で齟齬をなくし、情報が適切に共有されていることを確認するために作成されます。現状を確認できる内容に加えて、システムに期待される効果（要件）についても記載されます。また、予算やスケジュールも明記することで、開発フェーズにおいて発生した課題に対して、予算と日程のいずれを優先するかなどを検討する際にも利用できます。
要件定義書はシステム開発側が作成する文書になります。一般的にはRFP（提案依頼書）とヒアリングに基づいて作成されます。また、必要に応じて現地調査を含みます。
WEB上で簡単に要件定義書の作成・管理を行えるツール「NotePM」
要件定義書の書き方
目的
本文書が何のシステム開発に対して作成されている文書なのかを明記します。また、既存システムなのか、新規開発であるかも明記します。既存システムの場合は第○次開発などと番号付けして管理されます。
概要
システム開発の概要を記述します。詳細は後述されますので、ここでは端的に記しておくのが良いでしょう。
システム方式・構成
アーキテクチャや全体のシステム構成図を記します。テキスト、またはネットワーク図などで記します。あまり詳細に書いても基本設計の時点で変更されることが多いので、あくまでも概要レベルに止めておくのが良いでしょう。
用語定義
文書内で使われている用語をまとめます。また、社内用語や業界用語についても記します。これらの認識がクライアントと開発側でずれていると、後で大きな問題につながる可能性があります。
業務要件
RFPやヒアリング、現地調査を通じて分かった業務要件と、そのシステム化すべきポイントをまとめて記載します。
現状のフロー
現状のフローを記述します。簡易的なものであればフローチャートで記述できます。複雑なものであればビジネスプロセスモデリング表記法、産能大式フローチャートなどを用いて記述します。
構築後のフロー
こちらはシステム構築後のフローです。こちらも現状のフローと同じく、簡易的なものであればフローチャートで良いでしょう。複雑なものであればビジネスプロセスモデリング表記法、産能大式フローチャートなどを用いて記述します。
利用者一覧
現状、および構築後における利用者（ステークホルダー）を一覧化します。この人たちはシステムに何らかの形で関わることになりますので、その変更内容を認識してもらう必要があります。また、システム構築後には教育なども必要でしょう。ここに漏れた人たちがいる場合、システム運用開始後にトラブルへつながる可能性があります。
規模
システムの規模を明記します。一般的に人月で記述しますが、さらにサーバーやネットワーク周りにおける変更が見込まれる場合には、その規模も記述しておきます。
機能要件
ここからは機能要件を記述します。機能要件はクライアントから求められる機能になります。
画面
新たに作成、変更される画面をリストアップします。
権限
機能における必要な権限設定について一覧化します。
帳票
システムから新たに出力される帳票、修正が加わる帳票をリストアップします。
情報・データ
システムが新たに作成するデータ、変更される既存のデータをリストアップします。
外部インタフェース
システムが外部サービスへ接続する、または外部サービスへのインタフェースを公開する場合に明記します。これらは別途セキュリティ監査の対象になり得るでしょう。
データフロー
業務フローではなく、データがどのように遷移するのかを明記します。これはテーブルデータで記述したり、フローチャートを用いて記述されます。
非機能要件
非機能要件とはプロジェクトに関係するものの、システム開発以外の要件になります。
互換性
プロジェクトが既存システムの更新である場合、旧システムとの互換性について明記します。もし互換性がない場合には、データ移行や多重運用することについて明記が必要です。
スケジュール
プロジェクト全体におけるスケジュールを記述します。開発フェーズはもちろん、テストや納品、運用教育やデータ移行などプロジェクトが円滑に完了するのに必要な項目を洗い出した上でスケジュールを決めます。
予算
プロジェクト全体における予算を記述します。開発はもちろん、サーバーなどの固定費用、保守運用に関わる費用も明記します。
要件定義書サンプル例
##目的
本ドキュメントは売り上げ管理と経理システムの自動連携を実現させるシステム開発に関する要件定義書になります。
##概要
###システム方式・構成
システム構成は次の通りです。なお、新たなハードウェア導入は予定していません。
- アプリケーションサーバー
自動連携設定を行う画面、連携結果を表示する画面を提供します。- データベースサーバー
既存の社内サーバーです。- 経理システム
現在経理部で使われている経理システムおよび専用のワークステーションです。###用語定義
- 経理システム
社内で用いている経理システム○○のことを指します。- 社内システム
社内で用いられている共通システムを指します。- バッチ
定期的に自動実行されるシステムを指します。- ログ
ここではバッチシステムによって出力される処理結果を指します。##業務要件
###現状のフロー
現状のフローは次のようになっています。
- 経理担当者がシステム開発部門に売り上げ出力を依頼
- システム開発部門が売り上げデータをCSV出力して、メールで送信
- 経理担当者がCSVをExcelで開いて編集
- 経理担当者が経理システムへログイン
- 経理システムのインポート機能でCSVデータを取り込み
###構築後のフロー
システム構築後、フローは次のようになります。
- 経理担当者が専用画面にて自動取り込みに関して設定
- バッチシステムが自動処理後、経理担当者にメールで完了を通知
- 経理担当者が経理システムへログイン
- 取り込み未確定データを確認後、経理システムにて確定処理を実行
###利用者一覧
- 経理担当者
###規模
2人月（エンジニア1人×2）の予定です。
##機能要件
###画面
- バッチ処理設定画面
バッチの有効または無効、頻度、処理完了後に送信するメールアドレスを設定する画面です。- バッチ処理結果一覧画面
バッチ処理の履歴一覧を確認する画面です。- バッチ処理結果詳細画面
ある時に行われたバッチ処理の結果を確認する画面です。###権限
- バッチ処理設定は経理担当者のみ可能とします。
- バッチ処理結果は経理担当者および経理システム担当者のみ閲覧可能とします。
###帳票
本システムでは以下のメールおよび帳票が出力されます。
- バッチ処理結果メール
- バッチ処理結果詳細レポート
###情報・データ
本システムでは以下のデータが作成されます。
- 経理システムに取り込める形での売り上げデータのエクスポートデータ
CSVデータで一時出力されます。処理後、削除されます。- 経理システムへのインポートログデータ
経理システムへのインポート処理に関する詳細なログデータがデータベースに保存されます。- 経理システムへの未確定インポートデータ
経理システムへは未確定データとしてインポートされます。その内容を経理担当者が確認後、取り込み処理を確定します。###外部インタフェース
- メール
経理担当者へのバッチ処理完了を通知します。- Slack
バッチ処理が失敗した時にシステム管理者グループへ通知されます。- CSV処理
経理システムへ接続してAPIを通じてインポート処理を実行します。###データフロー
本システムのデータ処理は次のようになります。
- バッチシステムが売り上げマスターより対象となるデータを抽出
- バッチシステムが抽出したデータを経理システムへ取り込めるように加工
- バッチシステムが経理システムへ接続
- バッチシステムが経理システムへデータを送出
- バッチシステムがログをログテーブルに記述
- バッチシステムが経理担当者へバッチ処理完了のメールを送信
- バッチシステムが対象の売り上げマスターデータへインポート完了のフラグ立て
##非機能要件
###互換性
過去システムとの互換性は維持されます。なお経理システムのバージョンは12.0.0を対象としています。マイナーアップデートは問題ないと思われますが、メジャーアップデートのタイミングでAPIが変更される可能性はあります。
###スケジュール
| 日付 | 内容 |
| 2022年04月10日まで | 要件確認 |
| 2022年04月20日まで | 開発 |
| 2022年04月30日まで | テスト |
| 2022年05月10日まで | テスト結果に伴う調整 |
| 2022年05月20日まで | 再度テスト |
| 2022年05月31日まで | 開発完了およびデプロイ |###予算
100万円