「システム要件定義って、結局なにを決める工程なの？」と疑問に感じていませんか。開発工程の名前は似たものが多く、要件定義・要求定義・基本設計の境界は混乱の原因になります。この記事では、システム要件定義の役割を一つに絞って整理します。
対象試験と出題頻度
システム要件定義は、基本情報技術者（FE）・応用情報技術者（AP）で出題されるテーマです。
ソフトウェアライフサイクルプロセス（SLCP）の一工程として、共通フレーム2013の枠組みで問われます。
「要求」と「要件」の違い、機能要件と非機能要件の区別が頻出ポイントです。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
システム要件定義（System Requirements Definition）とは、一言で言うと
「利用者の要望を整理し、システムが満たすべき機能と性能を文書化する工程」
のことです。
イメージとしては、「注文住宅の設計打ち合わせ」です。施主が「広いリビングがほしい」と言っただけでは家は建ちません。
建築士が「リビングは20畳、南向き、床暖房付き」と具体的な数値や仕様まで落とし込んで初めて施工に入れます。システム開発も同じで、ふわっとした要望のままでは作れないため、開発できる粒度まで整理する工程が必要です。
📊 システム要件定義の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | System Requirements Definition |
| 位置づけ | 共通フレーム2013における開発プロセスの最初の工程 |
| 主な成果物 | システム要件定義書 |
| 定義する内容 | 機能要件・非機能要件・業務要件・制約条件 |
解説
発注者の頭の中にある「こうしたい」は、そのままでは開発者に伝わりません。
「速いシステムがほしい」と言われても、画面表示3秒以内なのか0.1秒以内なのかで設計は大きく変わります。この曖昧さを排除し、開発側が手を動かせる状態に翻訳する工程がシステム要件定義です。
「要求」と「要件」の違い
試験で混同しやすい2つの用語を最初に整理します。
| 用語 | 主体 | 中身 |
|---|---|---|
| 要求 | 発注者・利用者 | 「こうあってほしい」という願望ベースの表明 |
| 要件 | 開発者側 | 要求を実現可能な形に整理した、開発の前提条件 |
機能要件と非機能要件
システム要件定義書に書かれる内容は、大きく2種類に分かれます。
機能要件
システムが「何をするか」
- 商品検索ができる
- 注文を受け付ける
- 在庫を管理する
- 帳票を出力する
非機能要件
システムが「どうあるべきか」
- 性能（応答3秒以内）
- 可用性（稼働率99.9%）
- セキュリティ（暗号化）
- 運用・保守性
開発工程の中の位置づけ
共通フレーム2013における前後関係を図示します。
企画プロセス
業務要件定義
開発プロセス
システム要件定義
★この工程
開発プロセス
システム方式設計
開発プロセス
ソフトウェア要件定義
▲ 業務要件 → システム要件 → ソフトウェア要件 と粒度が細かくなる
業務要件定義は「業務をどう改善したいか」、システム要件定義は「そのためにシステムが何を担うか」、ソフトウェア要件定義は「ソフトウェア部分の具体的な仕様」を決める工程です。
粒度が段階的に細かくなる流れを押さえると、関連用語との混同を防げます。
利害関係者との合意形成
システム要件定義の最後には、利害関係者（ステークホルダ）の確認とレビューを経て、要件の合意形成が必要です。
ここで握った内容が後工程の「契約上のゴール」になるため、後から「やっぱり違う」が起きないよう、文書化と承認の手続きが重視されます。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 システム要件定義の核心を3行で
・利用者の要望を、開発可能な粒度まで具体化して文書にまとめる工程
・成果物は「システム要件定義書」で、機能要件と非機能要件を含む
・業務要件 → システム要件 → ソフトウェア要件と粒度が細分化される
試験ではこう出る！
システム要件定義は、FE・APの午前問題で「開発工程の作業内容を選ぶ問題」として繰り返し出題されています。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R元秋 午前 問64 |
共通フレーム2013における要件定義プロセスの作業内容を問う問題。 | ・利害関係者の識別と要件の合意が正解 ・設計・実装・運用の作業がひっかけ |
| FE H30秋 午前 問65 |
非機能要件に該当する項目を選ぶ問題。 | ・性能・可用性・セキュリティが非機能要件 ・「商品の検索機能」など機能要件はひっかけ |
| AP H29春 午前 問64 |
要件定義プロセスで「業務要件→システム要件」の流れを問う問題。 | ・粒度が段階的に細かくなる順序を理解しているか ・工程名の入れ替えがひっかけ |
📝 IPA試験での出題パターン
パターン1：「この工程で行う作業はどれか」
選択肢に各開発工程の作業内容が並び、要件定義の作業を選ばせる形式。キーワードは「利害関係者の識別」「要件の引き出し」「合意形成」。設計・テストの作業文がひっかけとして紛れ込みます。
パターン2：「機能要件／非機能要件の区別」
具体的な要件項目を提示し、機能要件か非機能要件かを判別させる形式。性能・可用性・拡張性・セキュリティは非機能要件、業務処理の中身は機能要件、と機械的に振り分けられれば得点できます。
ここまでで合格ラインに届きます。共通フレームの細かい記述項目まで暗記する必要はないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. システム要件定義の説明として、最も適切なものはどれでしょうか？
- A. プログラムの内部構造を決め、モジュール分割やインタフェースを設計する工程である。
- B. 利用者の要望を整理し、システムが満たすべき機能要件・非機能要件を文書化して、利害関係者と合意する工程である。
- C. 完成したシステムを本番環境に展開し、利用者教育や移行作業を行う工程である。
正解と解説を見る
正解：B
解説：
システム要件定義は、発注者の要望を開発可能な形に整理し、機能要件と非機能要件として文書化したうえで利害関係者の合意を得る工程です。後工程に渡す「ゴールの定義」を担うため、合意形成までを含む点が大きな特徴です。
選択肢Aはソフトウェア方式設計（内部設計）の説明です。モジュール分割やインタフェース設計は、要件が確定したあとの設計工程に属します。選択肢Cはシステム導入・受入支援の工程の説明です。本番展開や利用者教育は開発の最終フェーズで行う作業であり、要件を決める工程とは役割が異なります。
よくある質問（FAQ）
Q. システム要件定義とソフトウェア要件定義はどう違いますか？
対象範囲が異なります。前者はハードウェア・ネットワーク・運用体制を含めた「システム全体」が満たすべき条件を決めます。後者はその中でソフトウェアが担う部分に絞り込んで、画面・帳票・データ項目などの具体仕様を定義します。共通フレーム2013では別プロセスとして整理されており、AP試験でもこの順序が問われます。
Q. 要件定義書は誰が作成するのが一般的ですか？
ベンダ側のSE（システムエンジニア）が中心になって作成し、発注者がレビュー・承認する形が多いです。ただし共通フレーム2013の考え方では、要件定義の主体は本来「取得者（発注者）」です。発注者側にIT人材がいない場合に、ベンダがコンサル的に支援するのが日本の実情です。
Q. アジャイル開発でも要件定義は必要ですか？
必要です。ただし形式が異なります。ウォーターフォール型では分厚い要件定義書を最初にまとめますが、アジャイルではプロダクトバックログ・ユーザーストーリーという形で、開発と並行して継続的に要件を更新します。「最初に全部固めるか、走りながら詰めるか」の違いで、要件を明らかにする行為自体は不可欠です。
Q. 要件定義の失敗はどんなトラブルにつながりますか？
代表例は、開発後半での仕様変更による工数増・納期遅延・品質低下、そして発注者と開発者の訴訟トラブルです。「言った言わない」を防ぐ意味でも、書面での合意が重視されます。IPA公開の「非機能要求グレード」は、非機能要件の抜け漏れを防ぐためのチェックリストとして実務でよく使われます。
