要件定義書とは？書き方や記載項目をわかりやすく解説！

システム開発をしていると、「要件定義書を作成してください」と言われることがあります。

しかし、いざ要件定義書を書こうとすると、

• そもそも要件定義書って何？
• 機能仕様書や基本設計書とは何が違うの？
• 要件定義書には何を書けばいいの？
• 画面やデータベースの設計まで書く必要があるの？

と疑問に思うこともあるでしょう。

この記事では、要件定義書とは何なのか、基本的な役割や主な記載項目、具体的な書き方についてわかりやすく解説します。

要件定義書とは？

要件定義書とは、簡単にいうと、「なぜシステムを作るのか」「システムで何を実現するのか」「どのような条件を満たす必要があるのか」を整理した文書です。

システム開発では、いきなり画面を設計したりプログラムを書いたりするわけではありません。

まず、

• 現在どのような課題があるのか
• システムを導入して何を改善したいのか
• 誰がシステムを利用するのか
• システムにどのような機能が必要なのか
• 性能やセキュリティなど、どのような条件を満たす必要があるのか

といった内容を整理します。

例えば、現在はユーザー登録を紙の申込書で受け付け、担当者が申込内容を業務システムへ入力しているとします。

この業務を、利用者自身がWebサイトからユーザー登録するようにしたいと考えたとします。

この場合、要件定義では、

• ユーザー自身がWebからアカウントを登録できること
• 氏名・メールアドレスなど必要な情報を登録できること
• 登録したアカウントでログインできること
• 個人情報を適切に保護できること
• 想定する利用者数やアクセス数の条件で、必要な性能を満たせること

などを決めていきます。

一方、

• 登録画面の入力欄をどこに配置するか
• 登録ボタンをどこに配置するか
• エラーメッセージを画面のどこに表示するか
• どのクラスやメソッドで登録処理を実装するか

といった内容は、一般的には要件定義より後の基本設計や詳細設計で具体化します。

つまり、要件定義では「どのように作るか」よりも、「何のために、何を実現する必要があるのか」を明確にすることが重要です。

要件定義書は何のために作る？

要件定義書を作る大きな目的は、システムを作る目的や満たすべき要件について、発注者・利用者・開発者などの関係者の認識を合わせることです。

例えば、

ユーザー登録機能を作る。

だけでは、人によって想像する内容が異なる可能性があります。

ある人は、「メールアドレスとパスワードだけで登録できればよい」と考えるかもしれません。別の人は、「氏名・住所・電話番号も登録する必要がある」と考えるかもしれません。さらに、「登録したメールアドレスへ確認メールを送る必要がある」と考えている人もいるでしょう。

このような認識の違いを残したまま開発を進めると、完成したシステムが利用者や発注者の期待と異なるものになることがあります。

そのため、要件定義書では主に、

• システムを作る背景や目的
• システム化する範囲
• システムに必要な機能
• 性能・可用性・セキュリティなどの条件

などを整理し、発注者・利用者・開発者などで確認・合意します。

また、要件定義書は、その後の機能仕様・基本設計・テストなどを行うための基礎資料にもなります。

要件定義が曖昧なまま開発を進めると、後工程で大きな手戻りが発生する可能性があるため、要件定義はシステム開発において重要な工程です。

要求と要件の違い

要件定義について調べていると、要求と要件という言葉が登場します。

厳密な使い分けは組織やプロジェクトによって異なりますが、一般的には次のように考えると分かりやすいと思います。

用語	意味
要求	利用者・顧客・業務部門などの関係者が「こうしたい」「こうであってほしい」と求めているニーズや期待
要件	要求や制約などを整理し、システムや業務として満たすべき条件を明確にしたもの

例えば、利用者から、

ユーザー登録をもっと簡単にしたい。

という要求があったとします。

この要求について、

• Webからユーザー登録できること
• スマートフォンからも登録できること
• 必須項目は氏名・メールアドレス・パスワードとする
• 登録完了後に確認メールを送信できること

