• 具体的な各ユース・ケースに、少なくとも 1 つのアクターが関与しているか。関連していない場合は、アクターと相互作用しないユース・ケースが余分であるなど、どこかに問題があるのでこのユース・ケースを削除する。詳細については、「ガイドライン: ユース・ケース」を参照。
    • 各ユース・ケースが互いに独立しているか。2 つのユース・ケースが常に同じシーケンスで活性化する場合は、1 つのユース・ケースに合併できる。
    • 包含されるユース・ケースの場合: 当該ユース・ケースを包含しているユース・ケースがあると仮定しているか。このような仮定は避けるべきです。そうすれば、包含されるユース・ケースが、ユース・ケースを含むユース・ケースの変更に影響を受けることがなくなる。
    • 非常に似た振る舞いやイベントのフローを持つユース・ケースがないか。該当するユース・ケースがあり、これらのユース・ケースの振る舞いを将来も類似させておく場合、1 つのユース・ケースに合併する。合併することによって、将来変更の導入が容易になる。注: ユース・ケースを結合する場合は、ユーザーの参加が必要である。ユーザーは、新しく結合したユース・ケースと相互作用するため、影響をうける可能性があるためである。
    • イベントのフローの一部が、ほかのユース・ケースとして既にモデル化されているか。この場合は、新しいユース・ケースは古いユース・ケースを使用できる。
    • イベントのフローの一部が、既にほかのユース・ケースの一部になっているか。この場合は、このサブフローを抽出し、該当するユース・ケースで使用する。注 : サブフローを再利用する場合は、ユーザーの参加が必要である。既存のユース・ケースのユーザーが影響を受ける可能性があるためである。
    • 1 ユース・ケースのイベントのフローを、ほかのイベントのフローに挿入できるか。この場合は、ほかのユース・ケースとの拡張関係を持つようにモデル化する。
    • 後の混乱を避けるため、ユース・ケースの名前が一意で、直感的、かつ説明的なものであるか。そうでない場合は名前を変更する。
    • 顧客とユーザーが同様に、ユース・ケースの名前と説明を理解しているか。各ユース・ケース名は、ユース・ケース・サポートの振る舞いを記述しなければならない。
    • ユース・ケースは、その性能を明白に左右している要求をすべて満たしているか。ユース・ケースの特殊な要求でのオブジェクト・モデルで処理するには、ユース・ケースのいかなる( 機能外) 要求も含んでいる必要がある。
    • アクターとユース・ケース間の通信シーケンスが、ユーザーの期待に応えているか。
    • ユース・ケースのイベントのフローについて、開始と終了の方法と時期が明確となっているか。
    • 特定の条件が満たされないときにのみ活性化する振る舞いが存在する。設定した条件が満たされない場合に起こる事態の説明があるか。
    • 過度に複雑なユース・ケースがないか。ユース・ケース・モデルを理解しやすくするために、複雑なユース・ケースは分割できる。
    • ユース・ケースに、本質的に異なるイベント・フローが含まれるか。その場合は、複数の異なるユース・ケースに分割することが最良である。本質的に異なるイベント・フローを持つユース・ケースは、理解と保守が非常に困難である。
    • ユース・ケースにあるサブフローが、正確にモデル化されているか。
    • ユース・ケースの実行を誰が望んでいるかが明らかであるか。ユース・ケースの目的が明らかであるか。
    • アクターの相互作用と交換情報が明らかであるか。
    • 説明がユース・ケースの実態を表しているか。


Rational Unified Process   2003.06.15