この記事は、「架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）」の記事の一部です。
要件定義書の概要
要件定義書はプロジェクト関連ドキュメントの中で最も重要なドキュメントの１つです。
システムで実現したい各種要件（業務、機能、非機能等）を記述します。
本来、システム利用者（企業）が作成すべきものですが（要件は利用者しかわからないので）、慣例的に開発会社がヒアリングと確認を行いつつ作成するのが標準的になっています。
| 項目 | 内容 |
|---|---|
| 作成目的 | システムが対応すべき業務、有すべき機能・非機能を定義 |
| 記述すべき内容 | システムの目的、業務要件、機能要件、非機能要件、その他留意事項 |
| 作成タイミング | 要件定義 |
| 対象者 | プロジェクトメンバー全員（非技術者、技術者） |
| ファイル形式 | パワーポイント、Exce、Word等の組み合わせ |
| 備考 | 最近は（アジャイル開発が多いので）要件定義書をどちらかというと非技術者（意思決定層やクライアント）との意識合わせ資料と割り切って記述することが多いです |
一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。
サンプルダウンロード
サンプルのダウンロードはこちらから。
作成してみる
では作成していきましょう。
作成方針・ポイント
要件定義書はITプロジェクトにおいて最も重要なドキュメントといってもいいでしょう。
だからこそ要件定義書に何を書くか？の範囲、深さはプロジェクトにより異なると思いますが、私は以下の方針で書くことが多いです。
- 要件定義書はクライアント（非技術者）との要件について共通認識を持つための書類と位置付ける
- 要件に漏れがないことを重視（深さは開発可能かどうか）
深さについては、コードを書けない人がどこまで深い（と思ってる）資料を作ったところで100%再現性は無い（実装で開発者の主観・解釈が入る）と考えているので、必要以上に深く書いてもあまり意味ないかなーと思ってます。一方、要件は漏れてしまうとそもそも実装対象とならないので、漏れがないことをより重視しています。
まあ、クライアントワークで「黙って書けよ！」と言われれば書くには書きますが。。。
なので、結果として記述的には、
- まずは要件を列挙
- 各要件について說明資料を準備（メンバーの状況によりその深さを調整）
という感じになります。
構成（目次）を考える
文化によりやや異なるかと思いますが、以下のような項目を記述するのが一般的かなと思います。
- システム化（開発）の目的
- 業務要件
- 機能要件
- 外部機能（目に見える機能：画面、帳票等）
- 内部機能（目に見えない機能：データ、I/F、バッチ、外部連携等）
- 非機能要件
- 可用性
- 性能
- セキュリティー
あとは、非機能を中心にプロジェクトにとって重要な項目を追加する感じです。
- 方式
- 拡張性
- 移行
- 教育
- 環境
要件については、それぞれに対し、列挙と說明を書く感じです。
各内容を記述する（サンプルの說明）
では、サンプルについて少し解説したいと思います。
表紙
特に記述することはない。
目次
ひとまずこんな感じ。
システム化の目的と範囲
定番かつ必須の内容です。プロジェクト計画書から転記してもいいと思いますし、新たに起こしてもいい内容です。
業務要件一覧
私は必ず一覧を作るようにし、それだけでは理解できない項目について追加の資料を作るという感じにすることが多いですが、一般的には、一覧、概要、フロー図を用意することが多いかもしれません。
一般的な開発では一覧はパワポには収まらないため、Excelに列挙することが多いです。
業務要件フロー図
フロー図も書いてみました。今回はシステムが複雑じゃないのでこれ１枚。
一般的な開発では数十〜数百ページに及ぶこともあります。
機能要件一覧
業務要件同様、まず一覧を作成。必要に応じて說明資料をつくる感じ。
一般的な開発では一覧はパワポには収まらないため、Excelに列挙することが多いです。
機能要件（補足例：機能と配置イメージ）
今回は個別說明というより、全体像が解りにくいので全体のイメージ図と機能配置を補足資料として記述してみました。詳細の決定が設計等の後工程になるものはそれも明示し、必ず後工程等で定義するようにします。
非機能要件一覧
他の要件と同様、まず一覧化。定義しない要件も列挙して「定義しない」旨を明記したりするほうがいいです。じゃないと後で「言ってくれなかった」、「プロとして言うのが筋でしょ」とか言われるので。「定義しない」ことを定義するのも定義の１つです。
非機能要件：可用性
非機能要件：性能
非機能要件：セキュリティー
非機能要件：移行性
非機能要件：プロジェクト上の留意事項
一般的な非機能要件じゃなくても機能以外で明記すべきことがあれば「プロジェクト上の留意事項」等として明記しておく方が無難です。
ここからは補足資料です。
プロジェクト スケジュール（プロジェクト計画書から転記）
プロジェクト 体制（プロジェクト計画書から転記）
一般的には（参考）
実践ガイドブックでは？
実践ガイドブックにおいても要件定義は業務要件、機能要件、非機能要件（後者２つはシステム要件）で構成されるものとして紹介され、テンプレートも提供されています。
（実践ガイドブック 第3編5章 P13より引用）
業務要件定義書
業務要件定義のテンプレートは4章の添付書類となっており現状分析結果報告書のテンプレートと合わせて公開されています。
まずは現状分析を行う前提。新規などの場合は不要かと思います。
（現状分析結果報告書の目次）
改めて業務要件定義。業務の手順、範囲、フロー、体制などについて記載する想定です。
（業務要件定義書の目次）
機能要件定義書
機能一覧があり、その後、画面、帳票、データ、外部インターフェースを記述する流れになっています。
内部機能、外部機能といったカテゴリは無いようです（というか、その呼び名は私も違和感ありますが）。
（機能要件定義書の目次）
非機能要件定義書
行政サービスということもあり、最初にユーザビリティ及びアクセシビリティがありますね。
その他、中立性、引き継ぎ、教育等が存在するのが行政システムの資料っぽいです。
（非機能要件定義書の目次）
なお、TISさんのFintanでも要件定義関連資料が提供されており大変参考になります。また、要件定義資料ではありませんが、開発プロセス関連資料として提供されている「ウォーターフォール開発における役割分担シート」の小項目は要件定義で「決めないといけないことリスト（今回は対象外リスト）」になるかと思います。