など、要求を実現するために満たすべき条件として整理したものが要件です。

要件定義書・機能仕様書・基本設計書・詳細設計書の違い

要件定義書について理解するときは、機能仕様書・基本設計書・詳細設計書との違いを知っておくと分かりやすくなります。

それぞれの役割を大まかに分けると、次のようになります。

文書	主に決めること
要件定義書	なぜ作るのか、何を実現する必要があるのか
機能仕様書	システムがどのように振る舞うのか
基本設計書	画面・データ・外部インターフェースなどをどのような形にするのか
詳細設計書	プログラム内部をどのように構成・実装するのか

要件定義書に書く主な項目

要件定義書には「必ずこの項目を書かなければならない」という一律の決まりがあるわけではありません。

システムの規模や種類、プロジェクトの進め方によって必要な項目は異なります。

一般的な業務システムやWebシステムであれば、例えば次のような内容を整理します。

1. 基本情報・改訂履歴

まず、要件定義書そのものを管理するための基本情報を記載します。

例えば、次のような内容です。

• 文書名
• システム名
• バージョン
• 作成日
• 作成者
• 承認者
• 改訂履歴

要件定義書は、プロジェクトの途中で内容が追加・変更されることがあります。

そのため、「どの版が最新なのか」「いつ、どの内容が変更されたのか」を確認できるようにしておくことが重要です。

例えば、改訂履歴は次のように整理します。

バージョン	日付	変更内容	作成者
1.0	2026/09/03	初版作成	山田
1.1	2026/09/10	性能要件を追加	山田

2. 背景・現状

背景・現状では、なぜシステムを開発することになったのかを整理します。

現在の業務がどのように行われていて、どのような問題や課題があるのかを記載します。

例えば、現在のユーザー登録業務が次のようになっているとします。

現在、ユーザー登録は紙の申込書で受け付けている。
担当者が申込書の内容を業務システムへ手入力しているため、登録作業に時間がかかっている。
また、手入力による入力ミスが発生することもある。

このように、現在の業務や問題点を整理しておくことで、「なぜシステムを作る必要があるのか」が分かりやすくなります。

3. システム化の目的

次に、システムを導入することで、何を改善・実現したいのかを明確にします。

現在のユーザー登録業務の場合は次のように記載できます。

ユーザー自身がWebサイトからアカウントを登録できるようにし、 担当者による手入力作業を削減する。
これにより、登録業務の効率化と入力ミスの削減を実現する。

ここで重要なのは、単に、「ユーザー登録システムを作る」と書くだけで終わらせないことです。これでは「システムを作ること」自体が目的になってしまいます。

例えば、

• 登録作業にかかる時間を減らしたい
• 担当者の作業負担を減らしたい
• 入力ミスを減らしたい
• 利用者自身で登録できるようにしたい

といった、システムを導入することで解決したい課題や実現したい状態まで明確にします。

「背景・現状」が現在どのような問題があるのかを整理する項目なのに対して、「システム化の目的」はその問題をシステムによってどのように改善したいのかを整理する項目です。

4. システム化の範囲

システム化の範囲では、今回のプロジェクトでどこまでを対象にするのかを明確にします。

例えば、次のように整理します。

業務・機能	対象
ユーザー登録	○
ログイン	○
ユーザー情報変更	○
パスワード変更	○
商品購入	対象外
商品配送	対象外

システム化の範囲を決めていないと、開発途中で「ユーザー管理も今回作ると思っていた」「商品購入まで今回の対象だと思っていた」といった、関係者同士の認識の違いを防ぎやすくなります。

そのため、何を作るのかだけでなく、何を今回の対象外とするのかも明確にすることが重要です。

5. 利用者・関係者

次に、誰がシステムを利用するのか、また誰がこのシステムに関係するのかを整理します。

例えば、次のようにまとめます。

