要件定義とは｜意味・目的・進め方と要件定義書の成果物を実物で解説

要件定義は「決める工程」です。どんな画面にするか（設計）やどう書くか（実装）の前に、「誰が何に困っていて、システムが何をすれば解決か」を文書にして、関係者が合意します。

flowchart TD
    K[企画・要求定義<br>何のために・誰が困っているか] --> Y[要件定義<br>何を作るか・どこまで作るか]
    Y --> B[基本設計<br>どう見えるか・どう動くか]
    B --> D[詳細設計・実装]
    D --> T[テスト]
    Y -. 受け入れ基準が<br>そのままテストになる .-> T

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、題材（社内の弁当注文アプリ）のヒアリングメモ・要求一覧・要件一覧・受け入れ基準を CSV として自分で書き、抜けと曖昧語を調べる Python 3.13.18 のスクリプトを実行しました。曖昧な要件を2通りに解釈したコードは pytest 9.1.1 で実行し、失敗と成功の原文を載せています。要件定義の全体像と非機能要件の項目は、IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」と「非機能要求グレード2018」の公開ページで確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

要件定義とは（意味と目的）

この節では、要件定義という言葉の意味と、何のためにやるのかが分かります。

要件定義とは、これから作るシステムが「何をするか」「どこまでやるか」「どれくらいの品質か」を文書にし、頼む側（業務部門・発注者）と作る側（開発チーム）が合意する工程です。 「要件」は「満たすべき条件」という意味で、システムが満たすべき条件を定めるので「要件定義」と呼びます。英語では requirements definition、または requirements engineering（要求工学）の一部として扱われます。

目的は2つです。

• 実現する姿を決める：できあがったときに、誰が、どの画面で、何をできるようになっているか。
• 範囲（スコープ）を決める：何を作り、何を作らないか。「作らないこと」を書くのも要件定義の仕事です。

IPA の「ユーザのための要件定義ガイド 第2版」は、システム開発の遅延の過半は要件定義の失敗にあると述べ、業務部門のユーザが主体的に関わる要件定義へ転換する必要があると書いています。作る側だけで決める工程ではなく、使う側が決める工程です。

要望・要求・要件の違い

要求と要件の違い、要求定義の書き方は、関連記事「要求と要件の違い｜要求定義と要件定義の書き方と例」で扱っています。この記事は、その前後も含めた全体像と進め方に絞ります。

要求定義・基本設計との違い（工程の中の位置）

この節では、要件定義が前後の工程と何が違うのかが分かります。

要求定義は「困りごとと望み」を集める工程、要件定義は「システムが満たす条件」に落とす工程、基本設計は「どう見えるか・どう動くか」を決める工程です。 同じ「締め切り」でも、工程ごとに書く内容が変わります。

RFP・仕様との関係

外部に開発を頼むときは、要件定義の前に RFP（提案依頼書）を出すことがあります。RFP は「こういう目的で、この範囲のシステムを作りたい。提案と見積もりを出してほしい」という依頼で、要求一覧と範囲・制約が主な中身です。選定したあと、依頼先と一緒に要件定義を行い、要件定義書を検収の基準にします。「仕様」は要件を具体化した取り決めで、基本設計以降で決まることが多い言葉です。要件は「何を満たすか」、仕様は「どう振る舞うか」と覚えておくと、文書の名前に迷いません。

基本設計の書き方と記入例は、関連記事「基本設計書の書き方｜項目・記入例とレビューの観点」で扱っています。

要件定義の進め方（5つの段階）

この節では、要件定義を何から始めて何で終えるかが分かります。

「聞く→要求一覧→要件→画面と受け入れ基準→合意」の5段階です。 小さな社内システムでも大きな基幹システムでも、段階は同じで、かける時間と文書の厚さが違うだけです。

ヒアリングで何を聞くかの一覧は、関連記事「要件ヒアリングの質問一覧60項目｜シートのテンプレートと記入例」で扱っています。

