ユースケース
ユースケース（Use Case）は、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム）の機能的要求を含む振舞を把握するための技法である。各ユースケースは、何らかの目的・目標/機能に関する台本（シナリオ）での主体（アクター(actor)）と呼ぶ利用者（ユーザ）とシステムのやりとりを描いている。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行う。ユースケースを図にしたものがユースケース図であり、両者を厳密に区別すべき根拠はない。
1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイヴァー・ヤコブソンは、初めてユースケースの視覚化モデリング技法を成文化した。当初彼は usage scenarios とか usage case という用語を使用していたが、それらが英語として不自然であると気づき use case という用語を使うようになった。ヤコブソンが創始したユースケースのモデリングに対して、Kurt Bittner、アリスター・コーバーン、Gunnar Overgaard といった人々が改良を加えていった。
1990年代、ユースケースは機能要求を含む振舞を把握する手法として使われるようになってきた。発祥の分野であるオブジェクト指向関連で顕著である。ユースケースの有効性はオブジェクト指向に限らない。ユースケースの仕様は、オブジェクト指向とは直接的な関係がない。
システム工学において、ユースケースはソフトウェア工学よりも抽象度の高いレベルで利用され、システムの任務やシステム保有者の目標を描くのに使われる。より詳細な要求は SysML のリクワイアメント図などで把握される。
詳しさの度合い
Alistair Cockburn の Writing Effective Use Cases には、ユースケース作成にあたって3段階の詳しさのレベルを定義している。
要約
要約(brief)ユースケースはユースケースをいくつかの文にまとめたものである。これはスプレッドシートを使ってソフトウェア開発を計画するのに最も適している。要約ユースケースはスプレッドシートのセルに書ける程度の長さであり、同じ行の別のセルにビジネス上の優先度、技術的複雑度、リリース番号などを記入する。
略式
略式(casual)ユースケースは、要約ユースケースの内容をより詳しく文章化したもので、ストーリーのような形でそのユースケースを詳述する。
詳細
詳細(detailed)ユースケースはいくつもの節に分かれたテンプレートに従って書かれる定形文書である。ユースケースといえばこれを指すのが一般的である。詳細ユースケースのテンプレートについては後の節で詳述する。
適切な詳細さ
ソフトウェア開発工程によっては単純なユースケースだけを要求定義に使用すればよい場合もある。しかし、場合によってはより詳細なユースケースが必要なこともある。プロジェクトの規模が大きければ大きいほど、ユースケースの詳細さが求められる傾向がある。
ユースケースの詳細さのレベルはプロジェクトの段階によっても異なる。最初のユースケースは要約程度でよいが、開発工程が進むに従って、より詳細なユースケースが必要となってくる。このためユースケースに要求されるものは異なってくる。当初はユーザーの観点でビジネス上の要求をまとめるための要約レベルのユースケースでよい。しかし、開発が進むと開発者は設計の指針として詳細なユースケースを必要とするようになってくる。
ラショナル統一プロセスでは、要約ユースケースをユースケース図として描き、コメントとして略式の記述を入れ、さらにイベントの流れについて詳細な記述を加えていく。これらを1つのユースケースツール（つまり、UMLツールなど）で入力できる場合もあるし、もちろん別々にテキストエディタで書くことも可能である。
ユースケース名
ユースケース名はユースケースを一意に識別するためのものである。名詞と動詞の組み合わせにするのが望ましい（「本を借りる」「現金をおろす」など）。また、完了可能なゴールにするのが望ましい（「ユーザー登録」ではなく「ユーザーを登録する」が好ましい）。また、エンドユーザーがそのユースケースが何を描いたものか理解できる程度の詳しさが望ましい。ゴール駆動型ユースケース分析ではユースケース名としてアクターのゴールに対応したものを採用し、ユーザー指向の立場を鮮明にする。単語数としては2つから3つが適切である（日本語の場合、助詞は数えない）。それ以上長くなるとしたら、発想を転換して同じ意味のもっと短いフレーズにすべきである。
版数
そのユースケースの段階を示すため版数が必要になることが多い。ビジネス分析のための最初のユースケースは、ソフトウェア開発中に使われる詳細化された版とはかなり異なることがある。また、古い版のユースケースが現状の文書に残っていることもあるため、どの段階のユースケースであるかを示す必要が出てくる。
概要
ユースケースの本体が完成する以前にその概要を記述する節である。これによって読者が簡単に概要を知ることができる。基本的には数個の文で記述され、ゴールと主なアクターに関する説明を含む。
事前条件
そのユースケースを開始する時点で真である条件を記述する節である。ただし、ユースケースを開始させるトリガーとは異なることに注意されたい。一部でも事前条件が真でない場合、そのユースケースを実行したときにどうなるかは不確定である。
トリガー
トリガーとは、そのユースケースを開始するための条件である。外部的条件、時間的条件、内部的条件がありうる。
事後条件
シナリオが完了した時点で真であるべき条件である。
ビジネスルール
ビジネスルールとは、そのユースケースに関して、組織のビジネスとして行う際に従うルールであり、明文化されている場合と明文化されていない場合がある。ビジネスルールは特殊な仮定条件である。ビジネスルールは特定のユースケースにだけ関わるものもあれば、全ユースケースに関わるものもあるし、場合によってはビジネス全体に関わるものもある。
注
経験上、どんなテンプレートを使っても、どこにも当てはまらない重要な情報がある。そのため、どのテンプレートにもそのような情報を記述する節が存在する。
作者と作成日
この節では、この版のユースケースの作者と作成日を記述する。また、以前の版についても同様の情報を記述すべきである。しかし、これはユースケースの本質的部分ではないため、最後に記述するのがふさわしい。ユースケースは複数の人々の協力によってできるものであり、個人が所有権を主張すべきものではない。
ユースケースの記述法
ユースケースとアクターの関係はユースケース図で図示できる。これはイヴァー・ヤコブソンの Objectory に基づいた統一モデリング言語の一部である。SysMLでも同様の記述をシステムブロックレベルで使用する。
ユースケースと開発工程
開発工程でのユースケースの使われ方は、その開発における方法論によって異なる。一部の開発方法論では、単なるユースケース調査が必要とされるだけである。他の方法論では開発の進行に従ってユースケースを詳細化させ、性格を変化させていく。また別の方法論ではビジネスユースケースから開始し、より詳細化したシステムユースケースへと発展させ、さらに非常に詳細なテストケースへと発展させていく。