ユースケース
OOAでは機能要求を「ユースケース図」に記述する。
「ユースケース図」にはユースケースの説明文として以下のような「ユースケース記述」が付与される。主処理フローはメインフローに記述されるがケースにより代替フロー、例外フローも記述される。またフロー開始時の条件は事前条件、終了時の条件は事後条件、ビジネスルールなどは事前事後に適用される不変条件として記述する。
なお、ユースケース図の各要素（特にフローと条件）はイテレーティブに記述が追記・変更されることが前提である。
【ユースケース名】商品を購入する
【概要】本ユースケースは、Web上および店頭で商品を購入する際に呼び出される。店頭では、店員を通じて本ユースケースが利用される【アクター】
- Webユーザー
- 店員（オペレータ）
【事前条件】
- アクターがログイン済であること
【メインフロー】
- アクターは、購入したい商品のジャンルを選ぶ
- システムは、選択されたジャンルの商品一覧を返す
- アクターは、商品を選ぶ
- システムは、商品の詳細情報（説明、金額、写真）を返す
- アクターは、この商品でよければ商品購入手続きに入る
ユースケースはユースケース名を決めた時点で粒度が決まるが、その粒度を小さくしすぎて機能数が増大してしまう落とし穴がある。これを回避するため「ユーザの認識できる言葉」でユースケース名をきめていく必要がある。
機能単位をユースケースにするな
ユースケースの単位を、機能分割の感覚で作ってしまいます。そのようなユースケースは、ユーザーの視点から見ると時系列を伴うものが多く、時系列を表すすべがないユースケース図には不適切であり、また、ユースケースの個数が膨大になってしまいます。
ユースケースは「技術」「性能」「品質」に依存しない。DBが変わったりFWやPGLがかわってもユースケースには影響しない。
データベースがどこにあるかなどは問題ではない
よくある誤解が、例えば「商品を登録する」というユースケースの中にデータベースが存在すると勘違いしてしまうことです。この勘違いから、「商品を参照する」というユースケースに関連を持つアクターからも「商品を登録する」に関連を引いてしまいます。
ユースケースには変更されやすいホットスポット、変更されにくいコールドスポットがある。そしてコールドスポットがあるユースケースにはBRが含まれることが多い。逆にBRがないユースケースはホットスポットとなりやすい。優先順位が高いのは前者だ。ロバストネス分析でBRの数を数えればそれが開発優先順位の指標となる。勿論数が多い方が優先順位が高い。変わりにくい、またはビジネスにとって重要なユースケースから始めるのだ。
最後に洗い出されたユースケース全体を眺めて粒度をそろえる。