利用者・関係者	内容
未登録ユーザー	新しくアカウントを登録する
一般ユーザー	ログインしてサービスを利用する
管理者	ユーザー情報を管理する
運用担当者	システムの監視や運用を行う

利用者によって、必要となる機能や利用できる範囲は異なります。

例えば、

• 未登録ユーザーはユーザー登録を行う
• 一般ユーザーは自身の登録情報を確認・変更する
• 管理者はユーザー情報を管理する

といった違いがあります。

そのため、要件を考える前に、「誰がこのシステムを使うのか」を整理しておくことが重要です。

6. 現行業務と新しい業務

業務システムを開発する場合は、システム導入前と導入後で、業務の流れがどのように変わるのかを整理することがあります。

このように、導入前と導入後の業務を比較することで、

• どの作業がなくなるのか
• どの作業をシステムが行うのか
• 利用者や担当者の役割がどのように変わるのか
• 新しく必要になる作業は何か

を把握しやすくなります。

例えば今回のケースでは、「担当者が紙の申込内容をシステムへ手入力する」という作業がなくなり、「利用者自身がWebサイトから情報を登録する」という業務に変わります。

このように現行業務と新しい業務を整理しておくことで、システム化によって何を変えるのか、そのためにどのような機能が必要なのかを考えやすくなります。

7. 機能要件

要件定義書では、システムとして満たす必要がある要件を一覧にして管理することがあります。

例えば、会員制Webサービスであれば、次のような要件があります。

要件ID	要件
REQ-001	ユーザーがWebサイトからアカウントを登録できること
REQ-002	登録済みユーザーがシステムへログインできること
REQ-003	ユーザーが自身の登録情報を変更できること
REQ-004	ユーザーがパスワードを変更できること
REQ-005	管理者が登録ユーザーを確認できること

このように、それぞれの要件に要件IDを付けておくと、要件の追加や変更を管理しやすくなります。

また、要件IDは、その後に作成する機能仕様書や基本設計書、テスト仕様書などとの対応関係を管理するときにも利用できます。

例えば、要件定義で決めた内容をもとに、機能仕様書や基本設計書では、必要な機能や画面をさらに具体化します。

要件ID	機能ID	機能概要	画面ID
REQ-001	F-001	氏名・メールアドレス・パスワードを入力してユーザーを登録する	SCR-001
REQ-001	F-002	登録したメールアドレスへ確認メールを送信する	-
REQ-002	F-003	メールアドレスとパスワードを利用してユーザーを認証する	SCR-002
REQ-003	F-004	ユーザーが自身の登録情報を変更する	SCR-003
REQ-004	F-005	ユーザーが自身のパスワードを変更する	SCR-004
REQ-005	F-006	管理者が登録ユーザーを検索・確認する	SCR-005

例えば、REQ-001の「ユーザーがWebサイトからアカウントを登録できること」という要件は、

REQ-001：ユーザーがWebサイトからアカウントを登録できること
↓
F-001：ユーザーを登録する
↓
SCR-001：ユーザー登録画面

のように、後工程の機能や画面へ具体化されていきます。

また、要件と機能が必ず1対1で対応するわけではありません。

上の例では、REQ-001という1つの要件を実現するために、

• F-001：ユーザーを登録する機能
• F-002：確認メールを送信する機能

という複数の機能が存在します。

反対に、複数の要件を1つの機能で実現する場合もあります。

なお、この段階では、

• 登録ボタンは画面右下に配置する
• エラーメッセージは入力欄の下に表示する
• UserServiceクラスで登録処理を行う

といった画面設計やプログラム内部の実装方法まで要件として決める必要はありません。

要件定義では、まず「システムとして何を実現する必要があるのか」を整理することが重要です。

このような要件一覧には、ユーザー登録やログインなどの機能要件だけでなく、性能・セキュリティ・運用などの非機能要件も含めて管理することがあります。次に、機能要件と非機能要件の違いについて見ていきます。