参加する人と役割

要件定義が長引く原因で多いのは「決める人が会議にいない」ことです。最初に、誰がどの役割かを決めておきます。

要件定義で要る力

• 聞く力：答えをもらうのではなく、今の手順と例外と数字を引き出す。「いつまで？」「それが起きたらどうしている？」と聞き返せるか。
• 書く力：聞いたことを「誰が・何を・できる」の形にそろえ、2 人が読んで同じテストを書ける文にする。
• 決めてもらう力：未決事項を「誰が・いつまでに」の形にして、決める人の前に出す。決められない項目は「決まるまで作らない」と線を引く。

以下の節では、この5段階を小さな題材で実際にやって、できた成果物をそのまま載せます。

題材：社内の弁当注文アプリ（ヒアリングのメモ）

この節では、題材の前提と、段階1のヒアリングメモの実物が分かります。

題材は社員80名の会社の「弁当注文アプリ」です。 今は毎朝 Slack と口頭で注文が集まり、総務が Excel に転記して 10 時に弁当屋へメールで発注しています。総務の担当者に 30 分聞いたメモが次です。整えずに、聞いたままの言葉で残しています。

# ヒアリングメモ（2026-10-29 総務・田中さん 30分）

- 毎朝 9:30 ごろに Slack と口頭で注文が来る。総務が Excel に転記して 10 時に弁当屋へメールで発注
- 転記ミスで数が合わないことが月に 2〜3 回。足りない・余るどちらもある
- 弁当は A（のり弁 500円）・B（日替わり 600円）・C（サラダ 450円）の 3 種類。たまに増える
- 「締め切りまでに注文できるようにしたい」「締め切り後は変えられないようにしてほしい」
- 支払いは月末に給与天引き。だれが何個頼んだかを月末に集計している（Excel で 1 時間くらい）
- 出張や在宅の人は頼まない。社員は 80 名くらい、1 日に 30〜40 食
- スマホから頼みたいという声が多い。PC を持っていない人（工場の人）もいる
- 弁当屋さんは FAX でもメールでもいい。今はメール
- 「取り消しもできると助かる」（いつまで？→ 聞き忘れ）
- 予算はあまりない。社内の人が作る前提。できれば 2 か月で

この段階で大切なのは、数字（月に 2〜3 回・1 時間・30〜40 食）と、聞き忘れ（取り消しはいつまで）をそのまま残すことです。数字はあとで非機能要件と効果の根拠になり、聞き忘れは未決事項の種になります。

要求一覧を書く（誰が・何を・なぜ）

この節では、段階2でメモを要求一覧にした実物と、書くときの決まりが分かります。

要求一覧は「誰が・何を・なぜ」と「出どころ」を1行にしたものです。 メモの言葉を、主語と理由のある文に直します。弁当屋の要求は本人に聞いていないので「推測（要確認）」と明記しました。

要求が多いときの優先順位の付け方（MoSCoW）は別の記事で扱っていますが、この題材では 7 件なので全部「必須」として進めます。

機能要件と非機能要件に分ける

この節では、段階3で要求を要件に落とした実物と、機能要件・非機能要件の違いが分かります。

機能要件は「システムが何をできるか」、非機能要件は「それをどれくらいの品質で行うか」です。 次は最初に書いた版（v1）です。あとで抜けと曖昧語を見つけて直すので、まずは素直に書いた状態を載せます。

機能要件（v1）

非機能要件（v1）

要件の文は「誰が（主語）・何を・できる／する」の形にそろえると、あとで画面と受け入れ基準に割り当てやすくなります。主語が「システム」になる要件（FR-05）は、人が操作しない自動処理です。

機能要件のうち「ID・優先度・受け入れ基準を要件定義書にどう書くか」は、関連記事「要件定義書のサンプル｜書き方・テンプレートと全9章の記入例」で、文書全体の章立てとともに扱っています。

