ユースケース（Use Case）は、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム）の機能要求を含む振舞を把握するための技法である。各ユースケースは、何らかの目的・目標/機能に関する台本（シナリオ）での主体（アクター(actor)）と呼ぶ利用者（ユーザ）とシステムのやりとりを描いている。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行う。ユースケースを図にしたものがユースケース図であり、両者を厳密に区別すべき根拠はない。

1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイヴァー・ヤコブソンは、初めてユースケースの視覚化モデリング技法を成文化した。当初彼は usage scenarios とか usage case という用語を使用していたが、それらが英語として不自然であると気づき use case という用語を使うようになった[1]。ヤコブソンが創始したユースケースのモデリングに対して、Kurt Bittner、アリスター・コーバーン（英語版）、Gunnar Overgaard といった人々が改良を加えていった。

1990年代、ユースケースは機能要求を含む振舞を把握する手法として使われるようになってきた。発祥の分野であるオブジェクト指向関連で顕著である[要出典]。ユースケースの有効性はオブジェクト指向に限らない。ユースケースの仕様は、オブジェクト指向とは直接的な関係がない。

システム工学において、ユースケースはソフトウェア工学よりも抽象度の高いレベルで利用され、システムの任務やシステム保有者の目標を描くのに使われる[要出典]。より詳細な要求は SysML のリクワイアメント図などで把握される。
ユースケースの目的と範囲

各ユースケースは、1つの目標やタスクを成し遂げる方法を描く。ソフトウェアプロジェクトでは、開発予定のシステムに関するユースケースを数十ほど描く場合がある[要出典]。そのソフトウェアプロジェクトの形式性の度合いやプロジェクトの段階によってユースケースに求められる詳細さのレベルが変化する。

ユースケースとシステムの機能は一致するとは限らない。1つのユースケースが複数の機能に対応していることもある。1つの機能が複数のユースケースに対応していることもある。

ユースケースは、あるゴールを成し遂げるにあたっての外部のアクターとシステムとのやり取りを定義する。アクターはそのシステムとやり取りする人間や物の「役割」である。実際には1人の人間であっても、役割が複数あれば複数のアクターとして描かれる。例えば、A さんが現金自動預け払い機(ATM)で預金を引き落とす場合には「顧客」であるが、同じ A さんが実は「銀行員」として ATM にお金を補充するなら、それは別の役割である。

ユースケースではシステムをブラックボックスとして扱う。したがってシステムの反応を含めたシステムとのやり取りは外部から観測されるものとして描かれる。これは意図的に設定された方針であり、ユースケース作成者はシステムがどう動作するかではなく何をするかに集中しなければならない。これによって特定の実装方法を暗黙のうちに前提としてしまう罠を避けるのである。

ユースケースには、ビジネスユースケースとシステムユースケースがある。これらの違いはその対象範囲だけである。ビジネスユースケースはビジネス全体をブラックボックスとして扱い、そのビジネスと外部のアクターとのやりとりを描く（例えば、顧客が何かを購入するシナリオなど）。ビジネスユースケースの詳細によりビジネスのプロセスが定義される。

ビジネスユースケースを具体化することで、労働者がそのビジネスでどのように協力してビジネスの外部アクターに価値を提供するかが説明される。労働者の一部でも自動化されるなら、その自動化される部分はシステムユースケースの対象となる。その場合、他の労働者や外部アクターはそのシステムユースケースでのアクターとなる。

ユースケース作成の際の注意点は以下の通りである:

特定のゴールを達成するためにシステムをアクターがどう使うかを描く。

実装を限定するような言葉を使わない。

適切なレベルの詳細さで描く。

ユーザーインターフェイスや表示などの詳細を含めない。これらはユーザーインターフェイス設計の範疇である。

ユースケースの書き方
詳しさの度合い

Alistair Cockburn の Writing Effective Use Cases には、ユースケース作成にあたって3段階の詳しさのレベルを定義している。
要約

要約(brief)ユースケースはユースケースをいくつかの文にまとめたものである。これはスプレッドシートを使ってソフトウェア開発を計画するのに最も適している。要約ユースケースはスプレッドシートのセルに書ける程度の長さであり、同じ行の別のセルにビジネス上の優先度、技術的複雑度、リリース番号などを記入する。
略式

略式(casual)ユースケースは、要約ユースケースの内容をより詳しく文章化したもので、ストーリーのような形でそのユースケースを詳述する。
詳細

詳細(detailed)ユースケースはいくつもの節に分かれたテンプレートに従って書かれる定形文書である。ユースケースといえばこれを指すのが一般的である。詳細ユースケースのテンプレートについては後の節で詳述する。
適切な詳細さ

ソフトウェア開発工程によっては単純なユースケースだけを要求定義に使用すればよい場合もある。しかし、場合によってはより詳細なユースケースが必要なこともある。プロジェクトの規模が大きければ大きいほど、ユースケースの詳細さが求められる傾向がある。

ユースケースの詳細さのレベルはプロジェクトの段階によっても異なる。最初のユースケースは要約程度でよいが、開発工程が進むに従って、より詳細なユースケースが必要となってくる。このためユースケースに要求されるものは異なってくる。当初はユーザーの観点でビジネス上の要求をまとめるための要約レベルのユースケースでよい。しかし、開発が進むと開発者は設計の指針として詳細なユースケースを必要とするようになってくる。

ラショナル統一プロセスでは、要約ユースケースをユースケース図として描き、コメントとして略式の記述を入れ、さらにイベントの流れについて詳細な記述を加えていく。これらを1つのユースケースツール（つまり、UMLツールなど）で入力できる場合もあるし、もちろん別々にテキストエディタで書くことも可能である。
ユースケースのテンプレート

詳細ユースケースを文書化する際の標準的なテンプレートは存在しない。いくつかの方式が存在しており、プロジェクト毎にいずれかを選ぶか開発者が適当なものを選んで使用している。特定の方式の詳細の比較よりもプロジェクト内で標準化する方が重要である。