情報処理試験を勉強していると、「要件定義って企画とどう違うの？」「機能要件と非機能要件の境目がわからない」と混乱しがちです。
この記事では、要件定義プロセスの全体像から業務要件・機能要件・非機能要件の違いまでを整理します。
対象試験と出題頻度
要件定義プロセスは、ITパスポート・基本情報技術者・応用情報技術者のすべてで出題されるテーマです。
「要件定義プロセスで実施すべき作業はどれか」「非機能要件に該当するものはどれか」といった問題が繰り返し出題されており、共通フレームの知識と合わせて正確に区別できるかが問われます。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
要件定義プロセス（Requirements Definition Process）とは、一言で言うと
「システムに求められる機能・性能・制約を利害関係者と合意して明文化する、開発の最上流工程」
のことです。
イメージとしては、「家を建てる前の設計打ち合わせ」です。
施主（利用者）が「リビングは20畳、南向き、犬が走れる庭付き」と要望を出し、設計士がそれを図面にまとめ、双方で「これで間違いないですね」と合意する。
この打ち合わせが要件定義プロセスに相当します。「リビングは20畳で南向き」が機能面の要望、「震度7でも倒壊しない」が性能面の要望にあたり、それぞれ機能要件・非機能要件として整理されます。
📊 要件定義プロセスの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Requirements Definition Process |
| 位置づけ | 共通フレーム2013のシステムライフサイクルプロセスのうち、企画プロセスの次に実施される工程 |
| 主な成果物 | 要件定義書（業務要件・機能要件・非機能要件を記載） |
| 定義する3つの要件 | 業務要件、機能要件、非機能要件 |
解説
システム開発では「企画 → 要件定義 → 開発 → 保守・運用」の順にプロセスが進みます。
企画プロセスでシステム化の方針と投資対効果を決めた後、「具体的に何を作るのか」を関係者全員で詰めるのが要件定義プロセスの役割です。
共通フレーム2013では、要件定義プロセスの作業として「利害関係者の識別」「利害関係者のニーズ・要望・制約条件の識別」「要件の合意と文書化」が規定されています。ここで定義される内容は、業務要件・機能要件・非機能要件の3つに分類されます。
3つの要件の違い
要件定義プロセスで定義する内容は明確に3つに分かれます。ここだけは確実に押さえてください。
| 要件の種類 | 定義する内容 | 具体例 |
|---|---|---|
| 業務要件 | 新しい業務の手順・ルール・組織・責任・権限・制約条件など、業務そのもののあり方 | 「受注から出荷まで48時間以内に完了する」「承認者は部長以上」 |
| 機能要件 | 業務要件を実現するためにシステムが備えるべき機能。入出力データの種類・画面・帳票・処理内容など | 「受注データを入力する画面」「在庫一覧を出力する帳票」 |
| 非機能要件 | 機能要件以外のすべて。可用性・性能・拡張性・運用性・保守性・移行性・セキュリティ・システム環境など | 「稼働率99.9%」「障害復旧時間4時間以内」「開発言語はJava」 |
図解：要件定義プロセスの位置づけと3要件の関係
システムライフサイクルプロセスと要件定義の位置
▼ 要件定義プロセスで定義する3要件
業務要件
業務手順・ルール
組織・責任・権限
機能要件
入出力データ
画面・帳票・処理
非機能要件
可用性・性能
セキュリティ・運用
非機能要件の6大カテゴリ（非機能要求グレード）
IPAが公開している「非機能要求グレード」では、非機能要件を6つのカテゴリに整理しています。
概要だけ把握しておけば十分です。
| カテゴリ | 主な内容 |
|---|---|
| 可用性 | 稼働率、障害時の復旧目標時間（RTO）など |
| 性能・拡張性 | 応答時間、スループット、将来のデータ量増加への対応 |
| 運用・保守性 | バックアップ周期、監視サイクル、障害対応手順 |
| 移行性 | 現行システムからの移行方法、移行期間の制約 |
| セキュリティ | 認証方式、データ暗号化、アクセス制御 |
| システム環境・エコロジー | 設置場所の条件、消費電力、CO2排出量 |
企画プロセスとの境界線
過去問で混同しやすいのが「企画プロセス」との違いです。
企画プロセスはシステム化の方針や投資対効果を決める工程であり、「何を作るか」の具体的な中身には踏み込みません。
「費用対効果の評価」「システム化構想の立案」は企画プロセスの作業であり、要件定義ではない点を区別してください。
| プロセス | 決めること | キーワード |
|---|---|---|
| 企画 | システム化の方針・計画、投資効果 | 費用対効果、システム化構想、優先順位 |
| 要件定義 | 利害関係者のニーズをもとに、業務・機能・非機能の要件を明文化 | 利害関係者、合意、業務手順、制約条件 |
| 開発 | 要件をもとにシステム方式設計・プログラミング・テストを実施 | 設計、実装、テスト |
では、これらが試験でどのように出題されるか見ていきましょう。
💡 要件定義プロセスの核心を3行で
・企画プロセスの後、開発プロセスの前に位置する上流工程
・定義する要件は「業務要件（業務のあり方）」「機能要件（システムが備える機能）」「非機能要件（性能・セキュリティ等それ以外すべて）」の3種類
・利害関係者と合意して要件定義書にまとめることがゴール
試験ではこう出る！
要件定義プロセスは、IP・FE・APの全区分で繰り返し出題されている定番テーマです。出題パターンは3つに集約されます。
📊 過去問での出題実績（抜粋）
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| IP R6 問33 | 業務要件定義が曖昧なことで起こり得る問題を選ぶ | 「仕様変更の手戻り」「受入れテスト設計の困難」が正解。企画段階の問題やコーディングミスはひっかけ |
| FE H30秋 問65 |
要件定義プロセスで実施すべきものを選ぶ | 「利害関係者の識別とニーズの識別」が正解。企画プロセスや開発プロセスの作業が紛れ込む |
| FE R1秋 問65 |
非機能要件の定義で行う作業を選ぶ | 「技術要件（開発基準・標準）の作成」が正解。機能間のデータフローは機能要件 |
| AP H28秋 問65 |
非機能要件項目に該当するものを選ぶ | 「可用性・性能・拡張性・セキュリティ等」が正解。業務手順やシステム機能の実現範囲は業務要件・機能要件 |
| IP H30春 問6 |
非機能要件だけを全て挙げたものを選ぶ | 「システム監視のサイクル」「障害復旧時間」が非機能要件。「業務機能間のデータの流れ」は機能要件で除外 |
📝 IPA試験での出題パターン
パターン1：「要件定義プロセスで実施する作業を選べ」
企画プロセス・開発プロセス・保守プロセスの作業と混ぜた4択形式。「利害関係者のニーズを識別する」「業務手順やルールを明確にする」が要件定義の選択肢。「費用対効果の評価」「システム化構想」は企画プロセスなので除外する。
パターン2：「機能要件 or 非機能要件に該当するものを選べ」
入出力データ・画面・帳票は機能要件。可用性・応答時間・セキュリティ・移行方法は非機能要件。「システム監視のサイクル」が非機能要件であることを見落とすと失点する。
パターン3：「要件定義の不備で起きる問題を選べ」
IP H31春 問17、IP R6 問33がこのパターン。「業務ルールの誤った解釈」「仕様変更の手戻り」が要件定義由来の問題。「費用対効果の誤評価」は企画プロセスの不備であり、ひっかけになる。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 要件定義プロセスにおいて、非機能要件に該当するものはどれでしょうか？
- A. システム基盤に関わる可用性、性能、拡張性、セキュリティ、運用性などの要件
- B. 新しい業務の遂行に必要なアプリケーションの利用者の作業やシステム機能の実現範囲
- C. 経営戦略や情報戦略に関わる経営上のニーズ、システム化を必要とする業務上の課題
正解と解説を見る
正解：A
解説：
非機能要件とは、システムの機能そのもの以外に求められる性能・品質・制約に関する要件です。IPAの非機能要求グレードでは、可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境の6カテゴリに整理されています。
選択肢Bは機能要件の説明です。「利用者の作業」「システム機能の実現範囲」「機能間の情報の流れ」といったキーワードが機能要件を示します。選択肢Cはシステム化方針（企画プロセスの領域）に近い記述であり、要件定義プロセスで扱う3要件のいずれにも直接該当しません。AP H28秋 問65で同趣旨の問題が出題されています。
よくある質問（FAQ）
Q. 要件定義は誰が主導するのですか？
システム取得者（発注側）が主導します。共通フレーム2013では、要件定義プロセスはシステム取得者側の責任で実施するプロセスとして位置づけられています。開発ベンダは技術的な助言を行いますが、最終的な要件の決定権と合意責任は利用者側にあります。
Q. 「業務要件」と「機能要件」は何が違いますか？もう少し具体的に教えてください。
業務要件は「仕事のやり方そのもの」に関する取り決めです。例えば「返品は購入後30日以内に限る」「承認は課長→部長の二段階とする」などです。機能要件は、その業務ルールを実現するためにシステムが提供する機能です。先の例なら「購入日から30日を超えた返品申請はエラーメッセージを表示する画面」「課長承認後に部長へ自動通知するワークフロー機能」が機能要件に該当します。
Q. 非機能要件が曖昧だと実際に何が起きますか？
開発後に「画面遷移が遅すぎる」「アクセス集中でサーバが落ちる」「セキュリティ基準を満たしていない」といった問題が発覚し、大規模な改修が必要になります。IPAの「要件定義を成功に導く128の勘どころ」でも、非機能要件の不備が手戻りの主要因として挙げられています。
Q. 要件定義プロセスとシステム要件定義は別物ですか？
別物です。要件定義プロセスは共通フレーム2013で定義されたライフサイクルプロセスの1つで、業務要件・機能要件・非機能要件を包括する上位概念です。一方、システム要件定義は開発プロセスの中で実施される作業であり、要件定義プロセスで合意した内容をシステムの構成要素レベルに分解・詳細化する工程です。試験では両者を混同させる選択肢が登場するため、レイヤーの違いを意識してください。