画面一覧と成果物の一覧

この節では、段階4で要件を画面に割り当てた実物と、要件定義で作る成果物の一覧が分かります。

画面一覧は、要件を「どの画面で満たすか」に割り当てた表です。 画面の数が見えると、作る量と期間の見積もりができます。この題材では 6 画面＋1 つの自動処理になりました。

要件定義の成果物

受け入れ基準を書く（テストになる形）

この節では、要件ごとの受け入れ基準の実物と、書き方の型が分かります。

受け入れ基準は「この条件で（Given）・こうすると（When）・こうなる（Then）」の3つを書いた文で、そのまま受け入れテストのケースになります。 要件が「できる」で終わっているのに対し、受け入れ基準は具体的な値と結果を書きます。

境界の値を必ず入れる

受け入れ基準で最初に書くべきなのは、ふつうの操作ではなく境界です。「できる」の端と「できない」の端を 1 つずつ書くと、要件の曖昧さがその場で見つかります。この題材で書いた境界は次のとおりです。

ここで気づくことがあります。AC-04 を書いたのはテスト担当で、「10 時まで」を「10:00:00 はもう締め切り後」と読みました。 要件 FR-03 の「締め切りまでに」は、それを決めていません。この食い違いが設計とテストで何を起こすかは、2 つあとの節で実際に動かして見せます。

抜けと曖昧語をスクリプトで確かめた結果

この節では、要求・要件・受け入れ基準の3つの表をつき合わせて、抜けと曖昧語を機械的に見つけた実物が分かります。

要件定義のレビューで見つけやすい抜けは3種類あります。「要件のない要求」「受け入れ基準のない要件」「曖昧語の入った要件」です。 3つの CSV を読んで調べる 30 行ほどの Python スクリプトを書き、v1 に対して実行しました。

import csv, re, sys, pathlib
d = pathlib.Path(sys.argv[1])
rd = lambda n: list(csv.DictReader(open(d / n, encoding="utf-8")))
requests, reqs, acs = rd("requests.csv"), rd("requirements.csv"), rd("acceptance.csv")
VAGUE = ["速やか", "適切", "柔軟", "など", "できる限り", "十分", "必要に応じて", "使いやすい", "まで"]
ng = 0
covered = {r for q in reqs for r in q["requests"].split(";") if r}
for q in requests:
    if q["id"] not in covered:
        print(f"NG 要件がない要求: {q['id']} {q['request']}"); ng += 1
with_ac = {a["requirement"] for a in acs}
for q in reqs:
    if q["id"] not in with_ac:
        print(f"NG 受け入れ基準がない要件: {q['id']} {q['requirement']}"); ng += 1
    hit = [w for w in VAGUE if w in q["requirement"]]
    if hit:
        print(f"NG 曖昧語 {hit}: {q['id']} {q['requirement']}"); ng += 1
    if q["kind"] == "非機能" and re.search(r"表示|応答|処理|同時", q["requirement"]) and not re.search(r"\d", q["requirement"]):
        print(f"NG 数値がない性能の要件: {q['id']} {q['requirement']}"); ng += 1
print(f"要求 {len(requests)} 件 / 要件 {len(reqs)} 件 / 受け入れ基準 {len(acs)} 件 / NG {ng} 件")

v1 に対する実行結果です。

$ python3 req_check.py v1
NG 要件がない要求: R-06 弁当の種類を自分で増やしたい
NG 受け入れ基準がない要件: FR-02 社員は自分の注文を取り消せる
NG 曖昧語 ['まで']: FR-03 社員は当日の締め切りまでに注文できる
NG 受け入れ基準がない要件: FR-06 総務は月ごとに社員別の注文数と金額をCSVで出力できる
NG 受け入れ基準がない要件: NFR-02 注文画面は速やかに表示される
NG 曖昧語 ['速やか']: NFR-02 注文画面は速やかに表示される
NG 数値がない性能の要件: NFR-02 注文画面は速やかに表示される
NG 受け入れ基準がない要件: NFR-03 平日8:00〜10:30の間は停止しない（計画停止はこの時間の外で行う）
NG 受け入れ基準がない要件: NFR-04 注文データは1年間保存する
NG 受け入れ基準がない要件: NFR-05 社内ネットワークからのみ利用できる
要求 7 件 / 要件 12 件 / 受け入れ基準 8 件 / NG 10 件