機能要件と非機能要件の違い

要件定義書に記載する要件は、大きく機能要件と非機能要件に分けて考えることができます。

用語	意味
機能要件	システムが提供する機能や振る舞い
非機能要件	性能・可用性・セキュリティ・運用・保守など、機能以外に満たすべき条件

例えば、「ユーザーがログインできること」は機能要件です。

一方、

• 通常時のログイン処理は3秒以内に完了すること
• 定められたサービス提供時間に利用できること
• インターネットを経由する通信を暗号化すること
• 障害時に定められた時間内で復旧できること

などは非機能要件です。

どれだけ必要な機能がそろっていても、システムの動作が極端に遅かったり、頻繁に停止したり、安全に利用できなかったりすれば、実用的なシステムとはいえません。

そのため、要件定義では、機能要件だけでなく非機能要件についても整理することが重要です。

例えば、要件定義書には次のような非機能要件を記載します。

要件ID	分類	要件
NFR-001	性能	規定した負荷条件において、主要画面の95％以上のリクエストを3秒以内に応答すること
NFR-002	セキュリティ	管理機能は管理者権限を持つユーザーのみ利用できること
NFR-003	運用	システムのバックアップを1日1回取得すること

これらの非機能要件についても、基本設計などの後工程では、どのように実現するのかを具体化していきます。

例えば、次のように整理できます。

要件ID	要件	基本設計などで具体化する内容の例
NFR-001	規定した負荷条件において、主要画面の95％以上のリクエストを3秒以内に応答すること	想定するアクセス数や処理量をもとに、サーバー構成・キャッシュ・データベースなどの構成を検討する
NFR-002	管理機能は管理者権限を持つユーザーのみ利用できること	管理機能に認証・認可を適用し、管理者権限を持つユーザーだけが利用できるように設計する
NFR-003	システムのバックアップを1日1回取得すること	バックアップの取得方法・実行時刻・保存先・保存期間などを設計する

8. 非機能要件

8.1 性能要件

性能要件では、システムがどのくらいの速さ・処理能力を持つ必要があるのかを定義します。

例えば、次のような内容です。

• 同時に何人まで利用できる必要があるのか
• 1日にどれくらいのアクセスや処理を想定するのか
• 画面をどのくらいの時間で表示する必要があるのか
• どれくらいのデータ量を扱うのか

例えば、次のように定義します。

項目	要件
同時利用者数	最大1,000ユーザー
通常画面の応答時間	規定した負荷条件において、主要画面の95％以上のリクエストを3秒以内に応答すること
1日の登録件数	最大10,000件
データ量	5年間で最大○○万件のユーザーデータを保持できること

例えば、「高速に動作すること」だけでは、人によって「高速」の基準が異なります。

そのため、「規定した負荷条件において、主要画面の95％以上のリクエストを3秒以内に応答すること」のように、できるだけ確認できる条件として定義します。

性能要件では、単に数値を書くのではなく、どのような負荷条件で、その数値を満たす必要があるのかも明確にしておくことが重要です。

8.2 可用性・信頼性要件

可用性・信頼性要件では、システムをどのくらい止めずに利用できる必要があるのか、障害が起きたときにどの程度まで復旧できる必要があるのかを定義します。

例えば、次のような内容です。

• サービスを利用できる時間
• どの程度の稼働率が必要か
• 計画メンテナンスをいつ行うか
• 障害発生後、何時間以内に復旧する必要があるか
• 障害発生時、どの時点までのデータを復旧する必要があるか

例えば、次のように定義します。

項目	要件
サービス提供時間	原則24時間365日。ただし計画メンテナンス時間を除く
定期メンテナンス	毎月第2日曜日 2:00～4:00
RTO	重大障害発生後4時間以内
RPO	障害発生時点から最大24時間前まで

