要件定義書のサンプル｜書き方・テンプレートと全9章の記入例

要件定義書は、業務の課題から「何を作るか」を決め、その後の設計と、最後の受け入れテストの両方の土台になります。

flowchart TD
    A[業務の課題・要望] --> B[要件定義書<br>何を・どこまで作るか]
    B --> C[基本設計書<br>画面・データの形]
    C --> D[開発]
    D --> E[受け入れテスト<br>完成かを判定]
    B -. 受け入れ基準 .-> E

この記事のサンプルは、次の9章でできています。章ごとに「何を書くか」と、サンプルに書いた例を並べました。

確認環境：Ubuntu 24.04.4 LTS・Python 3.11.15（SQLite 3.45.1・pytest 9.1.1）で、サンプルの FR-04 の受け入れ基準7つをテストのコードにし、小さな試作に対して実行しました。要件ID・優先度・受け入れ基準の抜け、あいまいな言葉を見つけるチェック用のスクリプトも、サンプルとレビュー前の下書きに通しています。非機能要件の数値は、同じ件数のデータを作って検索の時間を測りました。図は mermaid 11.17.2 で描画を確かめています。IPA の「非機能要求グレード2018」「ユーザのための要件定義ガイド 第2版」、デジタル庁の「デジタル社会推進標準ガイドライン」は公式のページで確かめました（確認日 2026年10月24日）。

要件定義書のサンプル（社内の備品貸出システム・全9章）

この節では、要件定義書1冊分のサンプルを、表紙から第9章まで通しで読めます。

題材は、架空の会社（社員約300名・本社1か所）の「社内の備品貸出システム」です。総務部が、ノートPC・プロジェクター・モバイルWi-Fi などの備品を、共有の表計算ファイルと紙の貸出票で管理している、という設定にしました。小さなシステムですが、要件定義書に要る章はすべて入っています。

表紙・変更履歴

第1章 はじめに（背景・目的・対象範囲・用語）

1.1 背景

備品（約450点）の貸出は、社員が総務部の窓口に来て紙の貸出票を書き、総務部の担当者2名が共有の表計算ファイルに転記している。貸出は月に約300件あり、受付と転記に1件あたり約8分、月に約40時間かかっている。前回の棚卸では、所在が分からない備品が12点あった。返却期限を過ぎた貸出は月平均15件ある。

1.2 目的（業務要件の目標）

1.3 対象範囲と対象外

1.4 用語集

1.5 関係者と役割

第2章 業務要件（今の業務・新しい業務・業務ルール）

2.1 今の業務（As-Is）と課題

2.2 新しい業務（To-Be）

社員は自分で空きを確かめて申請し、総務部は受け渡しと返却のときに QR コードを読み取るだけにします。

flowchart TD
    A[社員が空きを検索] --> B[貸出の申請]
    B --> C{10万円以上}
    C -- はい --> D[上長が承認]
    C -- いいえ --> E[総務が QR で受け渡し]
    D --> E
    E --> F[返却時に QR で記録]

2.3 業務ルール

2.4 貸出の状態

第3章 機能要件（機能一覧と受け入れ基準）

3.1 機能一覧

優先度は MoSCoW（Must：必ず作る、Should：できれば作る、Could：余力があれば作る、Won't：今回は作らない）で付けました。

今回は作らないもの（Won't）：社外への貸出、備品の購入の申請、費用を部ごとに分ける計算、スマートフォン向けのアプリ。

3.2 FR-04 貸出の申請（詳細）

FR-04 の受け入れ基準（この7つは、後の節でテストのコードにして実行しています）

3.3 ほかの機能の受け入れ基準（Must と Should）

第4章 画面・帳票・メール

画面の配置や項目の並びは、要件定義書には書かず、基本設計書で決めます。

第5章 データ要件

社員のデータは、このシステムでは作らず、人事システムから取り込みます（第6章）。

第6章 外部システムとの連携

IF-01 の CSV の項目と文字コードは、人事部と第2版までに決めます（Q-01）。

