エンタープライズアーキテクチャ・システム企画 重要度:★★★出題: AM2・PM1・PM2
要件定義プロセス
ようけんていぎぷろせす / Requirements Definition Process
新システムが具備すべき「業務要件」「機能要件」「非機能要件」を利害関係者から漏れなく抽出し合意するプロセス。
3行速習ポイント
- システム化計画に基づき、ユーザーがシステムを使って何をできるようにするかを確定する。
- 業務要件（新業務フロー・規程）とシステム要件（機能・データ・画面・非機能）を分離して定義する。
- 開発途中の仕様変更（スコープクリープ）を防ぐための「要件トレーサビリティ」を確保する。
図解
図要件定義の3大定義要素構成要素・基本原則
バランスよく網羅すべき要件の分類🏛 要件定義の3大定義要素（中核を構成する 3 つの柱）
Why/What: 業務
1. 業務要件
Business Requirements
BPRによって再設計された新業務の全体フロー、例外処理ルール、取扱データ、部門間の役割と承認権限を定義し、システム化の前提となる業務仕様を固める。
How: 機能仕様
2. 機能要件
Functional Requirements
業務要件を実現するためにシステムが提供すべき具体的な画面遷移、入力チェック、計算・判定ロジック、外部システムAPI連携、帳票出力仕様を定義する。
Quality: 非機能
3. 非機能要件
Non-Functional Requirements
IPA非機能要件グレード等を活用し、目標稼働率・RTO/RPO（可用性）、ピーク時応答時間（性能）、暗号化・監査ログ（セキュリティ）、移行手順を定量合意する。
💡 午後I・午後IIでは部門間で相反する要望に対し、経営目標への貢献度とTCO増減を定量提示して優先順位をつけ、要件肥大化（スコープクリープ）を抑止する。
概要と本質
要件定義は、発注者側の要求を明確な仕様へと落とし込む超上流の最終関門です。ここで業務要件の曖昧さや例外処理の検討漏れがあると、後工程（結合テストや受入テスト）で致命的な手戻りとなって爆発します。ITストラテジストは、ユーザー部門のわがままを全て受け入れるのではなく、費用対効果と業務標準化の観点から厳格にトリアージします。
重要ポイント・コア概念
- 利害関係者の特定：経営陣、現場オペレーター、管理者、外部取引先など多角的な視点
- 業務要件の明確化：新業務フロー（BPR後のTo-Be）、例外処理手順、権限管理
- 機能要件 vs 非機能要件：画面・帳票・計算ロジック（機能）と、性能・可用性・セキュリティ（非機能）
- 合意文書化：要件定義書を正として業務部門長と正式サインオフを実施
試験対策・午後II論文での活用法
午後Iの設問で「要件定義の漏れによって生じたトラブルの原因」を問われる問題が頻出。午後II小論文では、『業務部門間で対立した要件を、経営戦略への貢献度とコスト影響を数値化して提示することで納得させ、合意を取り付けた』という調整プロセスを論述すると試験官の共感を呼ぶ。
小論文で使える実践フレーズ・キーワード（クリックでコピー）
関連する重要用語
この用語が出題された過去問を解く（1分演習）
即時アウトプットで定着ITストラテジスト 過去問演習で実践力を鍛える