RTO（Recovery Time Objective：目標復旧時間）は、障害が発生してから、どのくらいの時間でシステムを復旧する必要があるのかを表します。例えば、「RTO：4時間」であれば、重大な障害が発生しても、4時間以内にサービスを復旧できることを目標とします。

RPO（Recovery Point Objective：目標復旧時点）は、障害が発生した場合に、どの時点までのデータを復旧できる必要があるのかを表します。例えば、「RPO：24時間」であれば、障害発生時点から最大24時間分のデータ損失を許容するという意味です。つまり、障害が発生した時点から遡って、24時間以内の時点までデータを復旧できることを目標とします。

実際のRTOやRPOは、システムが停止した場合の業務への影響やコストなどを考慮して決めます。

8.3 セキュリティ要件

セキュリティ要件では、誰がシステムを利用できるのか、データや通信をどのように守る必要があるのかを定義します。

例えば、次のような内容です。

• ユーザーをどのように認証するのか
• 誰がどの機能を利用できるのか
• 通信をどのように保護するのか
• 保存しているデータをどのように保護するのか
• パスワードをどのように扱うのか
• 操作履歴をどこまで記録するのか
• 不正アクセスや脆弱性へどのように対応するのか

例えば、次のように定義します。

• 管理機能は、管理者権限を持つユーザーのみ利用できること
• インターネットを経由する通信は暗号化して保護すること
• 管理者による重要な操作は、監査できるよう操作ログを記録すること

8.4 運用・保守要件

運用・保守要件では、システムをリリースしたあと、日常的にどのように運用・管理していくのかを定義します。

例えば、次のような内容です。

• システムをどのように監視するのか
• バックアップをどのくらいの頻度で取得するのか
• ログをどのくらい保存するのか
• 障害が発生した場合、誰がどのように対応するのか
• アカウントをどのように管理するのか
• 定期メンテナンスをどのように行うのか
• 利用者からの問い合わせにどのように対応するのか

例えば、次のように定義します。

項目	要件
システム監視	24時間監視する
バックアップ	1日1回取得する
ログ保存期間	1年間保存する
定期メンテナンス	毎月第2日曜日に実施する

可用性・信頼性要件と似ていますが、考え方は少し異なります。

可用性・信頼性要件は「どの状態を満たす必要があるのか」を定義し、運用・保守要件は「その状態を維持するために、どのような運用を行う必要があるのか」を整理します。

例えば、

• RPOを24時間以内にする → 可用性・信頼性要件
• そのRPOを満たすために、バックアップを1日1回取得する → 運用・保守要件

と考えると分かりやすいでしょう。

9. 移行要件

移行要件では、現在利用しているシステムやデータを、新しいシステムへどのように移す必要があるのかを定義します。

既存システムがない新規開発では不要な場合もあります。

例えば、次のような内容です。

• どのデータを新システムへ移行するのか
• 何年分のデータを移行するのか
• 古いデータをどのように新しい形式へ変換するのか
• 移行中にサービスを停止するのか
• 新旧システムを一定期間並行して利用するのか
• 移行に失敗した場合、元のシステムへ戻せるようにするのか

例えば、

• 既存システムに登録されている全ユーザー情報を新システムへ移行する
• 過去5年分の利用履歴を移行対象とする

といった内容を定義します。

移行はリリース直前に問題が見つかると大きな影響が出やすいため、要件定義の段階から対象範囲や条件を整理しておくことが重要です。

10. 外部システムとの連携要件

外部システムとの連携要件では、新しいシステムが、どのシステムや外部サービスと何をやり取りする必要があるのかを整理します。

例えば、

• メール配信サービス
• 決済サービス
• 社内の顧客管理システム
• 認証サービス
• 外部API

などとの連携です。

例えば、次のように整理します。

外部システム	連携内容
メール配信サービス	登録完了メールを送信する
認証サービス	ユーザー認証を行う
顧客管理システム	登録したユーザー情報を連携する

要件定義では、まず「どのシステムと、何を連携する必要があるのか」を明確にします。

