要求と要件の違い｜要求定義と要件定義の書き方と例

要求は「関係者が求めていること（なぜ・何をしたいか）」、要件は「その要求を満たすために、システムが満たすべき条件を、確かめられる形で書いたもの」です。 要求は利用者や事業の言葉で書き、要件は開発と検収で使える言葉で書きます。1つの要求から、ふつうは複数の要件が生まれます。

確認環境：「要件（requirement）」の定義は、ISO/IEC/IEEE 29148:2018 の定義を引用している NIST の用語集で、要件の分類は IIBA の「The Business Analysis Standard」4.4節（BABOK Guide v3 を参照）の原文で確かめました。日本語の用語は IPA「ユーザのための要件定義ガイド 第2版」（2019年）の本文で、段階の分け方は Karl Wiegers のインタビュー記事（Dr. Dobb's Journal、2007年）の原文で確かめています。要求一覧・要件一覧の抜けを調べるスクリプトは Python 3.11.15（Linux）で動かし、図は Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0）で描画できることを確かめました（確認日 2026年10月13日）。

要求と要件の定義を原文で確かめる

英語では、要求も要件もふつう「requirement」1語です。 日本語では「要求」と「要件」を分けて使うため、どこで線を引くかが文書ごとに違って見えます。主な出典の言葉を並べると、次のようになります。

29148 と BABOK はどちらも、need（求めていること）を先に置き、requirement をそれを表したもの・言い換えたものとしています。 日本語の「要求＝need」「要件＝requirement」と対応づけると、違いが整理しやすくなります。

IPA の「ユーザのための要件定義ガイド 第2版」も、同じ向きで書かれています。

• 「ステークホルダから要求（What）を漏れなく抽出し、内容を見極め、新たなビジネスやシステムを創造する要件として定義する」（はじめに）
• 「『BR.ビジネス要求定義』で定義した要求を機能要件・非機能要件の観点で仕様化」（本ガイドの構成と想定読者）

つまり、要求を集めて見極めたものが要件で、要件は機能要件・非機能要件として書き分けます。

「要求」「要件」の呼び方は文書によって揺れる

同じものでも、文書によって呼び方が違います。プロジェクトの用語集で、どちらを使うかを決めておくと混乱が減ります。

BABOK の英語では「business requirements」ですが、日本語では「ビジネス要求」と訳されることが多く、IPA の非機能要求グレードは「要求」の語を使っています。語の違いより、「目的の段階か、システムの条件の段階か」で見分けるのが確実です。 非機能の項目は、関連記事「非機能要件一覧｜IPA非機能要求グレード6大項目と定義書テンプレート」で扱っています。

ビジネス要求・ユーザー要求・システム要件の3段階

要求と要件は、2つに分けるより、3段階で考えると落とし込みやすくなります。 Wiegers はインタビューで、次のように分けています。

• ビジネス要求（business requirements）："describe the business objectives for the project and address the question of why we're undertaking the project"（プロジェクトの事業上の目的、つまり「なぜやるのか」）
• ユーザー要求（user requirements）："describe what users will be able to do with the product"（利用者がプロダクトで何をできるようになるか）
• 機能要件（functional requirements）："describe what the developer must implement"（開発者が作るべきもの）

BABOK の分類（IIBA 4.4節）も、ほぼ同じ段階です。

flowchart TB
  BR["ビジネス要求<br>なぜやるのか（目的・目標）<br>例：空予約を減らし、会議室の追加賃借を避ける"]
  UR1["ユーザー要求<br>社員：空き会議室をすぐ探して予約したい"]
  UR2["ユーザー要求<br>総務：使われない予約を手作業なしで解放したい"]
  subgraph SR["システム要件（要件定義の範囲）"]
    FR["機能要件<br>空き会議室の一覧表示<br>未使用予約の自動取り消し"]
    NFR["非機能要件<br>検索は95%が2秒以内"]
    CON["制約<br>ログインは社内SSO"]
    TR["移行要件<br>Excelの予約を移す"]
  end
  BR --> UR1
  BR --> UR2
  UR1 --> FR
  UR1 --> NFR
  UR2 --> FR
  BR --> CON
  UR2 --> TR

