作業:
|
目的
|
|
役割: システム分析者 | |
頻度: 必要に応じて。通常は反復ごとに複数回、方向づけフェーズと推敲フェーズの反復では頻繁に行う。 | |
ステップ | |
入力とする成果物: | 結果となる成果物: |
詳細情報: | |
ツール メンター: |
ワークフローの詳細: |
アクターの獲得は、システムの使用方法を定義する第一歩です。システムと相互作用する外部現象の各タイプは、アクターによって表現されます。アクターを獲得するには次の質問をします。
これらのカテゴリに 1 つ以上該当する個人、グループ、現象がアクター候補です。
適切な (人間の) アクターがあるかどうかを判定するには、アクターを演じられる人を 2 ~ 3 人あげ、そのアクターの集まりがアクターのニーズに十分応えられるかどうかを確認します。アクターの構成内容について詳しくは、「ガイドライン: アクター」を参照してください。
最も適切なアクターを獲得するのは最初は難しいかもしれません。また、すべてのユース ケースを獲得していないので、すぐにはすべてのアクターを獲得できないでしょう。ユース ケースで作業することが、システム環境と、システムとの相互作用の理解を深める唯一の方法です。ここまでくると、最初はあまりにも多数のアクターを使いすぎる傾向にあることから、最初のモデルを変更したくなるかもしれません。アクターを変更する場合は注意が必要です。導入する変更がユース ケース自体にも影響を与える可能性があるからです。アクターに変更を加えると、システムのインターフェイスと振る舞いにも大きな変更をもたらすことを忘れないでください。
アクターの名前はアクターの役割をはっきりと示す必要があります。今後の段階において、アクターの名前が別のアクターの名前と混同されるリスクがないようにします。
各アクターを定義するには、アクターの責任分野とアクターが何のためにシステムを必要とするのかを簡単に記述します。アクターはシステム外のものを表すため、詳細に記述する必要はありません。「ガイドライン: アクター」の「概要」も参照してください。
最初のアクターの概要作成ステップが完了したら、システムのユース ケースを獲得します。最初のユース ケースは準備段階なので、安定するまで何度か変更が必要になります。システムの構想や要求が不十分であったり、システムの分析が曖昧だったりすると、システムの機能は不明確になります。したがって、正しいユース ケースを獲得したかどうかを常に自問し続ける必要があります。さらに、最終バージョンに到達するまでには、ユース ケースの追加、削除、組み合わせ、分割などに備える必要があります。ユース ケースを詳細に記述すると、ユース ケースの理解が深まります。
ユース ケースを獲得する最良の方法は、各アクターがシステムに何を要求しているのかを検討することです。システムはユーザーのためにだけ存在するため、システムはユーザーのニーズに基づくべきだということを忘れないでください。システムに要求する機能を見れば、アクターのニーズがかなりわかるでしょう。アクターが人間であろうとなかろうと、アクターごとに次の質問を自問してみます。
これらの質問に対する答えは、ユース ケース候補を識別するイベント フローを表します。すべてが別々のユース ケースを構成するわけではなく、同一のユース ケースの変形としてモデル化するものもあります。どれが変形で、どれが別個の異なるユース ケースかを見分けるのはいつも簡単とはかぎりません。ただし、イベント フローを詳細に記述すると明確になります。
要求以外では、組織のエンタープライズ モデル (ビジネス モデルとも呼ばれる) が、ユース ケースの決定に役立つ貴重な情報源です。エンタープライズ モデルは既存の業務に情報システムを取り入れる方法を示したものなので、システムの環境がどうなっているかがよく理解できます。エンタープライズ モデルには企業の「ビジネス オブジェクト」が含まれているので、エンタープライズ モデルで定義する必要のある概念も見出すことができます。
システムには、ユース ケースになりそうなモデルが複数ある場合があります。「最適な」モデルを見つける最良の方法は、2 ~ 3 個のモデルを作成して好みのものを選び、それをさらに開発することです。代替モデルをいくつか開発していけば、システムの理解に役立ちます。
最初のユース ケース モデルの概要を作成する場合には、ユース ケース モデルが全機能要求を包括していることを確認します。すべてのユース ケースがすべての要求を満たすよう、要求を入念に吟味します。
ユース ケースについて、およびその獲得方法について詳しくは、「ガイドライン: ユース ケース モデル」と「ガイドライン: ユース ケース」を参照してください。
各ユース ケースには、アクターとの相互作用によって何が遂行されるかを示す名称を付けるべきです。理解を助けるために、名称の長さは数語に及ぶことがあります。複数のユース ケースに同じ名称を付けることはできません。「ガイドライン: ユース ケース」の「名前」も参照してください。
簡単な説明を付けてユース ケースを定義します。説明を付ける際には用語集を参照します。必要に応じて、新しい概念を定義します。「ガイドライン: ユース ケース」の「概要」も参照してください。
この時点で、ユース ケースについてイベント フローの最初のドラフトも書きます。各ユース ケースのイベント フローを、簡単な性能の集まりとして記述します。詳細は必要ありません。後でユース ケースを指定する人は、たとえ自分自身であっても、このような段階的な記述を必要とします。イベントの基本的なフローの概要から開始し、これに納得できたら、代替フローを追加します。
リサイクルマシン システムのリサイクル アイテムという、ユース ケースのイベント フローの最初の段階的な記述は、次のようになります。
- 顧客が「開始」ボタンを押す
- 顧客がリサイクル品を入れる
- システムが、投入されたリサイクル品の種類を確認する
- 受け取った品目タイプのその日の合計が増加される
- 顧客が「レシート」ボタンを押す
- システムがレシートを印刷する
システムの要求の中には、特定のユース ケースに割り当てられないものもあります。これらを補足仕様書 (「成果物: 補足仕様書」を参照) に収集します。
アクターとユース ケースの関係を示すことは重要なため、ユース ケースを獲得したら、どのアクターがユース ケースと相互作用するのかを確立します。これには、アクターとユース ケース間のシグナル伝達と同一方向に誘導可能なコミュニケーション関連を定義する必要があります。
シグナル伝達は通常、双方向に行われます。この場合、コミュニケーション関連は双方向に誘導可能にする必要があります。アクターとユース ケースの各ペアに、最も多い場合でも、コミュニケーション関連を 1 つだけ定義します。
定義する各コミュニケーション関連について簡単な説明も付けます。
コミュニケーション関連について詳しくは、「ガイドライン: コミュニケーション関連」を参照してください。
アクターまたはユース ケースの数が多くなりすぎた場合は、それらをユース ケース パッケージに分割して、ユース ケース モデルの保守を簡単にします。これによりユース ケース モデルの把握も容易になり、開発者がユース ケースまたはアクターのパッケージを担当することによって、ユース ケース モデルの責任の割り当てが簡単になります。
次の場合には、別の方法でユース ケースをパッケージ化できます。
ユース ケースのモデル化にはこれ以外の方法もあります。ただし、モデルを直観的にわかりやすく保つには、パッケージ化する際に明白な戦略を使用することが重要になります。
ユース ケース パッケージについて詳しくは、「ガイドライン: ユース ケース パッケージ」を参照してください。
関連するユース ケース同士の関係だけでなく、ユース ケースとアクター間の関係も、ユース ケース モデルのダイアグラムで表現できます。このダイアグラムには以下が含まれる場合があります。
各ダイアグラムは、ユース ケース モデルの適切なパッケージに所属する必要があります。
ユース ケース図について詳しくは、「ガイドライン: ユース ケース図」を参照してください。
ユース ケース モデルの概要説明の記述には以下が含まれます。
「ガイドライン: ユース ケース モデル」の「概要の説明」も参照してください。
この段階で、作業が予定どおりに進んでいるかどうかを確認するためにユース ケース モデルをチェックします。モデルの詳細なレビューは行いません。また、ユース ケース モデルの作業を行っている間、ユース ケース モデルのチェックポイントを考慮に入れる必要もあります。特に、「作業: 要求のレビュー」のアクター、ユース ケース、ユース ケース モデルのチェックポイントを参照してください。
この段階では、開発チーム外の人 (ユーザーと顧客など) がユース ケース モデルを承認することが重要です。したがって、この作業を終える前に、ユーザーと顧客がユース ケース モデルをレビューする必要があります。ユース ケース モデルの概要レポートとそのユース ケース図を、ディスカッションのガイドとして使用できます。
関係者は以下の事項を確認する必要があります。
レビューが必要なその他の問題について詳しくは、「作業: 要求のレビュー」のアクター、ユース ケース、ユース ケース モデルのチェックポイントを参照してください。
Rational Unified Process
|