NTTデータ
技術開発本部
副本部長
山本修一郎
概要
今回はシナリオを用いた要求分析手法について紹介する[1]。シナリオは問題自体を分析するための手法である。シナリオはヒューマンインタフェースなどの人間工学分野でも使われており広い適用範囲を持つ。
欧州では要求仕様を記述するのにシナリオが従来からよく使われている。たとえば業務情報システムの開発でビジネスプロセスを厳密に記述するために、ビジネスの状態遷移を形式的に表現できるペトリネットを用いたところ、120以上のビジネスプロセスが発生し管理不可能になっただけでなく、全状態を確認することも、状態の組み合わせが爆発的に多くなりすぎて処理不能になった。このような結果になった背景には現場の担当者にはペトリネットは十分に理解できなかったことが挙げられる。そこでペトリネットの適用を断念して27 個のシナリオで本質的な利用形態を表現することで、システム開発がうまくいったという[1]。
本稿では、まずシナリオとは何かを説明する。次いでシナリオを用いた要求分析プロセスなど要求分析手法とシナリオの関係を紹介する。また、シナリオの効果的な活用法やシナリオを作成する上での留意点についても述べる。
シナリオとは
図1 シナリオ構造
シナリオはシステムがどのように利用されるかを説明するための記述である。シナリオを開始するときと終了したときのシステムの状態、通常のイベントの流れ、例外イベントなどをシナリオでは記述する。シナリオの構成の例を図1に示す[2]。
利用者がシステムとどのように交信するかを記述するためにシナリオではシステムが可能な相互作用や必要な機能を明らかにする。シナリオの簡単な例を以下に示す。
[例題]
デジタル文書を注文する単純なシナリオ
- システムにログインする
- 文書注文コマンドを選択する
- 必要な文書の参照番号を指定する
- 配信方法を選択する
- システムをログアウトする
このようなイベントの系列としてのシナリオを、シーケンス図やアクティビティ図などでも表現することができる[3]。
シナリオの分類
図2 シナリオフレームワーク
欧州のCREW プロジェクト(Cooperative Requirements Engineeringwith Scenarios)ではシナリオの利用形態を分類するためのフレームワークを定義している。このフレームワークでは4つの視点からシナリオを分類する。図2に示したように4つの視点とは、シナリオの形式、目的、内容、ライフサイクルだ。
シナリオの形式
シナリオ形式では、どのようなシナリオ表現しているかどうかを分類する。典型的なシナリオ形式の属性にはシナリオが形式的か非形式的か、静的か動的かなどがある。
シナリオの内容
シナリオの内容にはシナリオがどのような知識を扱うかを分類する。シナリオ内容の属性としては、システムの内部構成かシステムを利用する組織の構成なのか、正常系なのか例外系なのかなどがある。
目的
シナリオの目的では、シナリオがシステム開発の中でどのような役割を持つ存在として記述されているかで分類する。役割の例には、システム機能の記述、設計の選択枝の探索、システムの欠陥の説明などがある。
ライフサイクル
シナリオのライフサイクルの視点では、生産物としてのシナリオを時間的に変化する対象とみなして管理プロセスの形態で分類する。
ここで紹介したシナリオフレームワークは、シナリオをどのようにして作成・管理するかを整理する観点を提供しているので有効である。