目的
  • システムの範囲を定義すること。つまり、システムによって何が処理され、システムの外部では何が処理されるのかを定義すること
  • システムと相互作用する人と物を定義すること
  • システム機能の概要を示すこと
役割:  システム分析者  
頻度: 必要に応じて。通常は反復ごとに複数回、方向づけフェーズと推敲フェーズの反復では頻繁に行う。
ステップ
入力とする成果物:    結果となる成果物:   
詳細情報:   
ツール メンター:   

ワークフローの詳細:   

アクターの獲得 ページの先頭へ

アクターの獲得は、システムの使用方法を定義する第一歩です。システムと相互作用する外部現象の各タイプは、アクターによって表現されます。アクターを獲得するには次の質問をします。

  • 仕事の遂行に、システムからの援助が必要なユーザー グループはどれか
  • 明らかにメインと思われるシステム機能の実行に必要なユーザー グループはどれか
  • システム保守やシステム管理のような 2 次機能の遂行に必要なユーザー グループはどれか
  • システムは外部のハードウェアまたはソフトウェア システムと相互作用するか

これらのカテゴリに 1 つ以上該当する個人、グループ、現象がアクター候補です。

適切な (人間の) アクターがあるかどうかを判定するには、アクターを演じられる人を 2 ~ 3 人あげ、そのアクターの集まりがアクターのニーズに十分応えられるかどうかを確認します。アクターの構成内容について詳しくは、「ガイドライン: アクター」を参照してください。

最も適切なアクターを獲得するのは最初は難しいかもしれません。また、すべてのユース ケースを獲得していないので、すぐにはすべてのアクターを獲得できないでしょう。ユース ケースで作業することが、システム環境と、システムとの相互作用の理解を深める唯一の方法です。ここまでくると、最初はあまりにも多数のアクターを使いすぎる傾向にあることから、最初のモデルを変更したくなるかもしれません。アクターを変更する場合は注意が必要です。導入する変更がユース ケース自体にも影響を与える可能性があるからです。アクターに変更を加えると、システムのインターフェイスと振る舞いにも大きな変更をもたらすことを忘れないでください。

獲得したアクターの命名と簡単な記述

アクターの名前はアクターの役割をはっきりと示す必要があります。今後の段階において、アクターの名前が別のアクターの名前と混同されるリスクがないようにします。

各アクターを定義するには、アクターの責任分野とアクターが何のためにシステムを必要とするのかを簡単に記述します。アクターはシステム外のものを表すため、詳細に記述する必要はありません。「ガイドライン: アクター」の「概要」も参照してください。

ユース ケースの獲得 ページの先頭へ

最初のアクターの概要作成ステップが完了したら、システムのユース ケースを獲得します。最初のユース ケースは準備段階なので、安定するまで何度か変更が必要になります。システムの構想や要求が不十分であったり、システムの分析が曖昧だったりすると、システムの機能は不明確になります。したがって、正しいユース ケースを獲得したかどうかを常に自問し続ける必要があります。さらに、最終バージョンに到達するまでには、ユース ケースの追加、削除、組み合わせ、分割などに備える必要があります。ユース ケースを詳細に記述すると、ユース ケースの理解が深まります。

ユース ケースを獲得する最良の方法は、各アクターがシステムに何を要求しているのかを検討することです。システムはユーザーのためにだけ存在するため、システムはユーザーのニーズに基づくべきだということを忘れないでください。システムに要求する機能を見れば、アクターのニーズがかなりわかるでしょう。アクターが人間であろうとなかろうと、アクターごとに次の質問を自問してみます。

  • アクターがシステムに望む主なタスクは何か
  • アクターはシステムのデータの作成、格納、変更、削除、読み取りを行うか
  • 突然外部的な変化が発生した場合、アクターはシステムに知らせる必要があるか
  • アクターはシステム内のある一定の出来事について知らされる必要があるか
  • アクターはシステムの起動または終了を行うか

これらの質問に対する答えは、ユース ケース候補を識別するイベント フローを表します。すべてが別々のユース ケースを構成するわけではなく、同一のユース ケースの変形としてモデル化するものもあります。どれが変形で、どれが別個の異なるユース ケースかを見分けるのはいつも簡単とはかぎりません。ただし、イベント フローを詳細に記述すると明確になります。

要求以外では、組織のエンタープライズ モデル (ビジネス モデルとも呼ばれる) が、ユース ケースの決定に役立つ貴重な情報源です。エンタープライズ モデルは既存の業務に情報システムを取り入れる方法を示したものなので、システムの環境がどうなっているかがよく理解できます。エンタープライズ モデルには企業の「ビジネス オブジェクト」が含まれているので、エンタープライズ モデルで定義する必要のある概念も見出すことができます。

システムには、ユース ケースになりそうなモデルが複数ある場合があります。「最適な」モデルを見つける最良の方法は、2 ~ 3 個のモデルを作成して好みのものを選び、それをさらに開発することです。代替モデルをいくつか開発していけば、システムの理解に役立ちます。

最初のユース ケース モデルの概要を作成する場合には、ユース ケース モデルが全機能要求を包括していることを確認します。すべてのユース ケースがすべての要求を満たすよう、要求を入念に吟味します。

ユース ケースについて、およびその獲得方法について詳しくは、「ガイドライン: ユース ケース モデル」と「ガイドライン: ユース ケース」を参照してください。

獲得したユース ケースの命名と簡単な記述

各ユース ケースには、アクターとの相互作用によって何が遂行されるかを示す名称を付けるべきです。理解を助けるために、名称の長さは数語に及ぶことがあります。複数のユース ケースに同じ名称を付けることはできません。「ガイドライン: ユース ケース」の「名前」も参照してください。

