ユースケース
各ユースケースには少なくとも1つの基本シナリオあるいは典型的なイベントの流れが存在する。基本イベント経路は例えば以下のようなステップとして描かれる:
システムはユーザーにログオンを促す。
ユーザーは名前とパスワードを入力する。
システムはそのログイン情報を確認する。
システムはシステムにログを残す。
... などなど。
これは意図的に設定された方針であり、ユースケース作成者はシステムがどう動作するかではなく何をするかに集中しなければならない。これによって特定の実装方法を暗黙のうちに前提としてしまう罠を避けるのである。
ユースケースには、ビジネスユースケースとシステムユースケースがある。これらの違いはその対象範囲だけである。ビジネスユースケースはビジネス全体をブラックボックスとして扱い、そのビジネスと外部のアクターとのやりとりを描く(例えば、顧客が何かを購入するシナリオなど)。ビジネスユースケースの詳細によりビジネスのプロセスが定義される。
ビジネスユースケースを具体化することで、労働者がそのビジネスでどのように協力してビジネスの外部アクターに価値を提供するかが説明される。労働者の一部でも自動化されるなら、その自動化される部分はシステムユースケースの対象となる。その場合、他の労働者や外部アクターはそのシステムユースケースでのアクターとなる。
ユースケース作成の際の注意点は以下の通りである:
特定のゴールを達成するためにシステムをアクターがどう使うかを描く。
実装を限定するような言葉を使わない。
適切なレベルの詳細さで描く。
ユーザーインターフェイスや表示などの詳細を含めない。これらはユーザーインターフェイス設計の範疇である。
ユースケースには特別な言語を必要としない。個々のプロジェクトに合った形で書くことができる。
ユースケースでストーリーを記述することができる。ユースケースをストーリーやシナリオに変換するのは非常に簡単である。
ユースケースはユーザーとシステムのやりとりに関するものである。ユーザーインターフェイス設計者はソフトウェア本体の開発以前に(あるいは並行して)開発に参加することができる。
ユースケースは文脈の中に要求仕様を入れ、ビジネスタスクとの関連でそれらを明確に説明する。
ユースケース図はシステム開発依頼者にシステムやそのビジネス領域を理解させやすい。
ユースケース図を作成するためのUMLツールが各種存在する。ユースケースやユースケース図を CASE ツールで作成すれば、他の設計書類と共に統合され、完全な要求・設計・実装に関する書類が保存できるようになる。
テストケースの一部(システムテスト、受け入れテスト、機能テスト)はユースケースから直接作成可能である。
ユースケースはパフォーマンス・エンジニアリングの効率的実行に重要である。