10 件の NG は、どれも人が読み直せば気づける抜けですが、表が 3 つに分かれていると見落とします。見つかったものを順に直しました。

v2 に同じスクリプトをかけた結果です。NFR-03 の「前日までに周知」も「まで」で引っかかったので、「前営業日の 17:00 より前に周知する」に直してから再実行しました。

$ python3 req_check.py v2
要求 7 件 / 要件 13 件 / 受け入れ基準 15 件 / NG 0 件

スクリプトの曖昧語の一覧は、自分の組織でよく出る言葉に入れ替えて使えます。「など」「柔軟に」「適切に」は、要件の文に入っていたら、ほぼ必ず誰かが聞きに戻ることになる言葉です。

曖昧な要件が設計・テストでどう壊れるか（FR-03 を追跡）

この節では、「締め切りまでに注文できる」という1つの要件が、設計と実装とテストでどう食い違い、何を作り直すことになるかが分かります。

v1 の FR-03「社員は当日の締め切りまでに注文できる」を、設計者は「10:00 を含む」と読み、テスト担当は「10:00:00 はもう締め切り後」と読みました。 どちらも日本語として間違っていません。設計者が書いた判定関数と、テスト担当が受け入れ基準 AC-03・AC-04 から書いたテストが次です。

# order_v1.py（設計者の解釈：「締め切りまで」= 10:00 を含む）
from datetime import datetime, time

DEADLINE = time(10, 0)

def can_order(now: datetime) -> bool:
    return now.time() <= DEADLINE

# test_order_v1.py（テスト担当の解釈：「10時まで」= 10:00:00 はもう締め切り後）
from datetime import datetime
from order_v1 import can_order

def test_ac03_before_deadline():
    assert can_order(datetime(2026, 10, 29, 9, 59, 59)) is True

def test_ac04_at_deadline():
    assert can_order(datetime(2026, 10, 29, 10, 0, 0)) is False

実行すると、AC-04 が失敗します。

$ python3 -m pytest test_order_v1.py -q
.F                                                                       [100%]
=================================== FAILURES ===================================
____________________________ test_ac04_at_deadline _____________________________

    def test_ac04_at_deadline():
        # テスト担当の解釈：「10時まで」= 10:00:00 はもう締め切り後
>       assert can_order(datetime(2026, 10, 29, 10, 0, 0)) is False
E       assert True is False
E        +  where True = can_order(datetime.datetime(2026, 10, 29, 10, 0))

test_order_v1.py:9: AssertionError
=========================== short test summary info ============================
FAILED test_order_v1.py::test_ac04_at_deadline - assert True is False
1 failed, 1 passed in 0.02s

このテスト失敗はバグではなく、要件の未決です。コードを直してもテストを直しても解決せず、「10:00:00 ちょうどをどうするか」を総務に決めてもらうしかありません。決まるまで、この機能の完了は止まります。

境界で何が起きていたか

2 つの解釈を 4 つの時刻で比べると、違うのは 10:00:00 の 1 秒だけです。この 1 秒を、設計者とテスト担当は別々に埋めていました。

設計への波及：定数か、設定か

食い違いはもう1つありました。v1 の設計者は締め切りをコードの定数 DEADLINE = time(10, 0) にしました。要件に「総務が変えられる」と書かれていなかったからです。ところが R-06（種類を増やしたい）を確認しに行ったときに、総務から「締め切りも日によって 9:30 にしたい」と出てきました。定数のままなら、変えるたびにプログラムを直して配布することになります。