一方、

• APIのURL
• HTTPメソッド
• リクエスト項目
• レスポンス項目
• エラーコード

などの詳細なインターフェース仕様は、基本設計などの後工程で具体化することが一般的です。

11. 制約条件

制約条件では、システムを開発するときに守らなければならない、変更しにくい条件を整理します。

例えば、

• 予算
• リリース期限
• 使用しなければならない既存システム
• 使用するクラウドサービス
• 対応しなければならない端末やブラウザ
• 法律や社内規定
• 技術上の制限

などがあります。

例えば、

• 既存の顧客管理システムは変更しない
• 新システムは既存の認証基盤を利用する
• 2027年4月までにサービスを開始する

といった内容です。

制約条件は、システムに求める機能そのものではありません。

しかし、設計や実装方法を大きく左右するため、要件定義の段階で明確にしておくことが重要です。

12. 前提条件

前提条件では、要件を決めるうえで「この条件は満たされているものとして考える」という前提を整理します。

例えば、

• 利用者はインターネットへ接続できる環境を持っているものとする
• 既存の顧客管理システムは、開発期間中も継続して利用できるものとする
• 外部の認証サービスは、新システムのリリース後も提供されるものとする

といった内容です。

制約条件と似ていますが、違いがあります。

種類	考え方	例
制約条件	開発時に守らなければならない条件	既存の認証基盤を利用すること
前提条件	要件を検討するときに成り立っているものとして扱う条件	既存の認証基盤が継続して利用できること

例えば、「既存の認証基盤を利用しなければならない」のであれば制約条件です。一方、「その認証基盤は今後も利用できるものとする」のであれば前提条件です。

前提条件が崩れた場合は、それをもとに決めていた要件や設計を見直す必要が出てくる可能性があります。

そのため、暗黙の前提にせず、文章として残しておくことが重要です。

13. 用語定義

プロジェクト独自の用語や、意味が曖昧になりやすい言葉について定義します。

用語	意味
ユーザー	本サービスへアカウント登録している利用者
管理者	ユーザー情報を管理する権限を持つ利用者
仮登録	メールアドレスの確認が完了していない状態
本登録	メールアドレスの確認が完了した状態

同じ「ユーザー」という言葉でも、管理者を含むのか一般ユーザーだけを意味するのかによって仕様が変わる可能性があります。

そのため、重要な用語については意味を明確にします。

要件には優先度を付ける

すべての要件を必ず同じ優先度で実現できるとは限りません。

予算やスケジュールによって、機能を絞る必要が出る場合もあります。

そのため、要件ごとに優先度を付ける方法もあります。

要件	優先度
ユーザー登録	必須
ログイン	必須
パスワード再設定	必須
SNSアカウントによるログイン	高
プロフィール画像設定	中

優先度を設定しておくことで、開発範囲を調整する必要が生じた場合に判断しやすくなります。

要件定義では関係者との合意が重要

要件定義書は、作成しただけでは十分ではありません。

重要なのは、発注者・利用者・開発者などの関係者が内容を確認し、

この内容を満たすシステムを作る。

という共通認識を持つことです。

特に、

• 対象範囲
• 機能要件
• 非機能要件
• 制約条件
• 前提条件
• 優先順位

などについて認識がずれていると、後工程で大きな問題になる可能性があります。

そのため、要件定義書をレビューし、必要に応じて修正したうえで関係者の合意を取ります。

要件定義書を書く際の注意点

要件定義書では、単に利用者から聞いた内容をそのまま書けばよいわけではありません。

要求の背景や目的を確認しながら、実現すべき要件として整理することが重要です。

曖昧な表現を避ける

要件は、できるだけ具体的で、満たしているかどうかを確認できる内容にします。

例えば、利用者から、「検索を速くしてほしい」と言われた場合、そのまま、「検索を速くすること」と要件にしてしまうと、「速い」の基準が人によって異なります。

