generated at
ユースケース

1987 年に Ivar Jacobson が提唱して依頼、広く使われてきた要求分析技法
UML では、ユーザー (アクター) とユースケースの関係がユースケースモデルとして表される
ユースケースの分割 : ユースケーススライス

ユーザー要求を引き出し、文書化するために使用される技法
システムと外部のアクターとの間の、アクターにとって価値ある結果をもたらしうる一連の相互作用を記述するもの
アクターは、システムと相互作用してユースケースを実行する人やシステムのこと
ユースケースの名前は 「目的語 + 名詞」 の形
設計仕様に踏み込んではならない (あくまでユーザーが相互作用についてどう考えているかを示す)
ユースケースの構成
ユースケースは、1 つのユースケースシナリオをイベントの通常フローとする
通常フロー以外の成功シナリオを代替フローや副シナリオと呼ぶ
ユースケースが、ユースケースのテンプレートに含まれない追加情報や要求を含むことも多い (関連する品質要求や制約条件など)
ユースケースとしては 「その他の情報」 に記載しておく
最終的には、ソフトウェア要求仕様書や要求文書の他の要素に落ち着くはず
ネットワーク障害への対応などの例外処理は、全ユースケースに書くのではなく、実装すべき追加機能要求とすべし
複数のユースケースをつなげたマクロなユースケースも作りえる
「カタログを検索する」 「商品をカートに入れる」 「カート内の商品を購入する」 といったユースケースをつなげた 「商品を購入する」 というユースケース

システムの利害関係者に対するシステムの振る舞いを記述したもの
利害関係者とシステムの間でどのようなやり取りが行われるかを順序に沿ったシナリオで表現する
記述する粒度がある
ビジネスレベルのユースケース (上流工程で業務分析を行うためのもの)
システムレベルのユースケース
ビジネスルールユースケース記述とは別のドキュメントにすると良い

ユースケースは、アジャイルの前に Ivar Jacobson の本で有名になった

関連

参考文献