v2 の要件に合わせて書き直した判定とテストです。タイムゾーン・取り消し・総務による変更も受け入れ基準どおりに確かめます。

# order_v2.py
from datetime import datetime, time
from zoneinfo import ZoneInfo

JST = ZoneInfo("Asia/Tokyo")

class Settings:
    """総務が管理画面で変える値（FR-07）。既定は 10:00"""
    def __init__(self, deadline: time = time(10, 0)):
        self.deadline = deadline

def can_order(now: datetime, settings: Settings) -> bool:
    # FR-03 v2：サーバー時刻（JST）が締め切り時刻「より前」なら受け付ける
    now = now.astimezone(JST)
    return now.time() < settings.deadline

def can_cancel(now: datetime, settings: Settings) -> bool:
    # FR-02 v2：取り消しも注文と同じ締め切り
    return can_order(now, settings)

$ python3 -m pytest test_order_v2.py -q
.....                                                                    [100%]
5 passed in 0.02s

要件定義の段階で「ちょうどは不可」「総務が変えられる」の 2 行を足していれば、設計は最初から設定テーブルと設定画面を含み、テストは境界値を迷わず書けました。曖昧な要件の代償は、工程が進むほど大きくなります。要件から設計・テストへの対応を表で追う方法は、トレーサビリティマトリクスの記事で扱っています。

非機能要件の項目表（IPA 非機能要求グレード）

この節では、非機能要件で抜けやすい項目を、IPA の分類で確かめる方法が分かります。

非機能要件は「言われないから書かない」になりやすく、障害やコスト超過の原因になります。 IPA の「非機能要求グレード2018」は、非機能要求を 6 つの大項目に分け、要求レベルを段階で示したもので、発注者と開発者の認識のずれを防ぐ目的で公開されています（事業は 2018 年度で終了し、資料はアーカイブとして公開中）。この題材の要件を 6 大項目に当てはめると、次のようになります。

「移行性」と「システム環境」は、小さなシステムでは「該当なし」と書くことが多い項目ですが、「該当なし」と書くのと、書かないのとでは違います。 書いてあれば確かめた印になり、書いていなければ誰も見ていない項目です。6 大項目それぞれの中項目と目標水準の決め方は、関連記事「非機能要件一覧｜IPA非機能要求グレード6大項目と定義書テンプレート」で扱っています。

よくある失敗と確かめ方・判断表

この節では、要件定義でよく起きる失敗と、それぞれを事前に見つける確かめ方が分かります。

失敗は「抜け」「曖昧」「合意なし」の3つに集約できます。 この記事の題材でも、v1 の時点で3つ全部が起きていました（R-06 の抜け・FR-03 の曖昧・取り消しの締め切りが未決のまま）。

変更の受け方（この題材で起きた例）

v1 の合意後に、総務から「締め切りを日によって 9:30 にしたい」と口頭で出てきました。この記事では次のように扱いました。要求 R-03 の「なぜ」に「弁当屋の都合で締め切りが日によって変わる」を追記し、要件 FR-07（R-06・R-03 を満たす）に「締め切り時刻（30 分単位）」を足し、画面 SCR-06 と受け入れ基準 AC-10 を追加し、期間への影響（画面 1 つぶん、約 3 日）を書いて総務課長に承認をもらい、文書の版を 1.1 にしました。口頭のまま作っていたら、画面一覧に無い画面がテストの直前に現れていました。変更そのものは悪いことではなく、記録されない変更が問題です。

どこまで細かく書くかの判断表

要件定義は、細かく書くほど良いわけではありません。書く深さは、作る人と使う人の距離で決めます。

