ユースケース
各ユースケースは、1つの目標やタスクを成し遂げる方法を描く。ソフトウェアプロジェクトでは、開発予定のシステムに関するユースケースを数十ほど描く場合がある。そのソフトウェアプロジェクトの形式性の度合いやプロジェクトの段階によってユースケースに求められる詳細さのレベルが変化する。
ユースケースとシステムの機能は一致するとは限らない。1つのユースケースが複数の機能に対応していることもある。1つの機能が複数のユースケースに対応していることもある。
ユースケースは、あるゴールを成し遂げるにあたっての外部のアクターとシステムとのやり取りを定義する。アクターはそのシステムとやり取りする人間や物の「役割」である。実際には1人の人間であっても、役割が複数あれば複数のアクターとして描かれる。例えば、A さんが現金自動預け払い機(ATM)で預金を引き落とす場合には「顧客」であるが、同じ A さんが実は「銀行員」として ATM にお金を補充するなら、それは別の役割である。
ユースケースではシステムをブラックボックスとして扱う。したがってシステムの反応を含めたシステムとのやり取りは外部から観測されるものとして描かれる。
ユースケースには以下のような限界もある:
ユースケースはシステムに関する機能以外の要求を把握するのには向いていない。
ユースケースのテンプレートは明確性を自動的に保証することはできない。明確性は作者の技量に依存する。
正確性が重要なミッションクリティカルなシステムやリアルタイムシステムには向いていない。
エンドユーザーとプログラマについて、ユースケースを正しく理解する際の学習曲線が存在する。標準化された定義が存在しないため、理解は徐々に深めていくしかない。
エクストリーム・プログラミングではユースケースが不必要に文書的になっているとし、むしろもっと単純なユーザーストーリーという手法を好む。
ユースケースを書く際に、ユーザーインターフェイスに依存するレベルをどうすべきかに悩むことがある。理論的にはユースケースはいかなるユーザーインターフェイスも前提としないことになっているが、何らかのインターフェイスを前提としないとユースケースを視覚化できないのである。
ユースケースはプラットフォームの要求仕様記述には向いていない。ユースケースは実装すべき1つのシステムを想定しているが、プラットフォーム(ハードウェアやオペレーティングシステム)はその上でいくつものシステムが動作するのである。
ユースケースは強調されすぎる傾向がある。Object Oriented Software Construction(第2版)でバートランド・メイヤーはユースケースに忠実にシステムを設計するあまり、他の有用な要求分析技法を排除してしまう問題を論じている。
ユースケースはソフトウェアへの要求仕様を把握する成熟したモデルである。従来、新たなシステムの設計を開始する際には1つの分厚い文書の形式で要求仕様がまとめられていたが、完全性という意味では失敗することが多かった。
(ユースケースを記述することも含めた)ユースケース・モデリングは、一般にシステムの機能要求を把握するための素晴らしい技法とされている。
ユースケースは早まった設計を防止する。
ユースケースは検証可能である。
ユースケースは見積もり・スケジューリングなどの基盤としても使用できる。
ユースケースはプロジェクト内で再利用可能である。版を重ねる毎に、要求仕様の把握、プログラマのための開発ガイドライン、テストケース、ユーザー向け文書に利用できる。
ユースケースの代替経路によってシステムの頑健性を強化することができる。
ユースケースは範囲設定に有効である。ユースケースは段階的リリースを行いやすくする。プロジェクト内での優先順位に従って、追加・削除が比較的容易である。
ユースケースはビジネスユーザーに理解しやすいことを旨としており、開発者とエンドユーザーの意思疎通に役立つ。