第7章 非機能要件

IPA の「非機能要求グレード」の6つの大項目に分けて書きました。

第8章 移行要件

第9章 受け入れ基準・制約・未決事項

9.1 受け入れ（検収）の条件

総務部が2027年3月に受け入れテストを行い、次の4つをすべて満たしたら受け入れる。

9.2 制約と前提

9.3 スケジュール

9.4 未決事項

要件定義書のテンプレート（コピーして使える目次と書くこと）

この節では、上のサンプルから中身を抜いた、そのまま使える目次の型が分かります。

次のテンプレートを文書の先頭に貼り、各章のコメントに沿って埋めていきます。 コメント（<!-- -->）は書き終えたら消します。

# （システム名） 要件定義書

| 版 | 日付 | 変更の内容 | 承認 |
|---|---|---|---|
| 0.9 | YYYY年M月D日 | レビュー用の初版 | ― |

## 1. はじめに
### 1.1 背景            <!-- 今の業務の件数・時間・困りごとを数字で -->
### 1.2 目的（業務要件）  <!-- BR-01〜：何を・どれだけ良くするか。目標は数値 -->
### 1.3 対象範囲と対象外  <!-- 「作らないもの」を必ず書く -->
### 1.4 用語集          <!-- 社内の言葉・あいまいになりやすい言葉の定義 -->
### 1.5 関係者と役割      <!-- 決める人・承認する人・データを出す人 -->

## 2. 業務要件
### 2.1 今の業務（As-Is）と課題
### 2.2 新しい業務（To-Be）   <!-- 業務フロー図 -->
### 2.3 業務ルール（R-01〜）  <!-- 上限・期限・承認の条件。例を添える -->

## 3. 機能要件
### 3.1 機能一覧（要件ID・使う人・優先度 MoSCoW・業務要件）
### 3.2 機能ごとの詳細と受け入れ基準（AC-xx-n）
<!-- 受け入れ基準は「〜すると〜になる」「〜の場合は〜と出る」の形で -->

## 4. 画面・帳票・メール   <!-- 一覧だけ。配置は基本設計で -->
## 5. データ要件         <!-- データ・主な項目・件数・残す期間 -->
## 6. 外部システムとの連携  <!-- 相手・受け渡すもの・方式・タイミング -->
## 7. 非機能要件         <!-- 可用性／性能・拡張性／運用・保守性／移行性／セキュリティ／システム環境・エコロジー -->
## 8. 移行要件          <!-- 何を・いつ・どう移し・どう確かめるか -->
## 9. 受け入れ基準・制約・未決事項
### 9.1 受け入れ（検収）の条件
### 9.2 制約と前提（期限・費用・技術・規程）
### 9.3 スケジュール
### 9.4 未決事項（内容・担当・期限）

一覧表で管理するときのシート構成

機能要件や非機能要件が数十件を超えるときは、本文は文書にし、一覧は表計算ソフト（スプレッドシート）で持つ形もよく使われます。そのときは、次のようにシートを分けると、要件IDでつながります。

要件と設計・テストの対応を一覧で追う方法は、関連記事「トレーサビリティマトリクスの作り方 要件・設計・テスト対応表」で扱っています。

要件定義書とは（要求定義書・RFP・基本設計書との違い）

この節では、要件定義書の役割と、名前の似た文書との違いが分かります。

要件定義書とは、これから作るシステムで「何を実現するか」を、発注する側と開発する側が合意するための文書です。 業務の課題・必要な機能・品質の条件・作らない範囲・完成の判定のしかたを書き、承認者の承認で確定します。

要求と要件の違いは、関連記事「要求と要件の違い｜要求定義と要件定義の書き方と例」で、要件定義書の次に作る文書は、関連記事「基本設計書の書き方｜項目・記入例とレビューの観点」で扱っています。

要件の3つの種類

機能要件だけを並べた要件定義書は、よく見る失敗です。 業務要件が無いと、予算が足りないときに何を削るかを決められません。非機能要件が無いと、完成してから「遅い」「止まると困る」という話になります。

