ユースケース（Use Case）とは、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム）の機能的要求を把握するための技法である。各ユースケースは、何らかのビジネス目標/機能に関するシナリオでのアクター(actor)と呼ばれるユーザーとシステムのやりとりを描いたものである。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行うことが多い。ユースケースとユースケース図は厳密には区別されるべきものである。1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイヴァー・ヤコブソンは、初めてユースケースの視覚化モデリング技法を成文化した。当初彼は "usage scenarios" とか "usage case" という用語を使用していたが、それらが英語として不自然であると気づき "use case" という用語を使うようになった。ヤコブソンが創始したユースケースのモデリングに対して、Kurt Bittner、Alistair Cockburn、Gunnar Overgaard といった人々が改良を加えていった。1990年代、ユースケースは機能要求を把握する手法として最もよく使われるようになってきた。特に元々の発祥の分野であるオブジェクト指向関連で顕著であるが、ユースケースの有効性はオブジェクト指向に限らない。というのも、ユースケース自体は本質的にはオブジェクト指向とは無関係だからである。システム工学において、ユースケースはソフトウェア工学よりも抽象度の高いレベルで利用され、システムの任務やシステム保有者の目標を描くのに使われることが多い。より詳細な要求は SysML のリクワイアメント図などで把握される。各ユースケースは、1つの目標やタスクを成し遂げる方法を描く。ほとんどのソフトウェアプロジェクトでは、開発予定のシステムに関するユースケースを数十ほど描く必要がある。そのソフトウェアプロジェクトの形式性の度合いやプロジェクトの段階によってユースケースに求められる詳細さのレベルが変化する。ユースケースとシステムの機能は必ずしも一致しない。1つのユースケースが複数の機能に対応していることもあるし、1つの機能が複数のユースケースに対応していることもある。ユースケースは、あるゴールを成し遂げるにあたっての外部のアクターとシステムとのやり取りを定義する。アクターはそのシステムとやり取りする人間や物の「役割」である。実際には1人の人間であっても、役割が複数あれば複数のアクターとして描かれる。例えば、A さんが現金自動預け払い機(ATM)で預金を引き落とす場合には「顧客」であるが、同じ A さんが実は「銀行員」として ATM にお金を補充するなら、それは別の役割である。ユースケースではシステムをブラックボックスとして扱う。したがってシステムの反応を含めたシステムとのやり取りは外部から観測されるものとして描かれる。これは意図的に設定された方針であり、ユースケース作成者はシステムがどう動作するかではなく何をするかに集中しなければならない。これによって特定の実装方法を暗黙のうちに前提としてしまう罠を避けるのである。ユースケースには、ビジネスユースケースとシステムユースケースがある。これらの違いはその対象範囲だけである。ビジネスユースケースはビジネス全体をブラックボックスとして扱い、そのビジネスと外部のアクターとのやりとりを描く（例えば、顧客が何かを購入するシナリオなど）。ビジネスユースケースの詳細によりビジネスのプロセスが定義される。ビジネスユースケースを具体化することで、労働者がそのビジネスでどのように協力してビジネスの外部アクターに価値を提供するかが説明される。労働者の一部でも自動化されるなら、その自動化される部分はシステムユースケースの対象となる。その場合、他の労働者や外部アクターはそのシステムユースケースでのアクターとなる。ユースケース作成の際の注意点は以下の通りである:Alistair Cockburn の "Writing Effective Use Cases" には、ユースケース作成にあたって3段階の詳しさのレベルを定義している。要約(brief)ユースケースはユースケースをいくつかの文にまとめたものである。これはスプレッドシートを使ってソフトウェア開発を計画するのに最も適している。要約ユースケースはスプレッドシートのセルに書ける程度の長さであり、同じ行の別のセルにビジネス上の優先度、技術的複雑度、リリース番号などを記入する。略式(casual)ユースケースは、要約ユースケースの内容をより詳しく文章化したもので、ストーリーのような形でそのユースケースを詳述する。詳細(detailed)ユースケースはいくつもの節に分かれたテンプレートに従って書かれる定形文書である。ユースケースといえばこれを指すのが一般的である。詳細ユースケースのテンプレートについては後の節で詳述する。ソフトウェア開発工程によっては単純なユースケースだけを要求定義に使用すればよい場合もある。しかし、場合によってはより詳細なユースケースが必要なこともある。プロジェクトの規模が大きければ大きいほど、ユースケースの詳細さが求められる傾向がある。ユースケースの詳細さのレベルはプロジェクトの段階によっても異なる。最初のユースケースは要約程度でよいが、開発工程が進むに従って、より詳細なユースケースが必要となってくる。このためユースケースに要求されるものは異なってくる。当初はユーザーの観点でビジネス上の要求をまとめるための要約レベルのユースケースでよい。しかし、開発が進むと開発者は設計の指針として詳細なユースケースを必要とするようになってくる。ラショナル統一プロセスでは、要約ユースケースをユースケース図として描き、コメントとして略式の記述を入れ、さらにイベントの流れについて詳細な記述を加えていく。これらを1つのユースケースツール（つまり、UMLツールなど）で入力できる場合もあるし、もちろん別々にテキストエディタで書くことも可能である。詳細ユースケースを文書化する際の標準的なテンプレートは存在しない。いくつかの方式が存在しており、プロジェクト毎にいずれかを選ぶか開発者が適当なものを選んで使用している。特定の方式の詳細の比較よりもプロジェクト内で標準化する方が重要である。しかし、主要な部分についてはどの方式でもほぼ一定である。方式による違いは用語の使い方や記述順序であり、本質的な違いはない。典型的な節には以下のものがある:テンプレートによってはこれ以外の節も追加している。例えば、「仮定」、「例外」、「推奨」、「技術的要求」などである。また、業界によって特殊な記述が追加されることもある。ユースケース名はユースケースを一意に識別するためのものである。名詞と動詞の組み合わせにするのが望ましい（「本を借りる」「現金をおろす」など）。また、完了可能なゴールにするのが望ましい（「ユーザー登録」ではなく「ユーザーを登録する」が好ましい）。また、エンドユーザーがそのユースケースが何を描いたものか理解できる程度の詳しさが望ましい。ゴール駆動型ユースケース分析ではユースケース名としてアクターのゴールに対応したものを採用し、ユーザー指向の立場を鮮明にする。単語数としては2つから3つが適切である（日本語の場合、助詞は数えない）。それ以上長くなるとしたら、発想を転換して同じ意味のもっと短いフレーズにすべきである。そのユースケースの段階を示すため版数が必要になることが多い。ビジネス分析のための最初のユースケースは、ソフトウェア開発中に使われる詳細化された版とはかなり異なることがある。また、古い版のユースケースが現状の文書に残っていることもあるため、どの段階のユースケースであるかを示す必要が出てくる。ユースケースの本体が完成する以前にその概要を記述する節である。これによって読者が簡単に概要を知ることができる。基本的には数個の文で記述され、ゴールと主なアクターに関する説明を含む。そのユースケースを開始する時点で真である条件を記述する節である。ただし、ユースケースを開始させるトリガーとは異なることに注意されたい。一部でも事前条件が真でない場合、そのユースケースを実行したときにどうなるかは不確定である。トリガーとは、そのユースケースを開始するための条件である。外部的条件、時間的条件、内部的条件がありうる。各ユースケースには少なくとも1つの基本シナリオあるいは典型的なイベントの流れが存在する。基本イベント経路は例えば以下のようなステップとして描かれる:… などなど。ユースケースには同じテーマに関する第二の経路や代替シナリオが存在する場合もある。例外的な状況や問題が発生した場合なども記述できる（そのために別の節を専用に用意してもよい）。代替経路では、基本経路のステップに番号を振っておいて、何番目のステップで枝分かれするのか、あるいは場合によっては何番目で基本経路と合流するのかを記述する。これは、同じ情報を反復して書く無駄を省くためである。代替経路の記述例は以下の通り:例外的経路の記述例は以下の通り:Anthony J.H. Simons と Ian Graham によれば、代替経路はユースケースには本来存在しなかった。各ユースケースは1つの経路毎に描かれていた。そのため、ユースケースに基づいてシステムを設計するには多数のユースケースを描く必要があった。そういった意味では、ユースケースはドキュメンテーションというよりも純粋に調査のためのものだったのである。シナリオが完了した時点で真であるべき条件である。ビジネスルールとは、そのユースケースに関して、組織のビジネスとして行う際に従うルールであり、明文化されている場合と明文化されていない場合がある。ビジネスルールは特殊な仮定条件である。ビジネスルールは特定のユースケースにだけ関わるものもあれば、全ユースケースに関わるものもあるし、場合によってはビジネス全体に関わるものもある。経験上、どんなテンプレートを使っても、どこにも当てはまらない重要な情報がある。そのため、どのテンプレートにもそのような情報を記述する節が存在する。この節では、この版のユースケースの作者と作成日を記述する。また、以前の版についても同様の情報を記述すべきである。しかし、これはユースケースの本質的部分ではないため、最後に記述するのがふさわしい。ユースケースは複数の人々の協力によってできるものであり、個人が所有権を主張すべきものではない。ユースケースとアクターの関係はユースケース図で図示できる。これはイヴァー・ヤコブソンの Objectory に基づいた統一モデリング言語の一部である。SysMLでも同様の記述をシステムブロックレベルで使用する。開発工程でのユースケースの使われ方は、その開発における方法論によって異なる。一部の開発方法論では、単なるユースケース調査が必要とされるだけである。他の方法論では開発の進行に従ってユースケースを詳細化させ、性格を変化させていく。また別の方法論ではビジネスユースケースから開始し、より詳細化したシステムユースケースへと発展させ、さらに非常に詳細なテストケースへと発展させていく。ユースケースはソフトウェアへの要求仕様を把握する成熟したモデルである。従来、新たなシステムの設計を開始する際には1つの分厚い文書の形式で要求仕様がまとめられていたが、完全性という意味では失敗することが多かった。ユースケースには以下のような限界もある:

出典:wikipedia