簡単な説明を付けてユース ケースを定義します。説明を付ける際には用語集を参照します。必要に応じて、新しい概念を定義します。「ガイドライン: ユース ケース」の「概要」も参照してください。

イベント フローの概要の作成

この時点で、ユース ケースについてイベント フローの最初のドラフトも書きます。各ユース ケースのイベント フローを、簡単な性能の集まりとして記述します。詳細は必要ありません。後でユース ケースを指定する人は、たとえ自分自身であっても、このような段階的な記述を必要とします。イベントの基本的なフローの概要から開始し、これに納得できたら、代替フローを追加します。

例:

リサイクルマシン システムのリサイクル アイテムという、ユース ケースのイベント フローの最初の段階的な記述は、次のようになります。

  • 顧客が「開始」ボタンを押す
  • 顧客がリサイクル品を入れる
  • システムが、投入されたリサイクル品の種類を確認する
  • 受け取った品目タイプのその日の合計が増加される
  • 顧客が「レシート」ボタンを押す
  • システムがレシートを印刷する
追加要求の収集

システムの要求の中には、特定のユース ケースに割り当てられないものもあります。これらを補足仕様書 (「成果物: 補足仕様書」を参照) に収集します。

アクターとユース ケースの相互作用の記述 ページの先頭へ

アクターとユース ケースの関係を示すことは重要なため、ユース ケースを獲得したら、どのアクターがユース ケースと相互作用するのかを確立します。これには、アクターとユース ケース間のシグナル伝達と同一方向に誘導可能なコミュニケーション関連を定義する必要があります。

シグナル伝達は通常、双方向に行われます。この場合、コミュニケーション関連は双方向に誘導可能にする必要があります。アクターとユース ケースの各ペアに、最も多い場合でも、コミュニケーション関連を 1 つだけ定義します。

定義する各コミュニケーション関連について簡単な説明も付けます。

コミュニケーション関連について詳しくは、「ガイドライン: コミュニケーション関連」を参照してください。

ユース ケースとアクターのパッケージ化 ページの先頭へ

アクターまたはユース ケースの数が多くなりすぎた場合は、それらをユース ケース パッケージに分割して、ユース ケース モデルの保守を簡単にします。これによりユース ケース モデルの把握も容易になり、開発者がユース ケースまたはアクターのパッケージを担当することによって、ユース ケース モデルの責任の割り当てが簡単になります。

次の場合には、別の方法でユース ケースをパッケージ化できます。

  • ユース ケースが同一のアクターと相互作用する場合
  • ユース ケースが、相互に包含関係になったり拡張関係になったりする場合
  • ユース ケースがすべてオプションの場合で、システムと共に提供されたり、まったく提供されなかったりする場合

ユース ケースのモデル化にはこれ以外の方法もあります。ただし、モデルを直観的にわかりやすく保つには、パッケージ化する際に明白な戦略を使用することが重要になります。

ユース ケース パッケージについて詳しくは、「ガイドライン: ユース ケース パッケージ」を参照してください。

ユース ケース図によるユース ケース モデルの図示 ページの先頭へ

関連するユース ケース同士の関係だけでなく、ユース ケースとアクター間の関係も、ユース ケース モデルのダイアグラムで表現できます。このダイアグラムには以下が含まれる場合があります。

  • 同一ユース ケース パッケージに所属するアクター
  • アクター、およびそのアクターと相互作用するすべてのユース ケース
  • 同一情報を処理するユース ケース
  • 同一グループのアクターによって使用されるユース ケース
  • 1 つのシーケンスで実行されることの多いユース ケース
  • 同一ユース ケース パッケージに所属するユース ケース
  • 最も重要なユース ケース。この種のダイアグラムは、モデルのまとめとしての機能を果たし、ユース ケース ビューに包含される可能性があります。
  • 同じ追加において、同時に作成されたユース ケース

各ダイアグラムは、ユース ケース モデルの適切なパッケージに所属する必要があります。

ユース ケース図について詳しくは、「ガイドライン: ユース ケース図」を参照してください。

ユース ケース モデル概要の作成 ページの先頭へ

ユース ケース モデルの概要説明の記述には以下が含まれます。

  • ユーザーがユース ケースを利用する典型的なシーケンス
  • ユース ケース モデルによって処理されない機能

ガイドライン: ユース ケース モデル」の「概要の説明」も参照してください。

結果の評価 ページの先頭へ

この段階で、作業が予定どおりに進んでいるかどうかを確認するためにユース ケース モデルをチェックします。モデルの詳細なレビューは行いません。また、ユース ケース モデルの作業を行っている間、ユース ケース モデルのチェックポイントを考慮に入れる必要もあります。特に、「作業: 要求のレビュー」のアクター、ユース ケース、ユース ケース モデルのチェックポイントを参照してください。

この段階では、開発チーム外の人 (ユーザーと顧客など) がユース ケース モデルを承認することが重要です。したがって、この作業を終える前に、ユーザーと顧客がユース ケース モデルをレビューする必要があります。ユース ケース モデルの概要レポートとそのユース ケース図を、ディスカッションのガイドとして使用できます。

関係者は以下の事項を確認する必要があります。

  • 必要なユース ケースはすべて識別されたか
  • 不必要なユース ケースがあれば、識別されたか
  • 各ユース ケースの振る舞いは、正しい順序で実行されたか
  • 各ユース ケースのイベント フローは、この段階で可能な限り完了しているか
  • ユース ケース モデルの概要説明は理解可能か

レビューが必要なその他の問題について詳しくは、「作業: 要求のレビュー」のアクター、ユース ケース、ユース ケース モデルのチェックポイントを参照してください。



Rational Unified Process   2003.06.15