要件定義書に書くこと・書かないこと

要件定義書の書き方（5つの手順）

この節では、白紙からサンプルの形まで仕上げる順番が分かります。

目的と範囲を先に決め、業務の流れ → 要件の一覧 → 品質の数値 → レビューの順に書きます。 機能から書き始めると、目的に合わない機能が混ざりやすくなります。

ヒアリングで聞くことを一覧にしたシートは、関連記事「要件ヒアリングの質問一覧60項目｜シートのテンプレートと記入例」で扱っています。業務の流れを図にする方法は、関連記事「業務フロー図の書き方｜記号一覧・スイムレーン例とMermaidテンプレート」で扱っています。

各章の書き方のコツ（あいまいな書き方→判定できる書き方）

この節では、レビューで直されることの多い書き方と、その直し方が分かります。

要件は「読んだ人が、できたかどうかを同じように判定できる」形で書きます。 形容詞（速い・使いやすい）や「など」で終わる書き方は、人によって読み方が変わります。

章ごとのコツ

受け入れ基準はテストにそのまま使える（サンプルで実行した結果）

この節では、サンプルの FR-04 の受け入れ基準7つを、実際にテストのコードにして動かした結果が分かります。

判定できる形で書いた受け入れ基準は、1つずつがそのままテストになります。 貸出の申請だけを Python と SQLite で小さく作り（試作）、AC-04-1〜7 をテストにして pytest で実行しました。テストの名前は基準ID と同じにしています。

def test_AC_04_2_14日を超える期間は申請できない(db):
    # 借りる日を1日目と数える：4月12日に借りたら4月25日が14日目
    apply(db, "E001", "PJ-001", "2027-04-12", "2027-04-25", "t1", TODAY)
    with pytest.raises(ValueError, match="貸出期間は最長14日です"):
        apply(db, "E001", "CB-001", "2027-04-12", "2027-04-26", "t2", TODAY)

def test_AC_04_6_10万円以上は上長の承認待ちになる(db):
    no, status = apply(db, "E001", "PC-001", "2027-04-12", "2027-04-16", "t1", TODAY)
    assert status == "承認待ち"
    assert db.outbox == [("tanaka@example.com", f"承認依頼：申請番号{no}")]

「最長14日」を読み違えた試作で、1つが不合格になった

最初の試作は「返す日と借りる日の差が14日を超えたらエラー」と作りました。この作りだと、4月12日〜4月26日（借りる日を1日目と数えると15日間）が通ってしまいます。受け入れ基準に「4月26日までにすると申請できない」と例を書いていたので、テストで見つかりました。

________________________ test_AC_04_2_14日を超える期間は申請できない _________________________
    def test_AC_04_2_14日を超える期間は申請できない(db):
        # 借りる日を1日目と数える：4月12日に借りたら4月25日が14日目
        apply(db, "E001", "PJ-001", "2027-04-12", "2027-04-25", "t1", TODAY)
>       with pytest.raises(ValueError, match="貸出期間は最長14日です"):
E       Failed: DID NOT RAISE ValueError

test_fr04.py:27: Failed
=========================== short test summary info ============================
FAILED test_fr04.py::test_AC_04_2_14日を超える期間は申請できない - Failed: DI...
========================= 1 failed, 6 passed in 0.03s ==========================

借りる日を1日目と数えるように1行直すと、7つとも合格しました。

-    if (date.fromisoformat(due) - date.fromisoformat(start)).days > MAX_DAYS:
+    if (date.fromisoformat(due) - date.fromisoformat(start)).days + 1 > MAX_DAYS:  # 借りる日を1日目と数える
         raise ValueError("貸出期間は最長14日です")          # AC-04-2

