2013年9月15日
この知識エリアでは、要求に優先順位を付け、そして各種モデリングを活用してソリューションが何をするべきか（WHATに相当します）を明確にします。また、前提と制約を明確にし、要求の検証と妥当性確認を行います。ステークホルダー要求とソリューション要求が作成されます。
6つのタスクがあります。
- 6.1 要求に優先順位をつける
- 6.2 要求を体系化化する
- 6.3 要求を仕様化しモデル化する
- 6.4 前提条件と制約条件を決める
- 6.5 要求を検証する
- 6.6 要求を妥当性確認する
以下、6つのタスクの解説です。
6.1要求に優先順位をつける
このタスクは文字通り、要求に優先順位をつける作業です。
費用対効果、リスク、実現の難易度、成功のしやすさなどを基に優先順位を付けます。
インプットとして、「ビジネスケース」がありますから、要求がビジネスゴール・目標に整合していなくてはいけません。
ビジネスゴールに整合しない要求は優先順位が下がります。
6.2 要求を体系化する
ソリューションスコープを記述するためにどのモデルが適切かを理解します。
「引き出し」で出されたさまざまな要求を「ステークホルダ-要求」「ソリューション要求」等に
分類し、体系化します。「機能要求」「非機能要求」も分類します。
6.3 要求の仕様化とモデリングを行う
体系化された要求を更に詳細にモデリングして、分析します。
タスクの詳細はモデリングのテクニックに依存します。
アウトプットは「ステークホルダー要求」、もしくは「ソリューション要求」です。
6.4 前提条件と制約条件を決める
ステークホルダーの懸案事項をインプットとして、前提条件と制約条件を作成します。
6.5 要求を検証する
BABOK(R)では、以下の要求に関する品質特性をチェックすることを「要求の検証」と定義しています。
- 凝集性（まとまっていること）
- 完全性
- 一貫性
- 正確性
- 実現可能性
- 修正可能性
- あいまいでない
- テスト可能性
アウトプットは「要求[検証された]」になります。
6.6 要求の妥当性を確認する
要求が妥当であるためには、要求がビジネスケース（ビジネス要求）に、貢献しなければなりません。
そのことを確認する作業です。これがBABOK(R)での「要求の妥当性確認」の定義です。
具体的には、「ステークホルダー要求[検証された]」「ソリューション要求[検証された]」「移行要求[検証された]」が「ビジネスケース（ビジネス要求）」に貢献することを確認します。
アウトプットは「要求[妥当性確認された]」となります。
「要求の検証と妥当性確認」は極めて重要です。「ソリューション（システム）の検証と妥当性確認」と混同しないでください。
他の知識体系（CMMIや共通フレーム2007）でも、「検証（Verification）と妥当性確認（Validation）」は重要だと謳っていますが、殆どの場合最終成果物（すなわちソリューションやシステム）に関するものです。「要求の検証と妥当性確認」を明確に定義しているのは筆者の調べる限り、BABOK(R)のみのようです。
尚、アウトプットの「要求」に様々な状態が指定されていることに注目してください。
要求には以下のような状態が付きます。
- 要求[表明された]
- 要求[表明された、確認された]
- 要求[追跡された]
- 要求[伝達された]
- 要求[承認された]
- 要求[優先順位付き]
- 要求[分析された]
- 要求[検証された]
- 要求[妥当性確認された]
- 要求[割り当てられた]
- 要求[保守された、かつ再利用可能]
各々どのタスクのアウトプットでしょうか。考えてみてください。
ガイドを見れば分かると思いますが。
使用するテクニックの例：
- 受け入れと評価の基準の定義
- 業務ルール分析
- データフロー図
- データモデル
- 機能分割
- 組織のモデル化
- プロセスモデル
- 問題追跡
- リスク分析
- シナリオとユースケース
- スコープモデリング
- メトリクスとKPI
- プロトタイピング
- シーケンス図
- 状態図
- 非機能要求分析
- ユーザストーリ
- 構造化ウォークスルー
非常に多くのモデリングテクニックを駆使する必要があることが分かります。
ソリューションの種類、アプローチによって必要なテクニックも変わります。