（５）要求アナリシスとデザイン定義

本章全体の解説

ここでは、要求を洗練していくという反復的な側面と戦略をソリューション案に繋げるまでの工程的な側面の２つを扱います。

＜反復的な側面＞

＜工程的な側面＞

1.要求を精緻化しモデル化する

引き出した情報を整理します。大抵の場合、表か図（あるいは両方）の形式で整理します（用語集、権限マトリクス、データフロー図など）。整理の過程では、ビジネスアナリシス情報を要素に分解します。要求の明確な表現と分類を検討します。要求を分類することで要求の抜け漏れに気付くきっかけにもなりますし、要求の理解を深めることができます。要求の抽象レベルはステークホルダにより理解のしやすさが異なります。経営者であれば抽象的なレベルが理解しやすくシステムエンジニアには具体的なレベルの方が理解しやすくなります。抽象レベルを変えた際に意味が変わらないよう注意する必要があります。

2.要求を検証する

要求・デザインの品質は使用適合性が重要な特性です。これはステークホルダによって判断されます。検証プロセスは繰り返し実行され、チェックリストを活用することが品質のチェックに役立ちます。

3.要求の妥当性を確認する

整理した要求がビジネス要求と整合しているか確認します。

ビジネスの要求には表現されていない前提条件があることがあるため、要求の前提条件を明確にします。期待された便益がもたらされるか測定できるよう評価基準を定義します。デザインと要求が整合しない場合は、将来状態を見直すか要求を見直す必要があります。

なお、2.要求の検証と3.要求の妥当性確認は混同しがちですが、違いを表現すると以下の通りです。

4.要求アーキテクチャを定義する

要求アーキテクチャとはチェンジに必要なすべての要求一式です。要求の表現は単一ではなく、ビューポイントごとに異なります。一つのビューポイントに大量の情報を入れすぎると複雑になり本来の目的を失います。ビューポイントのイメージは以下の通りですが、実際は要求一覧のような形式の情報の方がボリューム的には多いです（個人的見解）。

5.デザイン案を定義する

要求をソリューションコンポーネントに当てはめ、望ましい将来状態を達成するための複数のデザイン案を示します。

6.潜在価値を分析しソリューションを推奨する

どのようなチェンジでも価値の増大と減少の両方が同時に起きます。便益とコストの2つを目に見えないものも考慮して比較します。各デザイン案の評価を行い最も効果的なトレードオフとなっていることを確認します。

以上が、要求アナリシスとデザイン定義のまとめです。