test_fr04.py::test_AC_04_1_空いている備品を申請できる PASSED             [ 14%]
test_fr04.py::test_AC_04_2_14日を超える期間は申請できない PASSED         [ 28%]
test_fr04.py::test_AC_04_3_4点目は申請できない PASSED                    [ 42%]
test_fr04.py::test_AC_04_4_返却期限を過ぎた人は申請できない PASSED       [ 57%]
test_fr04.py::test_AC_04_5_期間が重なる備品は申請できない PASSED         [ 71%]
test_fr04.py::test_AC_04_6_10万円以上は上長の承認待ちになる PASSED       [ 85%]
test_fr04.py::test_AC_04_7_二重送信しても1件だけ登録される PASSED        [100%]

============================== 7 passed in 0.02s ===============================

受け入れ基準の考え方と、テストの観点の広げ方は、関連記事「トレーサビリティマトリクスの作り方 要件・設計・テスト対応表」で扱っています。

要件定義書をスクリプトでチェックした結果（ID・抜け・あいまいな言葉）

この節では、レビューの前に機械的に見つけられる抜けを、サンプルと下書きで比べた結果が分かります。

要件ID・優先度・受け入れ基準・未決事項の担当のように「あるかないか」で判定できる項目は、人が読む前にスクリプトで見つけられます。 要件定義書の Markdown の表を読み、次の9つを調べる Python のスクリプトを作りました。

スクリプトの全文です。表の1列目が FR-01 のような ID の行だけを読みます。機能一覧は「要件ID・機能・使う人・優先度・業務要件」、受け入れ基準は「基準ID・要件ID・受け入れ基準」の列の順を前提にしています。

"""要件定義書（Markdown の表）を読み、抜けとあいまいな言葉を探す。"""
import re, sys
from collections import Counter

VAGUE = ["など", "等", "適切", "適宜", "柔軟", "高速", "迅速", "使いやすい",
         "わかりやすい", "分かりやすい", "できるだけ", "なるべく", "速やかに", "十分"]
NUM = ("可用性", "性能・拡張性", "運用・保守性")  # 数値で書く大項目
ID = re.compile(r"^(BR|FR|NFR|R|AC-\d+|SC|RP|ML|IF|MG|Q)-\d+$")

def rows(text):
    for line in text.splitlines():
        if line.startswith("|") and not re.match(r"^|[-| :]+|$", line):
            cells = [c.strip() for c in line.strip().strip("|").split("|")]
            if ID.match(cells[0]):
                yield cells

def main(path):
    text = open(path, encoding="utf-8").read()
    rs = list(rows(text)); probs = []
    ids = Counter(r[0] for r in rs)
    probs += [f"[1] ID が重なっている: {i}（{n}回）" for i, n in ids.items() if n > 1]
    br = {r[0] for r in rs if r[0].startswith("BR-")}
    fr = {r[0]: r for r in rs if r[0].startswith("FR-")}
    ac = [r for r in rs if r[0].startswith("AC-")]
    used = set()
    for i, r in fr.items():
        if r[3] not in ("Must", "Should", "Could"):
            probs.append(f"[2] {i} の優先度が無い・形が違う: '{r[3]}'")
        refs = set(re.findall(r"BR-\d+", r[4])); used |= refs
        if not refs: probs.append(f"[3] {i} が業務要件を指していない")
        for x in refs - br: probs.append(f"[3] {i} が無い業務要件 {x} を指している")
    probs += [f"[4] {b} を指す機能要件が無い" for b in sorted(br - used)]
    have = {r[1] for r in ac}
    probs += [f"[5] Must の {i} に受け入れ基準が無い" for i, r in fr.items() if r[3] == "Must" and i not in have]
    probs += [f"[6] {r[0]} が無い機能要件 {r[1]} を指している" for r in ac if r[1] not in fr]
    for r in rs:
        if r[0].startswith(("FR-", "AC-", "NFR-", "BR-", "R-")):
            for w in VAGUE:
                if w in " ".join(r[1:]): probs.append(f"[7] {r[0]} にあいまいな言葉「{w}」")
    for r in rs:
        if r[0].startswith("Q-") and (len(r) < 4 or not r[2] or not r[3]):
            probs.append(f"[8] 未決事項 {r[0]} に担当か期限が無い")
        if r[0].startswith("NFR-") and r[1] in NUM and not re.search(r"\d", r[2]):
            probs.append(f"[9] {r[0]} に数値が無い")
    kinds = Counter(re.sub(r"-\d+$", "", r[0]).split("-")[0] for r in rs)
    print("読んだ ID:", " ".join(f"{k}={v}" for k, v in sorted(kinds.items())))
    print("Must の機能要件:", sum(r[3] == "Must" for r in fr.values()), "件 / 受け入れ基準:", len(ac), "件")
    for p in probs: print(" ", p)
    print("指摘:", len(probs), "件")
    return 1 if probs else 0

