要求アナリシスとデザイン定義
真ん中の3つの知識エリア「戦略アナリシス」「要求アナリシスとデザイン定義」「ソリューション評価」を横に並べた形です。双方向の矢印を価値のスペクトルと言い、左端が「潜在価値」右端を「実現価値」と考えます。
「戦略」→ 要求アナリシスとデザイン定義 → ソリューション評価
と進むにつれて潜在価値から実現価値に変換されていくイメージを表しています。そしてそこで扱われるビジネスアナリシス情報が「ニーズ」→「ソリューションスコープ」→「要求」→「デザイン」と進化していくわけです。
ただしECBAでは中央の要求アナリシスとデザイン定義の部分のみが試験の対象です。本当は全体を理解した方が良いのですが少し残念です。
上図で分かるようにこの知識エリアには6つのタスクがあります。
- 要求を精緻化しモデル化する
- 要求を検証する
- 要求の妥当性を確認する
- 要求アーキテクチャを定義する
- デザイン案を定義する
- 潜在価値を分析しソリューションを推奨する
要求を精緻化しモデル化する
このタスクの目的は、引き出しの結果を分析し、統合し、精緻化して、要求とデザインに変換することです。
学習目標は次の4つです。
- 要求とデザインをモデル化することを理解している。
- 要求とデザインを分析することを理解している。
- 要求とデザインのキーとなる情報とその属性を理解している。
- 様々なニーズに対応するために適切な抽象度を選択することを理解している
1.要求とデザインをモデル化することを理解している
モデルの抽象度やカテゴリーが重要です。
モデル・カテゴリーには次の5つがあります。
- データと情報
- 人と役割
- アクティビティーフロー
- 能力
- 根拠
各々には表のようにいくつかのモデルが分類されています。
さらに要求を分析するための様々なテクニックのリストがあります。すべて使う必要はありませんが、重要なものはしっかり理解しておく必要があるでしょう。
こんなにたくさんモデリングのテクニックがあります。それを上記の5つのカテゴリーに分類しているのが重要です。よく使用されるものとしては次のものがあります。あ
- データモデリング
- プロセスモデリング
- インターフェース分析
- ユースケースとシナリオ
- ユーザーストーリー
要求を検証する
このタスクの目的は、要求とデザインの仕様とモデルが、品質標準を満たしており、使用目的に適していることを確実にすることです。
学習目標は次の3つです。:
- 要求品質、設計品質の特性を理解している。
- 業務を通じて要求を検証する活動を理解している。
- 品質管理のための適切なチェックリストをルールに従い使用することができる。
1 要求品質、設計品質の特性を理解している
次の要求やデザインの品質特性を理解しましょう。
- アトミック（自己完結）
- 完全性
- 一貫性
- 簡潔性
- 実現可能性
- 曖昧でない
- テストが容易
- 優先順位が付いた
- 理解が容易
2 業務を通じて要求を検証する活動を理解している
- 適切なツールや手法を使用しているか。
- モデル化の表記法やテンプレートやフォームを正しく使用しているか。
- 各モデル内の完全性をチェックする。
- 他のモデルと比較して、異なる要素を使用していないかをチェックする。
- 要求で使用されている用語が、ステークホルダーに理解できるか。
- 明確化に役立つ箇所があれば例を追加する。
.3 チェックリストの使用
要求の妥当性を確認する
このタスクの目的は、すべての要求とデザインが、ビジネス要求に沿ったものであり、必要な価値の提供に役立つものであることを確実にすることです。
学習目標は次の3つです。:
- リスクをマネジメントするために前提条件を明確にし、活用する基礎知識がある。
- チェンジの成功を評価するために、測定可能な評価基準を定義することに関する基礎知識がある。
- バリューデリバリーをサポートするために、ソリューションスコープとの整合性評価に関する基礎知識がある。
1 リスクをマネジメントするために前提条件を明確にし、活用する基礎知識がある。
顧客やステークホルダーの反応について前提条件を設定し（特にNewビジネス）、リスクをマネジメントする。これは「戦略アナリシス」との関係が必要なので、深い理解まで求めていません。「基礎知識（知っていればよい）」レベルです。
2 チェンジの成功を評価するために、測定可能な評価基準を定義することに関する基礎知識がある。
この部分も戦略アナリシスと関連しますので、深い理解は求めておらず、「基礎知識（知っていればよい）」レベルです。
3 バリューデリバリーをサポートするために、ソリューションスコープとの整合性評価に関する基礎知識がある。
ステークホルダーに便益を提供しない要求は取り除くべき要求の有力候補です。。
これも「知っていればよい」レベルです。
【重要】
「要求を検証する」タスクと「要求の妥当性を確認する」タスクは似ていますが違いを明確に理解する必要があります。
- 要求の検証：形式的な品質のチェックなので、ビジネス的に意味があるかどうかは何も問いません。曖昧でないか、一貫性、アトミック（閉じている）
- 妥当性確認： 要求がビジネス的に意味があるかという観点でチェックします。その2つの観点を独立したタスクでチェックするのがBABOKのポイントです。
それはソフトウェアを作る立場で「単体テストや総合テスト」でバグがないかどうかをチェックすることと、ユーザーの立場で「受入れテスト」により使用に適合しているかどうかを独立して検査することに類似しています。
要求アーキテクチャを定義する
このタスクの目的は、すべての要求が互いに支え合って、全体として目標を完全に達成することを確実にすることです。
学習目標は次の５つです。
- 要求のビューポイントとビューを有効に活用する基礎知識がある。
- ソリューションアーキテクチャを開発するためにテンプレートを活用する基礎知識がある。
- ルールに従い要求のセットが完全であることを確認することができる。
- 要求の関係性を明らかにすることで、要求が相互に関連することを理解している。
- ビジネスアナリシス情報アーキテクチャを定義することを理解している。
1 要求のビューポイントとビューを有効に活用する基礎知識がある
具体的なビューポイントの例：
- ビジネス・プロセス・モデル
- データ・モデルと情報
- ユースケースやユーザー・エクスペリエンスを含むユーザー相互作用
- 監査とセキュリティー
- ビジネス・モデル
これらはツールにかなり依存しますが基礎知識として知っていればよいレベルです。
2 ソリューションアーキテクチャを開発するためにテンプレートを活用する基礎知識がある。
アーキテクチャーのテンプレートはツールに大きく依存しますが、基礎知識を求められているので、知っていれば良いです。
3 ルールに従い要求のセットが完全であることを確認することができる。
ツールで確認するので、教えてくれればできるレベルの知識です。
4 要求の関係性を明らかにすることで、要求が相互にかんれんすることを理解
- 定義されている（defined）
- 必要である（necessary）
- 正確である（correct）
- 曖昧さがない（unambiguous）
- 一貫性がある（consistent）
このタスクは文字ではわかりずらいものです。具体的なツールです。
デザイン案を定義する
このタスクの目的は、ソリューション・アプローチを定義し、ビジネスを改善する機会を特定し、要求をソリューション・コンポーネント全体に割り当て、望ましい将来状態を達成するための複数のデザイン案を示すことです。
学習目標は次の４つです
- 適切なソリューション・アプローチを特定することを理解している。
- 改善の機会を特定することを理解している。
- チェンジの目標を達成するために、ソリューション・コンポーネントとリリースに要求を割り当てる方法を理解している。
- 望ましい将来状態に沿ったデザイン・オプションを開発することを理解している。
1 適切なソリューション・アプローチを特定することを理解している。
次のソリューション・アプローチを理解しましょう。
- 作成：いわゆるスクラッチで開発
- 購入：パッケージソフトを購入すること
- 両者の組み合わせ。
日本でもパッケージソフトを使用することがポピュラーになってきました。欧米では主流です。
2 改善の機会を特定することを理解している
次の改善の機会を理解しておきます。
- 業務効率改善: ERPやBPM（SoR）ではこの業務効率の改善が重要です。
- 情報アクセスの向上: SoEでは情報アクセスが重要です。
- 追加能力の特定: 特にパッケージの場合、SoR/SoE 共に追加能力も重要です。
3 チェンジの目標を達成するために、ソリューション・コンポーネントとリリースに要求を割り当てる方法を理解している。
要求の割り当てとは、目標を最大限に達成できるように、ソリューション・コンポーネントとリリースに要求を割り当てるプロセスである。しっかり理解しましょう。
4 望ましい将来状態に沿ったデザイン案を開発することを理解している
デザイン要素の例です
- ビジネス・ポリシーとビジネス・ルール
- 実行と管理の対象となるビジネス・プロセス
- ソリューションを運用し保守する人、その職務機能と責任
- 行うべきビジネス遂行上の意思決定
- ソリューション中で使用するソフトウェア・アプリケーションとアプリケーション・コンポーネント
- 織構造。組織間の相互作用、その顧客とサプライヤー
余談ですが、最近のDXソリューションは上記のデザイン要素すべてがチェンジ（変革）するものです。
潜在価値を分析しソリューションを推奨する
このタスクの目的は、デザイン案それぞれに関する潜在価値を見積り、エンタープライズの要求を満たすのに最適な案はどれかを確定することです。
学習目標は次の４つです。
- 潜在的なソリューションがもたらすと期待される利益を特定する方法を理解している。
- 潜在的なソリューションに関連するコストを特定することを理解している。
- 主要なステークホルダーに対するソリューションの価値を決定する基礎知識がある。
- 各デザイン案を評価し、最適なソリューションとして推奨する基礎知識がある
1 潜在的なソリューションがもたらすと期待される利益を特定する方法を理解している。
2 潜在的なソリューションに関連するコストを特定することを理解している。
予想コストは、ソリューションに関連する可能性のあるすべてのマイナスの値です。
3 主要なステークホルダーに対するソリューションの価値を決定する基礎知識がある。
ソリューションの潜在価値は、そのソリューションが提供する便益と、それに関連するコストに基づいて決まる。
4 各デザイン案を評価し、最適なソリューションとして推奨する基礎知識がある
考慮するべきいくつかの要因:
・使用可能なリソース:
・ソリューションに対する制約条件:
・要求の依存関係性:
ビジネスアナリストは、ニーズに対応するソリューションのうち最も価値が高いと思われる選択肢を推奨する。実装する価値があるデザイン案が存在せず、何もしないことが最善の推奨案となる場合もある。