ユースケース

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

1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイヴァー・ヤコブソンは、初めてユースケースの視覚化モデリング技法を成文化した。当初彼は usage scenarios とか usage case という用語を使用していたが、それらが英語として不自然であると気づき use case という用語を使うようになった。ヤコブソンが創始したユースケースのモデリングに対して、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ツールなど︶で入力できる場合もあるし、もちろん別々にテキストエディタで書くことも可能である。

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

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

典型的な節には以下のものがある:

●ユースケース名

●版数

●概要

●事前条件

●トリガー

●基本の経路

●代替経路

●事後条件

●ビジネスルール

●注

●作者と作成日

テンプレートによってはこれ以外の節も追加している。例えば、﹁仮定﹂、﹁例外﹂、﹁推奨﹂、﹁技術的要求﹂などである。また、業界によって特殊な記述が追加されることもある。

ユースケース名

ユースケース名はユースケースを一意に識別するためのものである。名詞と動詞の組み合わせにするのが望ましい︵﹁本を借りる﹂﹁現金をおろす﹂など︶。また、完了可能なゴールにするのが望ましい︵﹁ユーザー登録﹂ではなく﹁ユーザーを登録する﹂が好ましい︶。また、エンドユーザーがそのユースケースが何を描いたものか理解できる程度の詳しさが望ましい。ゴール駆動型ユースケース分析ではユースケース名としてアクターのゴールに対応したものを採用し、ユーザー指向の立場を鮮明にする。単語数としては2つから3つが適切である︵日本語の場合、助詞は数えない︶。それ以上長くなるとしたら、発想を転換して同じ意味のもっと短いフレーズにすべきである。

版数

そのユースケースの段階を示すため版数が必要になることが多い。ビジネス分析のための最初のユースケースは、ソフトウェア開発中に使われる詳細化された版とはかなり異なることがある。また、古い版のユースケースが現状の文書に残っていることもあるため、どの段階のユースケースであるかを示す必要が出てくる。

概要

ユースケースの本体が完成する以前にその概要を記述する節である。これによって読者が簡単に概要を知ることができる。基本的には数個の文で記述され、ゴールと主なアクターに関する説明を含む。

事前条件

そのユースケースを開始する時点で真である条件を記述する節である。ただし、ユースケースを開始させるトリガーとは異なることに注意されたい。一部でも事前条件が真でない場合、そのユースケースを実行したときにどうなるかは不確定である。

トリガー

トリガーとは、そのユースケースを開始するための条件である。外部的条件、時間的条件、内部的条件がありうる。

基本の経路

各ユースケースには少なくとも1つの基本シナリオあるいは典型的なイベントの流れが存在する。基本イベント経路は例えば以下のようなステップとして描かれる:

(一)システムはユーザーにログオンを促す。

(二)ユーザーは名前とパスワードを入力する。

(三)システムはそのログイン情報を確認する。

(四)システムはシステムにログを残す。

… などなど。

代替経路

ユースケースには同じテーマに関する第二の経路や代替シナリオが存在する場合もある。例外的な状況や問題が発生した場合なども記述できる︵そのために別の節を専用に用意してもよい︶。代替経路では、基本経路のステップに番号を振っておいて、何番目のステップで枝分かれするのか、あるいは場合によっては何番目で基本経路と合流するのかを記述する。これは、同じ情報を反復して書く無駄を省くためである。

代替経路の記述例は以下の通り:

1. システムはユーザーのマシン上のクッキーを認識する。

2. 基本経路のステップ4へ

例外的経路の記述例は以下の通り:

3. システムはユーザーのログオン情報を認識しない。

4. 基本経路のステップ1へ

Anthony J.H. Simons と Ian Graham によれば、代替経路はユースケースには本来存在しなかった。各ユースケースは1つの経路毎に描かれていた。そのため、ユースケースに基づいてシステムを設計するには多数のユースケースを描く必要があった。そういった意味では、ユースケースはドキュメンテーションというよりも純粋に調査のためのものだったのである。

事後条件

シナリオが完了した時点で真であるべき条件である。

ビジネスルール

ビジネスルールとは、そのユースケースに関して、組織のビジネスとして行う際に従うルールであり、明文化されている場合と明文化されていない場合がある。ビジネスルールは特殊な仮定条件である。ビジネスルールは特定のユースケースにだけ関わるものもあれば、全ユースケースに関わるものもあるし、場合によってはビジネス全体に関わるものもある。

注

経験上、どんなテンプレートを使っても、どこにも当てはまらない重要な情報がある。そのため、どのテンプレートにもそのような情報を記述する節が存在する。

作者と作成日

この節では、この版のユースケースの作者と作成日を記述する。また、以前の版についても同様の情報を記述すべきである。しかし、これはユースケースの本質的部分ではないため、最後に記述するのがふさわしい。ユースケースは複数の人々の協力によってできるものであり、個人が所有権を主張すべきものではない。