sys.exit(main(sys.argv[1]))

レビュー前の下書きでは12件、サンプルでは0件

この記事のサンプルの章をそのまま取り出したファイルと、そこによくある抜け（業務要件の ID の書き間違い、優先度の書き忘れ、受け入れ基準の削除、「高速」「適宜」などの言葉、担当の無い未決事項）を入れた下書きのファイルに、スクリプトを通しました。下書きの結果です。

$ python3 reqlint.py draft.md
読んだ ID: AC=16 BR=4 FR=12 IF=3 MG=4 ML=3 NFR=16 Q=3 R=6 RP=3 SC=10
Must の機能要件: 8 件 / 受け入れ基準: 16 件
  [1] ID が重なっている: AC-06-1（2回）
  [3] FR-11 が無い業務要件 BR-05 を指している
  [2] FR-12 の優先度が無い・形が違う: ''
  [4] BR-04 を指す機能要件が無い
  [5] Must の FR-08 に受け入れ基準が無い
  [7] AC-02-1 にあいまいな言葉「など」
  [7] AC-02-1 にあいまいな言葉「使いやすい」
  [7] NFR-04 にあいまいな言葉「高速」
  [7] NFR-07 にあいまいな言葉「適宜」
  [9] NFR-04 に数値が無い
  [9] NFR-07 に数値が無い
  [8] 未決事項 Q-03 に担当か期限が無い
指摘: 12 件

[4] BR-04 を指す機能要件が無い は、棚卸の時間を短くする目標（BR-04）に、つながる機能が1つも無い状態です。FR-11 の ID の書き間違い（BR-05）と、FR-10 から BR-04 が消えたことが重なって起きました。人が読むと見落としやすい抜けです。

サンプルの結果です。終了コードは、指摘があると1、無いと0にしています。

$ python3 reqlint.py sample.md
読んだ ID: AC=17 BR=4 FR=12 IF=3 MG=4 ML=3 NFR=16 Q=3 R=6 RP=3 SC=10
Must の機能要件: 8 件 / 受け入れ基準: 17 件
指摘: 0 件

このサンプルも、最初に通したときは [9] NFR-03 に数値が無い が1件出ました。「翌営業日の始業までに直す」と書いていたためで、「翌営業日の8時30分までに直す」と時刻で書き直しています。スクリプトで見つけられるのは「あるかないか」までです。目標の数値が業務に合っているか、受け入れ基準が業務ルールをすべて覆っているかは、人のレビューで確かめます。

非機能要件の書き方（IPA非機能要求グレードとの対応）

この節では、非機能要件をもれなく書くための観点と、サンプルの数値の決め方が分かります。

非機能要件は、IPA の「非機能要求グレード」の6つの大項目を観点の一覧として使うと、抜けを減らせます。 IPA の資料では、6つの大項目を次のように説明しています。各項目は、実現の難しさやコストの差に応じて、レベル0〜5の最大6段階で示されます。

非機能要求グレード2018 には、社会への影響の大きさで分けた3つのモデルシステム（「社会的影響が極めて大きいシステム」「社会的影響が限定されるシステム」「社会的影響が殆ど無いシステム」）が示されています。社内の備品貸出は、止まっても紙で代わりができるので、いちばん軽い区分を目安にして数値を決めました。各項目の一覧と定義書の型は、関連記事「非機能要件一覧｜IPA非機能要求グレード6大項目と定義書テンプレート」で扱っています。