そのため、例えば、「規定した負荷条件において、主要画面の95％以上のリクエストを3秒以内に応答すること」のように、可能なものは具体的な条件にします。

特に、

• なるべく
• できるだけ
• 高速
• 十分な
• 適切に
• 必要に応じて
• 使いやすい

といった、人によって判断が変わる表現には注意が必要です。

例えば、「大量のアクセスにも耐えられること」よりも、「ピーク時に1,000ユーザーが同時に利用できること」の方が、要件を満たしたかどうか確認しやすくなります。

ただし、すべての要件を数値だけで表せるわけではありません。

数値化が難しい場合でも、どのような状態になれば要件を満たしたと判断できるのかを、できるだけ明確にしておくことが重要です。

利用者の要望をそのまま要件にしない

利用者から言われた内容を、そのまま要件として採用するのではなく、なぜその要望があるのかを確認することも重要です。

例えば、「この画面にExcel出力ボタンが欲しい」と言われた場合でも、すぐに「Excel出力機能が必要」と決めるのではなく、「なぜExcelへ出力したいのか？」を確認します。

本当の目的が、「毎月の集計資料を作るため」なのであれば、Excel出力だけでなく、集計画面や自動レポートなど、より適した方法があるかもしれません。

要件定義では、表面的な要望だけでなく、その背景や目的まで確認して要件を整理することが重要です。

要件と設計を混同しない

要件定義では、「何を実現する必要があるのか」を中心に記載します。

例えば、

• 要件
  • ユーザーがメールアドレスとパスワードを利用してログインできること。
• 基本設計に近い内容
  • ログイン画面中央にメールアドレス入力欄を配置する。
• 詳細設計に近い内容
  • AuthService.login()メソッドで認証処理を行う。

のように整理できます。

要件定義の段階で、画面レイアウトやプログラム内部の実装方法まで細かく決めてしまうと、要件と設計の境界が分かりにくくなります。

ただし、利用する技術や画面方式そのものが契約条件や制約条件になっている場合は、要件として記載することもあります。

重要なのは、「なぜその内容を要件として決める必要があるのか」を意識し、要件と設計を区別することです。

機能要件だけでなく非機能要件や対象範囲も整理する

要件定義では、必要な機能だけを決めればよいわけではありません。

性能・セキュリティ・可用性・運用などの非機能要件を後回しにすると、例えば、

• 機能は完成したが、アクセスが集中すると動かない
• バックアップ方法が決まっていない
• 障害発生時に誰が対応するのか決まっていない

といった問題が、リリース直前になって見つかることがあります。

そのため、機能要件だけでなく、非機能要件についても要件定義の段階から検討しておくことが重要です。

また、システム化する範囲が曖昧なまま開発を進めると、「ユーザー管理も今回作ると思っていた」「商品購入まで今回の対象だと思っていた」といった認識の違いが発生することがあります。

そのため、「何を対象にするのか」だけでなく、「何を対象外にするのか」も明確にしておくことが重要です。

まとめ

この記事では「要件定義書」について、以下の内容を説明しました。

• 要件定義書とは何か
• 要求と要件の違い
• 要件定義書・機能仕様書・基本設計書・詳細設計書の違い
• 要件定義書に書く主な項目
• 機能要件と非機能要件の違い
• 要件定義書の書き方
• 要件定義書を書く際の注意点

要件定義書は、単に必要な機能を一覧にした文書ではありません。

システムを作る背景や目的、対象範囲、機能要件、性能・可用性・セキュリティ・運用などの非機能要件、制約条件などを整理し、「このシステムで何を実現するのか」を関係者で共有するための重要な文書です。

要件定義の内容は、その後の機能仕様・基本設計・詳細設計・実装・テストの基礎になります。

そのため、「どのように作るか」を急いで決めるのではなく、まずは「なぜ作るのか」「何を実現する必要があるのか」を明確にすることが重要です。

お読みいただきありがとうございました。