上の段ほど「なぜ」、下の段ほど「何を・どの水準で」になります。 要求定義はビジネス要求とユーザー要求を、要件定義はシステム要件（機能・非機能・制約・移行）を決める工程と考えると、境目がはっきりします。

29148 の文書の名前との対応

ISO/IEC/IEEE 29148 の 2011年版の目次には、要求・要件を書く文書として次の3つが並んでいます。

なお、ISO のページでは、現行の 29148 は 2018年の第2版で、「改訂中（to be revised）」の段階にあり、次の版（DIS）に置き換わる予定と書かれています（2026年10月13日時点）。

要求定義と要件定義の違い（工程として）

IPA のガイドは「要件定義は利用部門（ユーザ）の責任」と書いています（改訂にあたって）。要件定義は開発側だけの仕事ではなく、要求を持つ側が最後まで関わる工程です。

業務の現状と目指す姿の整理は関連記事「As-Is/To-Be分析のやり方｜業務フローと課題整理テンプレート」で、要件定義書の全体の書き方は「要件定義書の書き方｜記入例と要件ID・受け入れ基準」で扱っています。

要求から要件への落とし込み方（5つの手順）

flowchart LR
  A["1 要求を集める<br>ヒアリング・観察"] --> B["2 なぜを問う<br>ビジネス要求に結ぶ"]
  B --> C["3 解決策を選ぶ<br>1つの要求→複数の要件"]
  C --> D["4 確かめられる形で書く<br>数値・条件・受け入れ基準"]
  D --> E["5 IDでつなぐ<br>要件→要求の追跡"]
  E -.見直し.-> B

1. 要求を集める：利用者・業務担当・運用担当から、困りごとと、やりたいことを聞きます。聞く項目は、関連記事「要件ヒアリングの質問一覧60項目｜シートのテンプレートと記入例」で扱っています。
2. 「なぜ」を問い、ビジネス要求に結ぶ：「スマホで予約したい」と言われたら「なぜ？」と聞きます。答えが「席を離れた場所で会議が決まるから」なら、本当の要求は「その場で空きを確かめて押さえたい」です。どのビジネス要求にも結びつかない要求は、優先度を下げる候補になります。
3. 解決策を選ぶ：要求の中には、解決策が混じっていることがあります（「Excel のマクロで自動化したい」など）。手段は要件の段階で選び直せるように、要求は目的の形に戻します。
4. 確かめられる形で書く：「速く」「使いやすく」は人によって読み方が変わります。数値・条件・例で書き、受け入れ基準（合格の条件）を添えます。
5. ID でつなぐ：要件ごとに、元の要求の ID を書きます。要求から要件、設計、テストまでのつながりは、関連記事「トレーサビリティマトリクスの作り方 要件・設計・テスト対応表」で扱っています。

記入例：会議室予約システム

社員 約500名の会社で、会議室が足りないという声が出ています。調べると、予約されたのに使われない「空予約」が多いことが分かりました。数字は説明のための仮の値です。

ビジネス要求

ユーザー要求

優先度は MoSCoW（Must・Should・Could・Won't）で付けています。付け方は関連記事「MoSCoW分析のやり方｜要件の優先順位付けの例と判定シート」で扱っています。

システム要件（要件一覧）

UR-02 の「手作業なしで解放したい」は、FR-03 の「15分を過ぎたら自動で取り消す」という具体的な条件になりました。 「15分」は、要求を出した総務部と合意して決める値です。要求の段階では決まっていなかった数字を、要件の段階で決める。ここが要求定義と要件定義のいちばんの違いです。