• 1要求の全部に要件が付いているスクリプトで「要件がない要求」が 0 件
• 2要件の全部に受け入れ基準が付いている境界（ちょうど・0・上限）を含む
• 3曖昧語が残っていないまで・速やか・など・適切・柔軟・必要に応じて
• 4非機能の 6 大項目が全部埋まっている「該当なし」も書く
• 5対象外・前提・未決事項の節がある未決は「誰が・いつまでに決める」まで
• 6使う側・作る側・決める人の承認がある名前と日付。版番号を付ける

AI に下書きさせるときの使い方

この節では、要件定義で生成 AI をどこに使うと役に立ち、どこは人が決めるべきかが分かります。

AI が得意なのは「抜けの指摘」と「言い換えの候補出し」で、「決めること」は人の仕事です。 この記事の題材で試す順番は次のとおりです。

1. 1ヒアリングメモを渡して「聞き忘れ」を質問させる「取り消しはいつまで？」「締め切りちょうどは？」のような問いを出させる。答えるのは総務
2. 2要求一覧の下書きを作らせ、出どころを人が付けるAI が書いた「なぜ」は推測。推測のまま残さず、聞いて確かめる
3. 3要件の文から曖昧語を指摘させ、言い換え候補を 3 つ出させる「速やかに」→「3 秒以内」「5 秒以内」「10 秒以内」。どれにするかは人が決める
4. 4受け入れ基準の境界値を列挙させる09:59:59・10:00:00・10:00:01、数 0・1・5・6 のように漏れなく出させる
5. 5決定・未決・前提の表にまとめさせ、人が承認する承認の名前と日付は AI には書けない

AI に 1 回 1 問ずつ質問させて要件を整理するプロンプトの型は、関連記事「生成AI壁打ちプロンプト｜要件定義でAIに質問させる型」で扱っています。社外の情報や個人情報をメモごと AI に渡さないことは、使う前に組織の決まりで確かめます。

よくある質問

Q. 要件定義とは何ですか？ A. これから作るシステムが「何をするか・どこまでやるか・どれくらいの品質か」を文書にして、頼む側と作る側が合意する工程です。成果物は要求一覧・機能要件・非機能要件・画面一覧・受け入れ基準などです。

Q. 要件定義と要求定義の違いは何ですか？ A. 要求定義は「誰が何に困っていて何を望むか」を集めて整理する工程、要件定義はそれを「システムが満たすべき、確かめられる条件」に落とす工程です。要求は「転記ミスをなくしたい」、要件は「総務は当日の注文を種類ごとに集計した一覧を見られる」のように書きます。

Q. 要件定義と基本設計の違いは何ですか？ A. 要件定義は「何を」、基本設計は「どう見えるか・どう動くか」です。「締め切りより前なら注文できる」が要件、「注文画面に残り時間を表示し、締め切りは設定テーブルに持つ」が基本設計です。

Q. 要件定義は誰がやるのですか？ A. 決めるのは使う側（業務部門・発注者）、文書にして確かめるのは作る側（開発チーム）です。IPA のガイドも、業務部門のユーザが主体的に関わる要件定義への転換を求めています。作る側に任せきりにすると、作る側の推測で決まります。

Q. 要件定義の成果物には何がありますか？ A. 背景・目的・効果、範囲（やること・やらないこと）、業務フロー、要求一覧、機能要件・非機能要件、画面・帳票・バッチ一覧、データ項目の概要、外部連携、受け入れ基準、未決事項です。小さなシステムでは、要求一覧・要件一覧・画面一覧・受け入れ基準の 4 表から始めます。

Q. 機能要件と非機能要件の違いは何ですか？ A. 機能要件は「システムが何をできるか」（注文できる・集計を見られる）、非機能要件は「どれくらいの品質で」（3 秒以内・平日 8:00〜10:30 は止めない・13 か月保存）です。非機能要件は言われないので抜けやすく、IPA の 6 大項目で確かめます。

Q. 受け入れ基準はどう書けばよいですか？ A. 「この条件で（Given）・こうすると（When）・こうなる（Then）」を具体的な値で書きます。「サーバー時刻が 10:00:00 のとき注文を送ると、受け付けられず『締め切りを過ぎています』と出る」のように、境界の値を必ず入れます。

