エンタープライズアーキテクチャ・システム企画
午前II午後I午後II論文
重要度:
要件定義プロセス
よみがな: ようけんていぎぷろせす
英語名称・略称: Requirements Definition Process
1行要約（本質）
新システムが具備すべき「業務要件」「機能要件」「非機能要件」を利害関係者から漏れなく抽出し合意するプロセス。
3つの重要ポイント
1
システム化計画に基づき、ユーザーがシステムを使って何をできるようにするかを確定する。
2
業務要件（新業務フロー・規程）とシステム要件（機能・データ・画面・非機能）を分離して定義する。
3
開発途中の仕様変更（スコープクリープ）を防ぐための「要件トレーサビリティ」を確保する。
構造・プロセスの図解
図要件定義の3大定義要素
バランスよく網羅すべき要件の分類1. 業務要件
Business Requirements
業務の手順、ルール、入力・出力情報、担当組織と責任分担。
2. 機能要件
Functional Requirements
画面仕様、帳票レイアウト、計算ロジック、データ入出力機能。
3. 非機能要件
Non-Functional Requirements
可用性（稼働率）、性能（応答時間）、拡張性、運用保守性、セキュリティ。
概要・背景・本質
要件定義は、発注者側の要求を明確な仕様へと落とし込む超上流の最終関門です。ここで業務要件の曖昧さや例外処理の検討漏れがあると、後工程（結合テストや受入テスト）で致命的な手戻りとなって爆発します。ITストラテジストは、ユーザー部門のわがままを全て受け入れるのではなく、費用対効果と業務標準化の観点から厳格にトリアージします。
コア概念と着眼点
- 利害関係者の特定：経営陣、現場オペレーター、管理者、外部取引先など多角的な視点
- 業務要件の明確化：新業務フロー（BPR後のTo-Be）、例外処理手順、権限管理
- 機能要件 vs 非機能要件：画面・帳票・計算ロジック（機能）と、性能・可用性・セキュリティ（非機能）
- 合意文書化：要件定義書を正として業務部門長と正式サインオフを実施
ITストラテジスト試験（午後I記述・午後II論文）での論述ポイント
午後Iの設問で「要件定義の漏れによって生じたトラブルの原因」を問われる問題が頻出。午後II小論文では、『業務部門間で対立した要件を、経営戦略への貢献度とコスト影響を数値化して提示することで納得させ、合意を取り付けた』という調整プロセスを論述すると試験官の共感を呼ぶ。