ユースケース

ユースケースとは

ユースケースは、ソフトウェア工学やシステム工学において、システム（またはシステムの集合）の機能要件と振る舞いを把握するための技法です。各ユースケースは、特定の目的や機能に関するシナリオとして、アクターと呼ばれる利用者（エンドユーザーや他のシステム）とシステムの相互作用を描写します。

ユースケースの歴史

1986年、イヴァー・ヤコブソンによってユースケースの視覚化モデリング技法が初めて成文化されました。当初は「usage scenarios」や「usage case」という用語が使われていましたが、より自然な英語表現として「use case」という用語が定着しました。ヤコブソンの提唱後、カート・ビトナー、アリステア・コーバーン、グンナー・オーヴァーガードらによって改良が加えられ、1990年代には機能要件を把握する手法として広く利用されるようになりました。

ユースケースの目的と範囲

ユースケースは、特定の目標やタスクを達成するためのアクターとシステムのやり取りを定義します。ソフトウェアプロジェクトでは、数十個のユースケースが作成されることもあります。ユースケースの詳細は、プロジェクトの形式や段階によって変化します。

ユースケースとシステムの機能は必ずしも一致せず、1つのユースケースが複数の機能に対応したり、1つの機能が複数のユースケースに対応したりすることもあります。ユースケースではシステムをブラックボックスとして扱い、外部から観測できるやり取りに焦点を当てることで、実装の詳細にとらわれずにシステムの目的を明確にすることができます。

ビジネスユースケースとシステムユースケースの2種類があり、対象範囲が異なります。ビジネスユースケースはビジネス全体を対象とし、システムユースケースはビジネスの一部である自動化された部分を対象とします。

ユースケース作成時の注意点

特定のゴールを達成するためにシステムをアクターがどう使うかを描く。
実装に限定するような言葉を使わない。
適切なレベルの詳細さで記述する。
ユーザーインターフェースや表示などの詳細を含めない。

ユースケースの書き方

Alistair Cockburnは、ユースケースの詳細度を3段階に分類しています。

1. 要約 (brief) ユースケース: ユースケースを数文でまとめたもので、スプレッドシートなどでソフトウェア開発を計画するのに適しています。
2. 略式 (casual) ユースケース: 要約ユースケースをより詳しく文章化したもので、ストーリーのように記述します。
3. 詳細 (detailed) ユースケース: 複数の節に分かれたテンプレートに従って記述する定形文書で、一般的にユースケースといえばこの詳細ユースケースを指します。

プロジェクトの規模や段階に応じて、適切な詳細レベルのユースケースを作成する必要があります。開発初期段階では要約レベルで十分ですが、開発が進むにつれて、より詳細な記述が求められるようになります。

ユースケースのテンプレート

詳細ユースケースを記述するための標準的なテンプレートは存在しませんが、一般的に以下の節が含まれます。

ユースケース名: ユースケースを一意に識別するための名前。
版数: ユースケースのバージョンを示す番号。
概要: ユースケースの目的と内容を簡潔に説明する概要。
事前条件: ユースケースを開始するために満たされている必要のある条件。
トリガー: ユースケースを開始させるイベント。
基本の経路: ユースケースの典型的なシナリオ。
代替経路: 例外的な状況や異なるシナリオ。
事後条件: ユースケースが完了したときに満たされる条件。
ビジネスルール: ユースケースに関連するビジネス上の規則。
注: その他の重要な情報。
作者と作成日: ユースケースを作成した人と日付。

ユースケース記述の例

ユースケース名

「書籍を検索する」のように、名詞と動詞の組み合わせで、完了可能なゴールを示すことが望ましいです。

基本の経路

システムは検索画面を表示する。
ユーザーは検索キーワードを入力する。
システムは検索結果を表示する。

代替経路

ユーザーが検索キーワードを入力しない場合、エラーメッセージを表示する。
検索結果が見つからない場合、その旨を表示する。

ユースケース図

ユースケースとアクターの関係は、ユースケース図で視覚的に表現できます。これは、UML（統一モデリング言語）の一部として定義されており、SysMLでも同様の記述が利用できます。

ユースケースと開発工程

ユースケースは、開発方法論によって異なる使われ方をします。一部の方法論では、ユースケース調査のみが必要とされますが、他の方法論では、開発の進行に合わせてユースケースを詳細化し、ビジネスユースケースからシステムユースケース、そしてテストケースへと発展させていきます。

ユースケースの長所

機能要求を把握するための成熟したモデルである。
早まった設計を防止する。
検証可能である。
見積もりやスケジューリングの基礎として利用できる。
プロジェクト内で再利用可能である。
システムの頑健性を高めることができる。
範囲設定や段階的リリースを容易にする。
開発者とエンドユーザー間のコミュニケーションを円滑にする。
特別な言語を必要としない。
ストーリー形式で記述できる。
ユーザーインターフェース設計の基礎となる。
要求事項を文脈に沿って明確にする。
ユースケース図はシステム開発依頼者に理解しやすい。
テストケースの作成に利用できる。
パフォーマンスエンジニアリングに役立つ。

ユースケースの限界

機能以外の要件を把握するのには向いていない。
テンプレートが明確性を保証するものではない。
ミッションクリティカルなシステムやリアルタイムシステムには不向きな場合がある。
エンドユーザーとプログラマが理解するための学習が必要。
エクストリームプログラミングでは、ユーザーストーリーを好む傾向がある。
ユーザーインターフェースに依存するレベルをどうすべきか悩むことがある。
プラットフォームの要求仕様記述には向いていない。
ユースケースを重視しすぎると、他の有用な要求分析技法を排除する可能性がある。

まとめ

ユースケースは、システム開発において、ユーザーの視点から機能要件を明確にするための強力なツールです。適切なレベルの詳細さで記述し、その長所と限界を理解した上で活用することで、開発プロジェクトを成功に導くことができます。

もう一度検索