FR-03 のように、1つの要件を開発の単位に分けると、ユーザーストーリーやチケットになります。書き方は、関連記事「ユーザーストーリーの書き方と例30選｜受け入れ基準Given-When-Then」で扱っています。

機能要件・非機能要件との関係

機能要件と非機能要件は、どちらも「要件」の側の分け方です。 要求の段階では、まだ機能か非機能かを分けないことも多くあります。UR-01 から、機能要件（FR-01・FR-02）と非機能要件（NFR-01・NFR-02）の両方が生まれているのがその例です。

機能要件を画面や処理の単位で一覧にする方法は、関連記事「機能一覧の書き方とテンプレート 機能IDの採番と粒度の決め方」で扱っています。

要求一覧・要件一覧のテンプレート

表計算ソフトにそのまま貼れる CSV の形です。1行目が見出しです。

要求一覧

要求ID,種類,要求,出所,優先度
BR-01,ビジネス要求,（なぜやるのか。目的と目標の数値）,（責任者の名前）,Must
UR-01,ユーザー要求,（〇〇として、〜したい。なぜなら〜）,（ヒアリング・アンケートなど）,Must
UR-02,ユーザー要求,,,

要件一覧

要件ID,要求ID,種類,要件,受け入れ基準
FR-01,UR-01,機能要件,（システムが何をするか。主語はシステム）,（合格の条件。具体的な値や例）
NFR-01,UR-01,非機能要件,（どの水準で。数値で）,（測り方と合格の値）
CON-01,BR-01,制約,（選べない前提）,（確かめ方）
TR-01,UR-05,移行要件,（移行の条件）,（確かめ方）

ID の頭文字は、種類が分かるようにそろえます（BR：ビジネス要求、UR：ユーザー要求、FR：機能要件、NFR：非機能要件、CON：制約、TR：移行要件）。要件定義書での ID の付け方は、関連記事「要件定義書の書き方｜記入例と要件ID・受け入れ基準」で扱っています。

抜けを調べるスクリプト

2つの一覧を読み、次の4つを調べる Python のスクリプトです。

• 要件の「要求ID」が、要求一覧にあるか（親のない要件）
• 受け入れ基準が空になっていないか
• 「速く」「使いやすい」など、人によって読み方が変わる語がないか
• 要件に落ちていないユーザー要求がないか

import csv, re, sys

reqs = {r["要求ID"]: r for r in csv.DictReader(open(sys.argv[1], encoding="utf-8"))}
sols = list(csv.DictReader(open(sys.argv[2], encoding="utf-8")))
VAGUE = ["速く", "使いやすく", "使いやすい", "適切に", "柔軟に", "なるべく", "など", "等"]
errors = []

for s in sols:
    sid = s["要件ID"]
    if s["要求ID"] not in reqs:                       # 親の要求がない
        errors.append(f"{sid}: 要求ID {s['要求ID']} が要求一覧にない")
    if not s["受け入れ基準"].strip():                 # 確かめ方がない
        errors.append(f"{sid}: 受け入れ基準が空")
    words = [w for w in VAGUE if w in s["要件"]]
    if words:                                        # 人によって読み方が変わる語
        errors.append(f"{sid}: あいまいな語 {words}")

used = {s["要求ID"] for s in sols}
for rid, r in reqs.items():
    if r["種類"] == "ユーザー要求" and rid not in used:  # 要件に落ちていない要求
        errors.append(f"{rid}: 対応する要件がない（{r['優先度']}）")

print("\n".join(errors) if errors else "OK")
print(f"要求 {len(reqs)} 件 / 要件 {len(sols)} 件 / 指摘 {len(errors)} 件")

書きかけの版（通知の受け入れ基準が空、検索の性能が「速く表示する」、移行要件の親が UR-09 という書き間違い、UR-04 に対応する要件がない）で動かした結果です。