サンプルの数値を、計算と実測で確かめた

非機能要件の数値は、計算か実測で「達成できるか」「業務に合うか」を確かめてから書きます。 稼働率は、使う時間（平日10.5時間×月20日＝210時間）から、止まってよい時間を計算しました。

性能（NFR-04・NFR-06）は、備品450点と貸出5年分（18,000件）のデータを SQLite に作り、「ある分類で、ある期間に空いている備品」を探す問い合わせを200回測りました。

データベースの検索は、目標の2秒に対して小さな値でした。この規模なら、2秒の目標で効いてくるのはデータ量より、画面の表示や通信のほうです。数値の根拠（件数・測った条件）は、要件定義書の別紙に残すと、後で数値を変えるときに判断できます。

要件定義のヒアリングで使える質問

この節では、要件定義書の各章を埋めるために、業務の担当者へ聞く質問の例が分かります。

「どんな機能がほしいですか」とだけ聞くと、今の業務をそのまま置き換えた要望ばかりになります。 課題と目的から聞き、機能は開発する側から提案します。

要件定義書のレビューの観点チェックリスト

この節では、承認の前に確かめる観点を、チェックリストで確かめられます。

• 1目的が数値か具体的な状態で書かれているか背景の数字と同じ単位の目標になっているか
• 2対象範囲と対象外が書かれているかWon't（今回は作らない）も一覧にあるか
• 3すべての機能要件に要件ID・優先度・業務要件の ID があるかどの業務要件にもつながらない機能は無いか
• 4Must の機能要件に受け入れ基準があるか例外の条件（上限・期限・重なり）まで書いてあるか
• 5業務ルールの境目に例があるかちょうど14日・ちょうど10万円のときの扱い
• 6非機能要件の6大項目をすべて確かめたか数値と、測る条件（人数・データ量）がセットか
• 7外部連携の相手・方式・タイミングが書かれているか相手の部署の担当が決まっているか
• 8移行するもの・時期・確かめ方が書かれているか移さないものも書いてあるか
• 9未決事項に担当と期限があるか決まっていないことを決まったように書いていないか
• 10用語集と本文の言葉がそろっているか同じものを別の言葉で呼んでいないか
• 11業務の担当者と承認者の両方が読んだか版・承認者・承認日が残っているか

要件定義書のよくある失敗と対策

この節では、要件定義書で起きやすい失敗と、後で起きることが分かります。

IPA・デジタル庁の公開資料と要件定義書の対応

この節では、要件定義書の型として参照できる公的な資料と、何に使えるかが分かります。

サンプルやテンプレートの下敷きとして、IPA とデジタル庁が資料を公開しています。 いずれも公式のページで入手でき、時点は確認日（2026年10月24日）のものです。

IPA の2つの資料は、IPA のサイトでアーカイブとして公開されています（非機能要求グレードの情報の基準時点は2023年8月）。非機能要求グレードの資料は、PDF 形式と表計算の形式で使用条件が分かれていて、表計算の形式は使用条件を添えれば改変・再配布ができると書かれています。使う前に使用条件のページを読みます。

生成AIで要件定義書を作るときの注意

この節では、生成 AI に下書きを手伝わせるときに気をつけることが分かります。

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

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

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

よくある質問

Q. 要件定義書のサンプルはどこで手に入りますか？ A. この記事の「要件定義書のサンプル」に、表紙から第9章まで1冊分を載せています。公的な型としては、デジタル庁の標準ガイドラインの各種テンプレートに「要件定義書標準テンプレート」があります。

Q. 要件定義書の書き方の順番は？ A. 目的と範囲 → 業務の流れと業務ルール → 機能一覧と受け入れ基準 → 非機能要件と移行 → レビューと承認、の順です。機能から書き始めると、目的に合わない機能が混ざりやすくなります。