Q. 要件定義にはどれくらいの期間がかかりますか？ A. 全体の工期の 2〜3 割を目安にする考え方が多いですが、決める人が集まれる頻度で決まります。この記事の題材（2 か月の社内システム）なら、ヒアリング 2 回とレビュー 1 回で 2 週間ほどです。長引く原因の多くは「決める人が会議にいない」ことです。

Q. 要件が途中で増えたらどうすればよいですか？ A. 口頭で受けず、要求一覧に ID を付けて追加し、要件・画面・受け入れ基準への影響と期間への影響を書いて、承認者に判断してもらいます。承認した版には番号を付けます。「増やすなら何かを減らす」も選択肢です。

Q. アジャイル開発でも要件定義は必要ですか？ A. 文書の厚さは変わりますが、「何を・どこまで・どれくらいの品質で」を決めて合意することは変わりません。要求一覧（プロダクトバックログ）を育てながら、反復ごとに要件と受け入れ基準（完了の定義）を書きます。

Q. 「要件定義書」と「要件定義」は同じですか？ A. 要件定義は工程（活動）、要件定義書はその成果物（文書）です。要件定義書の章立てと記入例は別の記事で扱っています。

Q. 曖昧な要件かどうかは、どう見分けますか？ A. 2 人に別々に読ませて、同じテストを書けるかで見分けます。「まで」「速やかに」「など」「適切に」「柔軟に」「必要に応じて」が入っていたら、ほぼ必ず割れます。この記事では「締め切りまで」の 1 語で、設計者とテスト担当の解釈が 1 秒ぶん割れ、テストが失敗しました。

まとめ

• 要件定義とは、「何を作るか・どこまで作るか・どれくらいの品質か」を文書にして、頼む側と作る側が合意する工程。決めるのは使う側で、文書にして確かめるのは作る側。
• 要求定義は「困りごとと望み」、要件定義は「満たすべき条件」、基本設計は「どう見えるか・どう動くか」。同じ「締め切り」でも工程ごとに書くことが違う。
• 進め方は「聞く→要求一覧→機能要件・非機能要件→画面一覧と受け入れ基準→合意」の 5 段階。弁当注文アプリの題材では、要求 7 件・要件 13 件・画面 6 つ・受け入れ基準 15 件になった。
• 3 つの表をつき合わせるスクリプトで、v1 から「要件のない要求」「受け入れ基準のない要件」「曖昧語」の NG が 10 件見つかり、直した v2 で 0 件になった。
• 「締め切りまでに注文できる」の 1 語で、設計者（10:00 を含む）とテスト担当（含まない）の解釈が割れ、pytest が失敗した。直すのはコードでもテストでもなく要件。要件定義で 2 行足していれば、画面 1 つとコードの書き直しは起きなかった。

次に読むとよい記事です。要件定義書の章立てと記入例は「要件定義書のサンプル｜書き方・テンプレートと全9章の記入例」、要求と要件の書き分けは「要求と要件の違い｜要求定義と要件定義の書き方と例」、次の工程は「基本設計書の書き方｜項目・記入例とレビューの観点」で扱っています（いずれも本文中にリンクがあります）。

参考・出典

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

• IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版 ～要件定義を成功に導く128の勘どころ～」：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html
• IPA「ユーザのための要件定義ガイド 第2版」書籍・PDF の案内ページ：https://www.ipa.go.jp/archive/publish/tn20191220.html
• IPA「システム構築の上流工程強化（非機能要求グレード）」：https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• pytest 公式ドキュメント「How to invoke pytest」：https://docs.pytest.org/en/stable/how-to/usage.html
• Python 公式ドキュメント「zoneinfo — IANA time zone support」：https://docs.python.org/3/library/zoneinfo.html

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