ユースケースの粒度について

ソフトウェアの目的は、

ソフトウェアがどのような人に、どう使われるか

と表現されている。（下記リンク参照）
その通りだと思う。

それが前提にない（忘れられてしまった）ソフトウェア開発は失敗する。
これは、ユースケースの粒度にも表れる。


そもそも、ユースケースとは？

ユースケースは、以下の2つで構成される。

• ユースケース図
• ユースケース記述

様々な記事に書かれている通り、真に重要なのは「ユースケース記述」の方。
ユースケース（＝システムの利用例）は、利用者がシステムを使って実現したい機能（目的）のみ表現できればいいとされている。

抽出したユースケースが、果たして「利用者の目的」であるのかどうかは、アリスター・コーバーン氏の表現がわかりやすい。
アリスター・コーバーンは「主アクターはこれを実行した後で満足して立ち去れるか」という質問に対応するものと書いている。

JUDEでは、ユースケースのレベルを以下の4つで管理できるようだ。

• 要約レベル
• ユーザ目的レベル
• ユーザ機能レベル
• サブ機能レベル

もちろん、ユースケース図は「ユーザ目的レベル」で表現する。

技術者から見ると、「商品を購入する」というユースケースには複数の機能が含まれており、ユースケースが洗い出しきれていないのでは？と思ってしまいがち。
また、それら機能はユースケースとして表現もできる。が、ここで原点に戻らなくてはならない。

また、ユースケースモデルの描き方（ポイント）が紹介されているので抜粋する。

• 機能単位をユースケースにするな
• データベースがどこにあるかなどは問題ではない
• アクターの正しい理解
• システムの根拠がないまま挙動を書いてしまう
• 要求はユースケースかユースケース記述に書く

原則としてユースケース図かユースケース記述にシステムのすべての要求を書くとのこと。
「すべての要求」を書くとあるが、ドキュメント過多には十分注意する必要がある。
ムダなドキュメント（記述）であるなら省略する必要がある。
もちろん、要件定義に必要な記述は漏れなく洗い出す必要がある。

最後に、ユースケースモデルで整理できる要求は、「機能要求」のみである。
「非機能要求」はユースケースに記述することはできない。
（拡張性、再利用性、パフォーマンス、信頼性など）
これは一覧にまとめる、とされている。

＠IT：連載：【改訂版】初歩のUML　第8回
ユースケース重要！（not 図、but 記述) - An Agile Way [ITmedia オルタナティブ・ブログ]