Q. 要件定義テンプレートはそのまま使えますか？ A. 目次はそのまま使えますが、システムに要らない章は「対象外」「要件なし」と書いて残すほうが、確かめた跡が残ります。この記事のテンプレートは、各章に書くことをコメントで入れてあります。

Q. 要件定義書サンプルの分量はどのくらいが目安ですか？ A. 決まった分量はありません。この記事のサンプルは、業務要件4件・機能要件12件・非機能要件16件の小さなシステムです。件数が増えたら、本文は文書、一覧は表で持つ形にすると読みやすくなります。

Q. 要件定義書は誰が書きますか？ A. 決めて承認するのは発注する側です。実際には、開発会社や社内のシステム担当がヒアリングと提案をして文書にまとめ、発注する側が読んで承認する形が多くあります。

Q. 要件定義書と RFP（提案依頼書）の違いは？ A. RFP は、発注する側が開発会社を選ぶために「こういう提案がほしい」と伝える文書です。要件定義書は、開発会社が決まった後に、両者で詳しく決めて合意する文書です。

Q. 要件定義書と基本設計書の違いは？ A. 要件定義書は「何を・どこまで作るか」、基本設計書は「外から見てどう動くか（画面・データ・連携の形）」を書きます。画面の項目の配置は基本設計書に書きます。

Q. 機能要件と非機能要件の違いは？ A. 機能要件は「何ができるか」（例：貸出を申請できる）、非機能要件は「どのくらいの品質で動くか」（例：検索は2秒以内、稼働率99.5%以上）です。

Q. 受け入れ基準はどう書きますか？ A. 「〜すると〜になる」「〜の場合は〜と出る」の形で、正常な場合と、業務ルールごとの例外の場合を書きます。境目は日付や金額の例で示すと、そのままテストにできます。

Q. 要件定義書を作った後に要件が変わったら？ A. 変更の内容・理由・影響（費用・期限）を書き、承認を得てから版を上げます。変更履歴の表に、版・日付・内容・承認者を残します。

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

Q. 要件定義にはどのくらいの期間がかかりますか？ A. 規模で大きく変わります。サンプルでは、2か月（2026年11月〜12月）を要件定義に当てました。ここを短くしすぎると、後の工程で手戻りが増えます。

まとめ

• 要件定義書は、システムで「何を・どこまで作り、何ができたら完成か」を、発注する側と開発する側が合意する文書。
• サンプルの9章（はじめに・業務要件・機能要件・画面・データ・外部連携・非機能要件・移行・受け入れと未決事項）を、そのまま目次の型として使える。
• 目的は数値で、範囲は対象外まで書く。機能要件には要件ID・優先度・業務要件の ID・受け入れ基準を付ける。
• 受け入れ基準を境目の例つきで書くと、そのままテストになる。サンプルでは「最長14日」の読み違いが、テストで1件見つかった。
• 非機能要件は IPA の6大項目で抜けを確かめ、数値は計算か実測で確かめてから書く。
• 決まっていないことは未決事項にし、担当と期限を付ける。

次に読むとよい記事です。要件定義書の次の工程は、関連記事「基本設計書の書き方｜項目・記入例とレビューの観点」で、非機能要件の項目の全体は、関連記事「非機能要件一覧｜IPA非機能要求グレード6大項目と定義書テンプレート」で扱っています。

参考・出典

確認日はいずれも 2026年10月24日です。

• IPA「非機能要求グレード」：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/index.html
• IPA「非機能要求グレード2018」ダウンロード：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• IPA「非機能要求グレード本体（日本語版）」使用条件：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b-1.html
• IPA「非機能要求グレード2018 改訂情報～初版との差異～」：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000066170.pdf
• IPA「経営に活かす IT 投資の最適化」第2版：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000004568.pdf
• IPA「ユーザのための要件定義ガイド 第2版」：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html
• デジタル庁「デジタル社会推進標準ガイドライン」：https://www.digital.go.jp/resources/standard_guidelines
• pytest ドキュメント：https://docs.pytest.org/
• Python ドキュメント「sqlite3」：https://docs.python.org/ja/3/library/sqlite3.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。