$ python3 check_req.py youkyu.csv youken.csv
FR-04: 受け入れ基準が空
NFR-01: 受け入れ基準が空
NFR-01: あいまいな語 ['速く']
TR-01: 要求ID UR-09 が要求一覧にない
UR-04: 対応する要件がない（Could）
要求 5 件 / 要件 8 件 / 指摘 5 件

NFR-01 を「95%の検索で2秒以内」に直し、受け入れ基準を埋め、UR-05 を要求一覧に足し、UR-04 に FR-05 を対応させた版（上の記入例の表と同じ内容）では、次のようになりました。

$ python3 check_req.py youkyu2.csv youken2.csv
OK
要求 6 件 / 要件 9 件 / 指摘 0 件

「等」は「同等」のような語にも当たるため、指摘は人が見て判断します。あいまいな語の一覧は、チームでよく出る語に合わせて増やせます。

よくある誤り

よくある質問

Q. 「要求定義」と「要件定義」は、別の工程として分けるべきですか。 A. 規模によります。IPA のガイドは、ビジネス要求定義（BR）とシステム化要求定義（SR）を別の章として扱っています。小さな改修では、1つの文書の中で「要求」「要件」の欄を分けるだけでも、段階の違いは表せます。

Q. ユーザー要求とユーザーストーリーは同じものですか。 A. 近いものです。Wiegers の言うユーザー要求（利用者がプロダクトで何をできるか）を「〇〇として、〜したい。なぜなら〜」の型で書いたものが、ユーザーストーリーです。アジャイル開発では、ストーリーに受け入れ基準を添えて、要件の役目も持たせます。

Q. 要件はどこまで細かく書けばよいですか。 A. 目安は「受け入れ基準で合否が出せるところまで」です。画面の配置やテーブルの設計は、要件ではなく設計の段階で決めます。設計書との境目は、関連記事「基本設計書の書き方｜項目・記入例とレビューの観点」で扱っています。

Q. 要件が決まったあとに要求が変わったらどうしますか。 A. 要求 ID から、影響を受ける要件をたどれます。変更の受け付けと記録のしかたは、関連記事「仕様変更の管理方法 変更管理表テンプレートと変更要求フロー」で扱っています。

まとめ

• 要求は「求めていること（need）」、要件は「それを満たす条件を確かめられる形で書いたもの（requirement）」
• 29148 は要件を「need と制約・条件を表した記述」、BABOK は「need を使える形で表したもの」と定義している
• 段階は ビジネス要求（なぜ）→ ユーザー要求（誰が何をしたいか）→ システム要件（機能・非機能・制約・移行）
• 落とし込みは 集める → なぜを問う → 解決策を選ぶ → 確かめられる形で書く → ID でつなぐ
• 要件には 親の要求 ID と受け入れ基準 を必ず添える

参考・出典

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

• NIST Computer Security Resource Center「requirement - Glossary」（ISO/IEC/IEEE 29148:2018・IEEE Std 730-2014 の定義を引用）：https://csrc.nist.gov/glossary/term/requirement
• ISO「ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering」：https://www.iso.org/standard/72089.html
• ANSI Webstore「ISO/IEC/IEEE 29148:2011 プレビュー（目次）」：https://webstore.ansi.org/preview-pages/ISO/preview_ISO+IEC+IEEE+29148-2011.pdf
• IIBA「The Business Analysis Standard 4.4 Understanding Requirements and Designs」：https://www.iiba.org/knowledgehub/the-business-analysis-standard/4-implementing-business-analysis/4-4-understanding-requirements-and-designs/
• IPA「ユーザのための要件定義ガイド 第2版」：https://www.ipa.go.jp/publish/tn20191220.html
• Dr. Dobb's Journal「So What Are Requirements?」（Karl E. Wiegers へのインタビュー、2007年9月）：https://jacobfilipp.com/DrDobbs/articles/DDJ/2007/0709/070801cv01/070801cv01.html

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