システム開発の入口で必ず登場する「要件定義」。ここでつまずくと後工程のすべてが崩れる、と言われるほど重要な工程です。
本記事ではソフトウェア要件定義の意味、機能要件と非機能要件の違い、そしてIPA試験での問われ方までを一気に整理します。
対象試験と出題頻度
ソフトウェア要件定義は、基本情報技術者（FE）・応用情報技術者（AP）の午前問題で出題されるテーマです。
共通フレーム（SLCP）における位置づけ、機能要件と非機能要件の区別、UMLを使った要求の図示など、開発プロセス全体の入口として頻繁に問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「要件定義って結局、何をする工程なの？」と曖昧なまま進んでしまいがちです。ここで一度はっきりさせておきましょう。
ソフトウェア要件定義（Software Requirements Definition）とは、一言で言うと
「利用者の要求を整理し、システムが満たすべき機能と性能を文書化する工程」
のことです。
イメージとしては、「注文住宅の設計打ち合わせ」です。
家を建てるとき、いきなり大工さんが木を切り始めることはありません。まず施主に「リビングは何畳？」「収納はどこに？」「断熱性能は？」と聞き、要望を設計書に落とし込みます。
この設計書がなければ、施主の理想と完成した家が食い違ってしまいます。
ソフトウェア要件定義も同じで、利用者の「こういうシステムが欲しい」という要望を、開発者が作業できる形に翻訳する工程です。
📊 ソフトウェア要件定義の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Software Requirements Definition |
| 共通フレームでの位置 | システム要件定義の後、ソフトウェア方式設計の前 |
| 主な成果物 | ソフトウェア要件定義書（SRS） |
| 主な内容 | 機能要件、非機能要件、制約条件、利用者の業務シナリオ |
| 参照規格 | JIS X 0160（共通フレーム2013）／IEEE 830 |
解説
システム開発で最も手戻りコストが大きいのが「作ったものが利用者の欲しいものと違う」事態です。
コーディング後に発覚した要求の食い違いは、上流での修正と比較して数十倍のコストがかかると言われています。
この事故を防ぐために、開発の最上流で「何を作るか」を確定させる工程が設けられました。
それがソフトウェア要件定義です。
開発工程の中での位置づけ
共通フレーム（SLCP）における開発プロセスの流れを見てみましょう。
要件定義は「何を作るか」を決める工程、設計は「どう作るか」を決める工程です。
🔧 開発プロセスにおける要件定義の位置
①
システム
要件定義
業務全体の要求
②（本記事）
ソフトウェア
要件定義
SW単位の要求
③
ソフトウェア
方式設計
外部設計
④
詳細設計
～実装
内部設計・コーディング
▲ 「何を作るか」を決める②までが要件定義、「どう作るか」を決める③以降が設計
機能要件と非機能要件
要件定義書に書かれる内容は、大きく2つに分類されます。試験でも実務でも、この区別が最も重要です。
| 分類 | 何を決めるか | 具体例 |
|---|---|---|
| 機能要件 Functional |
システムが「何をするか」（提供する機能そのもの） | 商品検索、注文受付、在庫引当、帳票出力、ユーザ認証 |
| 非機能要件 Non-Functional |
システムが「どのように動くか」（品質・性能・制約） | 応答時間3秒以内、稼働率99.9%、同時接続1000人、AES暗号化 |
非機能要件は、IPAが公開する「非機能要求グレード」で6カテゴリ（可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境/エコロジー）に整理されています。
要件定義書に含めるべき項目
IEEE 830やJIS X 0160を参考にすると、ソフトウェア要件定義書には以下の項目が含まれます。
[ソフトウェア要件定義書（SRS）の構成例] 1. はじめに ├─ 目的・対象範囲 └─ 用語定義 2. 全体概要 ├─ システムの位置づけ ├─ 利用者の特性（アクター） └─ 制約条件（法令・既存システム） 3. 機能要件 ├─ 業務フロー ├─ 機能一覧 └─ ユースケース／画面遷移 4. 非機能要件 ├─ 性能（応答時間・スループット） ├─ 可用性（稼働率・RTO/RPO） ├─ セキュリティ（認証・暗号化） └─ 運用・保守 5. 外部インタフェース └─ 連携システム・データ形式
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 ソフトウェア要件定義の核心を3行で
・利用者の要求をシステムが満たすべき条件として文書化する開発上流工程
・記述内容は「機能要件（何をするか）」と「非機能要件（どう動くか）」に二分される
・共通フレームではシステム要件定義の後、ソフトウェア方式設計の前に位置する
試験ではこう出る！
ソフトウェア要件定義は、FE・APの午前問題で「開発プロセス」「マネジメント系」のテーマとして繰り返し出題されています。問われる切り口は概ね3パターンに集約されます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE R元秋 午前 問46 |
非機能要件の例として適切なものを選ぶ問題。 | ・「障害発生時の許容停止時間」が正解 ・帳票機能や検索機能はすべて機能要件側のひっかけ |
| AP H30秋 午前 問64 |
要件定義プロセスで実施する作業を選ぶ問題。 | ・「利用者の要求事項を漏れなく抽出し文書化」が正解 ・テスト項目作成や方式設計は別工程 |
| AP H29春 午前 問64 |
共通フレームの要件定義プロセスの説明を問う。 | ・利害関係者の識別とニーズの確定が中心 ・実装方法の決定は含まない点に注意 |
| FE H31春 午前 問46 |
機能要件と非機能要件の区別を問う典型問題。 | ・性能・信頼性・セキュリティは非機能側 ・業務処理ルールは機能側 |
📝 IPA試験での出題パターン
パターン1：「機能要件と非機能要件の振り分け」
選択肢に4つの要求事項が並び、非機能要件（または機能要件）に該当するものを選ばせる形式。「応答時間」「稼働率」「同時接続数」「セキュリティ強度」は非機能側、「○○を計算する」「○○を出力する」は機能側と覚えれば即答できます。
パターン2：「要件定義工程の作業内容」
「要件定義で実施するもの」を選ぶ形式。利害関係者の要求抽出・文書化・合意形成が正解で、「テストケース作成」「コーディング規約策定」「ハードウェア構成決定」はひっかけです。
パターン3：「開発プロセス上の位置」
共通フレームのプロセス順序を問う問題。「システム要件定義 → ソフトウェア要件定義 → ソフトウェア方式設計」の並びを暗記しておくと取りこぼしません。
試験ではここまででOKです。SRSの章立てやIEEE 830の細部まで覚える必要はありません。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア要件定義の説明として、最も適切なものはどれでしょうか？
- A. ソフトウェアの内部構造をモジュール単位に分割し、各モジュールのインタフェースとアルゴリズムを設計する作業。
- B. 利用者の要求を整理し、ソフトウェアが満たすべき機能要件と非機能要件を明確化して文書にまとめる作業。
- C. 完成したソフトウェアが要求どおり動作することを検証するため、テスト項目を設計し実施する作業。
正解と解説を見る
正解：B
解説：
選択肢Bが正解です。ソフトウェア要件定義は、利用者の要求を抽出・整理し、機能要件と非機能要件として文書化する開発上流工程を指します。「何を作るか」を確定させるのがこの工程の役割です。
選択肢Aはソフトウェア方式設計（外部設計）または詳細設計の説明です。要件定義の次工程に当たり、「どう作るか」を決める作業のため、要件定義とは目的が異なります。選択肢Cはソフトウェアテスト工程の説明です。要件定義の成果物（要件定義書）はテスト項目の根拠資料になりますが、テスト自体は開発の最終盤で実施される別工程です。
よくある質問（FAQ）
Q. 要件定義と要求定義は同じ意味ですか？
厳密には異なります。要求定義は利用者側が「こうしてほしい」と表明する段階の整理で、要件定義はそれを開発側が「こう作ります」と実現可能な条件に変換した段階を指します。日本のIT業界では両者を混同して使う現場も多いですが、IPAの共通フレームでは「要件定義」の用語が公式に採用されています。試験で「要求定義」が選択肢に出る場合は、利用者側の視点に寄った表現と理解してください。
Q. アジャイル開発でも要件定義は必要ですか？
必要です。ただしウォーターフォール型のように開発前に全要件を確定させるのではなく、ユーザーストーリーやプロダクトバックログという形で逐次更新します。スクラムではプロダクトオーナーが要求の優先順位を決め、各スプリントの開始時に詳細を詰めます。「要件定義書を作らない＝要件を決めない」ではない点に注意してください。
Q. 要件定義で利用者の要求を引き出すテクニックは？
代表的な手法にインタビュー、ワークショップ、現場観察、プロトタイピング、アンケートがあります。利用者本人も自分の要求を言語化できないことが多いため、プロトタイプを見せて反応を引き出す手法が有効です。応用情報の午後問題では、こうした要求獲得手法とその使い分けが問われることがあります。
Q. 要件定義工程で発覚しがちなトラブルは？
代表例は要求の抜け漏れ、利害関係者間の意見対立、スコープクリープ（後工程での要求追加）です。特にスコープクリープは予算とスケジュールを圧迫する原因となるため、変更管理プロセスを最初に決めておくのが鉄則です。実務では要件定義書にレビュー記録と承認サインを残し、後から「言った言わない」を防ぎます。