ユースケースの記述法

ユースケースとアクターの関係はユースケース図で図示できる。これはイヴァー・ヤコブソンの Objectory に基づいた統一モデリング言語の一部である。SysMLでも同様の記述をシステムブロックレベルで使用する。

ユースケースと開発工程

開発工程でのユースケースの使われ方は、その開発における方法論によって異なる。一部の開発方法論では、単なるユースケース調査が必要とされるだけである。他の方法論では開発の進行に従ってユースケースを詳細化させ、性格を変化させていく。また別の方法論ではビジネスユースケースから開始し、より詳細化したシステムユースケースへと発展させ、さらに非常に詳細なテストケースへと発展させていく。

ユースケースの長所

ユースケースはソフトウェアへの要求仕様を把握する成熟したモデルである。従来、新たなシステムの設計を開始する際には1つの分厚い文書の形式で要求仕様がまとめられていたが、完全性という意味では失敗することが多かった。

●︵ユースケースを記述することも含めた︶ユースケース・モデリングは、一般にシステムの機能要求を把握するための素晴らしい技法とされている。

●ユースケースは早まった設計を防止する。

●ユースケースは検証可能である。

●ユースケースは見積もり・スケジューリングなどの基盤としても使用できる。

●ユースケースはプロジェクト内で再利用可能である。版を重ねる毎に、要求仕様の把握、プログラマのための開発ガイドライン、テストケース、ユーザー向け文書に利用できる。

●ユースケースの代替経路によってシステムの頑健性を強化することができる。

●ユースケースは範囲設定に有効である。ユースケースは段階的リリースを行いやすくする。プロジェクト内での優先順位に従って、追加・削除が比較的容易である。

●ユースケースはビジネスユーザーに理解しやすいことを旨としており、開発者とエンドユーザーの意思疎通に役立つ。

●ユースケースには特別な言語を必要としない。個々のプロジェクトに合った形で書くことができる。

●ユースケースでストーリーを記述することができる。ユースケースをストーリーやシナリオに変換するのは非常に簡単である。

●ユースケースはユーザーとシステムのやりとりに関するものである。ユーザーインターフェイス設計者はソフトウェア本体の開発以前に︵あるいは並行して︶開発に参加することができる。

●ユースケースは文脈の中に要求仕様を入れ、ビジネスタスクとの関連でそれらを明確に説明する。

●ユースケース図はシステム開発依頼者にシステムやそのビジネス領域を理解させやすい。

●ユースケース図を作成するためのUMLツールが各種存在する。ユースケースやユースケース図を CASE ツールで作成すれば、他の設計書類と共に統合され、完全な要求・設計・実装に関する書類が保存できるようになる。

●テストケースの一部︵システムテスト、受け入れテスト、機能テスト︶はユースケースから直接作成可能である。

●ユースケースはパフォーマンス・エンジニアリングの効率的実行に重要である。

ユースケースの限界

ユースケースには以下のような限界もある:

●ユースケースはシステムに関する機能以外の要求を把握するのには向いていない。

●ユースケースのテンプレートは明確性を自動的に保証することはできない。明確性は作者の技量に依存する。

●正確性が重要なミッションクリティカルなシステムやリアルタイムシステムには向いていない。

●エンドユーザーとプログラマについて、ユースケースを正しく理解する際の学習曲線が存在する。標準化された定義が存在しないため、理解は徐々に深めていくしかない。

●エクストリーム・プログラミングではユースケースが不必要に文書的になっているとし、むしろもっと単純なユーザーストーリーという手法を好む。

●ユースケースを書く際に、ユーザーインターフェイスに依存するレベルをどうすべきかに悩むことがある。理論的にはユースケースはいかなるユーザーインターフェイスも前提としないことになっているが、何らかのインターフェイスを前提としないとユースケースを視覚化できないのである。

●ユースケースはプラットフォームの要求仕様記述には向いていない。ユースケースは実装すべき1つのシステムを想定しているが、プラットフォーム︵ハードウェアやオペレーティングシステム︶はその上でいくつものシステムが動作するのである。

●ユースケースは強調されすぎる傾向がある。Object Oriented Software Construction︵第2版︶でバートランド・メイヤーはユースケースに忠実にシステムを設計するあまり、他の有用な要求分析技法を排除してしまう問題を論じている。

脚注

関連項目

• 統一モデリング言語 (UML)
• ユースケース図
• ビジネスケース

外部リンク

• Understanding Use Case Modeling ユースケース・モデリングの基本
• Precise Use Cases
• Estimating With Use Case Points ユースケースを使って、UMLでモデリングされたアプリケーションの規模を測る方法の解説
• Use Case Template （PDF）
• Use Case Tutorials ユースケースとユースケース駆動開発の紹介
• Use Cases (Usability.gov)