NTTデータ
技術開発本部
副本部長
山本修一郎
シナリオと他の要求分析手法との関係
ユースケース
ユースケースはシステムのあるひとつの利用事例としてシナリオを表現すると考えられる。この意味では、ユースケースを中心に構成されるUMLのようなオブジェクト指向分析設計手法ではシナリオが本質的な表現手段になっているとも考えられる。ユースケースでは、ユースケーステキストによりシナリオを自然言語で記述することができる。
ユースケースに基づくシナリオの作成手順の例を図３に示す。
図３ ユースケースに基づくシナリオ作成
- 【手順1】
- ユースケースをユーザーの分野知識に基づいて抽出し、記述ガイドラインに従って作成する
- 【手順2】
- 抽出されたユースケースに対してオブジェクトモデルの再利用ライブラリを参考にして問題を分析する
- 【手順3】
- 問題分析によって拡充されたユースケースに対して、影響要因や例外種別を考慮してシナリオを作成する
- 【手順4】
- 定められた確認方法に従って、ユーザーに対して作成されたシナリオを確認する
またUMLではアクティビティ図と状態遷移図を用いてユースケースを自然言語よりも形式的に詳細化することができる．たとえばアクティビティ図では、予めユースケースに対するユースケーステキストをシナリオと考える．アクティビティ図を用いてシナリオとしての自然言語で記述されたユースケーステキストを記述する方法は次のようになる[3]。まず、ユースケーステキストに出現するアクタに対して、『レーン』を定義する．レーンというのは、従来の業務フロー図では担当者の業務範囲を示すものだ．次にユースケーステキストの順番に従って、その文の主体となるアクタに対応するレーンに、その文の内容をアクティビティ名として記述していく．また番号の順序に従って、アクティビティを関係付けることができる
UMLの振る舞い図
UMLではシステムの振る舞いを表現するための図式として、状態図、シーケンス図やコラボレーション図やアクティビティ図がある[3]。状態図では一つのオブジェクトの状態に着目して振舞いを記述する。これに対して、複数のオブジェクト間の相互作用を記述する場合は、シーケンス図やコラボレーション図やアクティビティ図を用いる。シーケンス図では時間順序に着目して振舞いを記述する。コラボレーション図ではオブジェクト間の相互関係に着目して振舞いを記述する。アクティビティ図では作業の流れに着目して振舞いを記述する。また、状態図が他の振舞い図と異なる点として、シーケンス図やコラボレーション図では特定のシナリオに従ったオブジェクト間の相互作用を記述するが、状態図ではすべての可能性のあるメッセージの系列を表現できることである。たとえば、複数のシーケンス図で記述されたシナリオのインスタンスの集合に出現するオブジェクトに対して、一つの状態図が対応して、これらのシナリオで記述されたメッセージに関する状態遷移を記述することができる。したがって、シーケンス図やアクティビティ図のようにユースケースをひとつのシナリオに対応付ける場合と、状態図のように複数のシナリオを表現すると考える場合がある。
ビュウポイント
ビュウポイント分析は、システムを外部から利用したり、システムの一部として動作する実体に着目して要求を分析する[4]。開発対象システムと間接的に交信する実体を境界VP（Bounding viewpoints）という。システムのサブプロセスを定義VP（Defining viewpoints）という。
ビュウポイント分析では、まずこの２つのビュウポイントを識別する。次いでビュウポイントを構造化する。このとき上位のシステムのビュウポイントを下位のサブシステムに反復的に分解していく。
各ビュウポイントに対して、アクティビティに着目して、入力データと出力データ、入力元と出力先のビュウポイントを表形式で明らかにすることにより、ビュウポイントの情報を収集する。
複数のビュウポイント間にデータの流れがあるとき、これらのビュウポイントに対する一連のアクティビティの系列をシナリオと考えることができる。
ゴール分析
図4 要求チャンクモデル
ゴールとシナリオの基本的な関係は、ゴールを実現するための具体的な動作の系列としてシナリオを対応付けることだろう。
そこで、要求の断片（要求チャンク）を対＜ゴール、シナリオ＞で定義すると、シナリオからゴールを逆に発見する方法も考えられる。たとえば、図４に要求チャンクの例を示す[4]。この要求チャンクに対して、次のようなゴール発見プロセスを構成できる。
まずシナリオを作成し、次にこのシナリオの構成要素としてのサブゴールを発見するという２段階で構成する。サブゴールを見つけたら、対応するシナリオを記述することにより、新しいサブゴールを探索する。この場合、ゴールからシナリオを探索する関係と、シナリオからゴールを発見する逆関係があることになる。
この方法の利点は、シナリオで表現されている具体的な交信関係を用いてサブゴールを発見するための系統的な手順をあたえることができる点だ。
つまり、シナリオを利用することで、ゴールをサブゴールに分解することができるわけだ。
シナリオの詳細化
トップダウン分解
プロジェクトの最初の時点では開発者はまずシナリオを抽象的なレベルでシステムの概要を把握するために記述する。次いでこのシナリオを段階的に推敲していく。典型的な例はビジネスプロセスを定義するために使われるシナリオ定義である。開発者がまずビジネスプロセスをシナリオでモデル化する。次いでビジネスプロセスの中で実行されるタスクを用いてシナリオを改訂する。最後に各タスクで実行されるタスクによりシナリオを改訂する。
ブラックボックスシナリオからホワイトボックスシナリオへの詳細化
環境とシステムとの交信を表現するシナリオでは、システムの構成要素間の交信関係のような詳細を記述する必要はないと思われるので、ブラックボックスシナリオで記述することになる。しかし開発者が十分にシステムの内容を理解するようになると、ブラックボックスシナリオを詳細化してシステムの構成要素間の交信関係まで含めたホワイトボックスシナリオとして記述するだろう。
システムを取り巻く外部環境とシステムの構成要素との交信関係を記述するためにはこのようなブラックボックスシナリオとホワイトボックスシナリオとを統合する必要がある。
シナリオの厳密化
最初にシナリオをテキスト形式で作成しておき、次いでテンプレート構造を用いて知識を追加したり、矛盾やギャップを検査する。さらに構造化テキストをシーケンス図のような形式性の高い表現に変換する。
この変換過程ではシナリオの内容の変更を伴うので、異なるシナリオの表現間の一貫性を保持することが重要になる。たとえばシーケンス図を定義するときに新しい交信を追加すると、上流工程の生産物としてのシナリオテキストの修正にまで変更が波及することがある。
シナリオの具体化
シナリオの最初の版では異なるレベルの知識を含んだものになることが多い。レビュや他の分野知識との相互検査により、知識が追加され、シナリオの一部が改訂されることでシナリオを改善する必要がある。