ユースケースと機能の違い

質問

基本的な質問で失礼します。
ユースケースと機能の違いは何でしょうか。
例えばシステムが注文を受け付ける場面を想定した場合、

ユースケース方式：商品を注文する
機能分割方式：注文登録機能

「UMLによる統一ソフトウェア開発プロセス」を読むと、
「ユースケースとは"特定のアクター"にとって"価値ある明確な
結果"を出すもの」と説明されています。

表現自体があいまいですが、ニュアンスは読み取れます。
ユーザ側から見ればシステムが何をもたらすのか把握しやすい
というメリットがあると思います。
が、開発者側から見た場合、従来の機能分割方法と何が異なる
のかが良く分かりません。
むしろ内部的な機能や、重要な業務ロジックを漏れなく記述する
ためには従来の機能分割方式の方が優れているように思えます。
実際顧客との要件定義セッションでは、画面やロジックについて
詳細な要求が出されるケースも多いと思います。

ユースケースのように「あえて」抽象化するような作業によって
記述漏れが起きるのではないかと思えます。

上記を踏まえ、改めてユースケースと機能の違いについてどなたか
教えて頂けますでしょうか。
もし違いがないとすれば、レベル感の異なる要求をユースケース
にまとめることはできるのでしょうか。
(例えば重要業務ルールを別資料にしてユースケースからリファー
するといった方法を取るのでしょうか)

回答No.1

hegemon · ベストアンサー

＞ユースケースと機能の違いは何でしょうか。

ユースケースとは仕様を記述するときの単位です。
機能は、設計における実装の単位です。

＞ユーザ側から見ればシステムが何をもたらすのか把握しやすい
＞というメリットがあると思います。

この点はそのとおりですね。

＞が、開発者側から見た場合、従来の機能分割方法と何が異なる
＞のかが良く分かりません。

上記のとおり、利用目的と場面が異なります。
ユースケースはシステム要求を利用者から聞きだしまとめるためのものですから、「従来の機能分割方法」を置き換えるものではありません。
むしろ、ユースケースを基にして、より詳細な機能分割を行うべきです。

＞実際顧客との要件定義セッションでは、画面やロジックについて
＞詳細な要求が出されるケースも多いと思います。

そうした「詳細な要求」は、必ずしもそのまま実装できる形では得られないことが多く、実装を意識してまとめようとすると顧客が混乱してしまう危険性があります。
その場合は、より抽象度の高いユースケースとしてまとめ、それを設計段階で実装可能な機能へと分割・詳細化すべきでしょう。
また、ユースケースは最終的な総合テストにおけるテスト項目としても役立ちます。