要件定義書の書き方｜記入例と要件ID・受け入れ基準

要件定義書とは、これから作るシステムで「何を実現するか」――解決したい業務の課題、必要な機能、性能やセキュリティの条件、対象にしない範囲――を、発注者と開発者が合意するためにまとめた文書です。システム開発の最初の工程で作られ、以降の設計・開発・テストのすべての土台になります。

要件定義の抜けや認識の違いは、後の工程で見つかるほど、修正の費用が大きくなります。この記事では、要件の種類と記入例に加えて、要件ID・受け入れ基準・対象外の書き方といった、「後で揉めない」ための実務のポイントを解説します。基本設計書・詳細設計書の記事と合わせて読むと、上流工程の全体像がつかめます。

要件定義・基本設計・詳細設計の違い

要件定義書には、画面の細かな配置やデータベースの項目は書きません。「何を実現したいか」「どうなれば成功か」を、業務の言葉で書くのが要件定義です。

要件の3つの種類

機能要件だけを並べた要件定義書は、よくある失敗です。「なぜその機能が必要か（業務要件）」がないと、優先順位を判断できず、「どのくらいの品質で（非機能要件）」がないと、完成してから「遅い」「止まったら困る」といった問題が起きます。

要件定義書の目次テンプレート

1. はじめに
   1.1 背景と目的
   1.2 対象範囲と対象外
   1.3 用語集
   1.4 関係者と役割
2. 業務要件
   2.1 現状の業務と課題（As-Is）
   2.2 システム化後の業務（To-Be）
   2.3 業務フロー
3. 機能要件
   3.1 機能一覧（要件ID・優先度つき）
   3.2 機能ごとの要件と受け入れ基準
4. 非機能要件
   4.1 性能  4.2 可用性  4.3 セキュリティ  4.4 運用・保守  4.5 移行
5. 外部システムとの連携
6. 制約条件（予算・期限・利用する技術・法令）
7. 前提条件と未決事項
8. 変更履歴・承認

各項目の書き方と記入例

「電話・FAXで受けている法人向けの注文を、Webで受け付ける」システムを例にします。

背景と目的：数値で書ける目的を入れる

目的が数値や具体的な状態で書かれていると、機能の優先順位を判断でき、完成後に効果を測れます。

対象範囲と対象外

「対象外」を書かないと、「それもやってくれると思っていた」という認識の違いが、必ずと言っていいほど起きます。要件定義書で最も効果の大きい項目の1つです。

機能一覧：要件IDと優先度

要件IDを付けると、基本設計・テストで「どの要件に対応するか」を追えるようになり（トレーサビリティ）、要件の漏れと要件にない機能の追加の両方を防げます。

優先度は、MoSCoW（Must：必須、Should：できれば、Could：余裕があれば、Won't：今回はやらない）で付けるのが一般的です。予算や期限が厳しくなったときに、何を削るかを冷静に判断できます。

機能ごとの要件と、受け入れ基準

機能要件には、「どうなれば完成とするか」を判定できる受け入れ基準を付けます。

FR-003 注文

受け入れ基準

• 注文を確定すると、注文番号が表示され、担当者のメールアドレスに確認メールが届く
• 与信の限度額を超える場合は、注文が確定されず、理由が表示される
• 在庫がない商品を含む場合は、「取り寄せ」と表示されたうえで注文できる
• 同じ注文を二重に送信しても、注文は1件だけ登録される

「使いやすいこと」「正しく注文できること」のような書き方では、完成したかどうかを誰も判定できません。受け入れ基準は、テストの項目にそのまま使える具体さで書きます。「〜の場合は」という例外の条件を含めるのがポイントです。

非機能要件：数値で書く

非機能要件は、発注者が「言われなくても当然」と考えていることが多いため、開発側から質問して明文化します。IPAの「非機能要求グレード」は、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境の観点で項目を洗い出す手引きとして役立ちます。

未決事項

決まっていないことを、決まったことのように書かないのが大切です。未決事項として一覧にし、担当と期限を決めて管理します。

ヒアリングで使える質問

要件定義の質は、発注者から何を引き出せるかで決まります。

「どんな機能が欲しいですか？」とだけ聞くと、今の業務をそのまま置き換えた要望や、手段の話ばかりが出てきます。課題と目的から聞き、機能は開発側から提案する、という進め方が効果的です。

よくある失敗と対策

レビューのチェックリスト

• □ 目的が、数値や具体的な状態で書かれているか
• □ 対象範囲と対象外が明記されているか
• □ すべての機能要件に、要件ID・優先度・受け入れ基準があるか
• □ 受け入れ基準に、例外の条件（エラー時・上限を超えた場合など）が含まれているか
• □ 非機能要件（性能・可用性・セキュリティ・運用・移行）が数値で書かれているか
• □ 外部システムとの連携の相手・方式・タイミングが書かれているか
• □ 法令・社内規程・予算・期限などの制約が書かれているか
• □ 未決事項に、担当と期限があるか
• □ 用語が統一され、用語集と一致しているか
• □ 業務の担当者と、決裁者の両方が確認したか

AIを活用するときの注意点

生成AIは、ヒアリングのメモから要件の一覧の下書きを作る、受け入れ基準の抜け（例外の条件）を洗い出す、非機能要件の確認項目を挙げるといった作業で大きな助けになります。

一方で、次の点に注意します。

• AIはもっともらしい要件を補って書くため、発注者が言っていない要件が混ざることがある。すべての要件について「誰が言ったか」を確認する
• 数値（件数、応答時間など）を推測で埋めさせない。わからない数値は未決事項にする
• 発注者の機密情報を、許可されていないAIサービスに入力しない

受け入れ基準まで具体的に書かれた要件定義書は、その後の設計・実装でAIを使う場面でも、AIへの正確な指示の土台になります。

よくある質問

Q. 要件定義は誰が行いますか？ A. 本来は発注者が主体となって決めるものですが、実際には開発会社のSEやコンサルタントが、ヒアリングと提案を通じて一緒に作り上げることが多くあります。最終的に内容を承認するのは発注者です。

Q. 要件定義書と提案依頼書（RFP）の違いは何ですか？ A. RFPは、発注者が開発会社を選ぶために作る「こういうシステムを作ってほしい」という依頼書です。要件定義書は、開発会社が決まった後に、発注者と開発会社が一緒に詳細を詰めて合意する文書です。

Q. アジャイル開発でも要件定義書は必要ですか？ A. 分厚い要件定義書を最初に作ることは少なく、ユーザーストーリーとして要件を管理することが一般的です。ただし、目的、対象範囲、非機能要件、受け入れ基準の考え方は、アジャイル開発でも同じように重要です。

Q. 要件定義にはどのくらいの期間がかかりますか？ A. システムの規模によって大きく異なりますが、開発全体の期間の1〜2割程度をかけることが多いとされます。ここで時間を惜しむと、後の工程での手戻りが大きくなります。

まとめ

• 要件定義書は、システムで何を実現するかを発注者と開発者が合意する文書
• 要件は業務要件・機能要件・非機能要件の3種類。機能だけを並べない
• 目的は数値で、範囲は対象外まで書く
• 機能要件には要件ID・優先度（MoSCoW）・受け入れ基準を付ける
• 受け入れ基準は、例外の条件を含め、テストに使える具体さで書く
• 決まっていないことは未決事項として、担当と期限を決めて管理する

株式会社RJCでは、SI事業を通じて、お客様とともに課題を整理し、要件定義から設計・開発まで一貫してシステムを形にしています。お客様の想いを「伝わる」形にする力を、仲間と一緒に高め合いながら、成長を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。