システム開発でユースケースって言葉が色んな意味で使われているので、
自分用に使い分けをまとめておきたいと思います。
ユースケース
ユースケースはシステム開発で、作成される開発資料のことですね。
ユーザーと開発するシステムの振る舞いを文章で簡潔に記述することができるので、
大規模なシステム開発である場合は、作成されることが多いですね。
システムを開発すると、数千万から数億円の費用がかかるので、その振る舞いを文章だけで記述できるのは本当に便利なんですね。
あとは、ISOの品質基準規格に準拠したウォーターフォールの開発だとほとんど作成されているのではないでしょうか。
色んなユースケース
それくらい重要なユースケースですが、
重要なだけあって色んな意味で使われています。
大きく分けて、ユースケース図・ユースケースシナリオ・ユースケース記述が使われていることが多いです。
たまに、USDMなんかも急に出てきたりします。
ユースケース図
ユースケースはシステムを操作する人がシステムに対して出来ることを端的に表したものですね。
個人的には、ユースケースと単に言ったときは「ユースケース図」を指していることが多いと思います。
過去記事でも紹介しましたが、チケット販売機のユースケースだと下図でしょうか。
あとで紹介するものより、わかりやすいということもあって非常に解りやすいです。
ユースケース図を書くときは、plantUMLが個人的にはおすすめですよ～。 xinformation.hatenadiary.com
ユースケースシナリオ
ユースケースシナリオは、各機能をどういうときにユーサーが使うかに着目した記述となります。
さっきのチケット販売機の場合は、システムとしてチケットを販売したり、会員権を購入したりすることはわかりますが、それらがどういったときに利用されるかわかりませんでした。
これは、どういうチケット販売機にもよるんですけど、たとえば会員でないとチケットを購入できないような状況でのチケットを購入するシナリオは1つで、
１．一般消費者はシステムを通じて会員権を購入する
２．一般消費者はシステムを通じてチケットを購入する
と連続で操作が行われます。
一方、会員にならなくてもチケットは購入出来る場合は単純に、
１．一般消費者はシステムを通じてチケットを購入する
となります。
これとは、また別のシナリオとして、
１．一般消費者はシステムを通じて会員権を購入する
が記述されます。
一見こんなことをして何の意味があるのか分からなくなりますけど、
前者の場合は、会員とチケットの購入のために連続して処理できる画面遷移が必要だよね～となりますが、
後者の場合は、チケットを購入し終わったらトップ画面に戻った方がいいよね～とか後々の仕様決定に影響してきます。
また、シナリオを書いてみてそこに登場して来ない機能は、重要度が低いから開発対象から取り除こうとかの判断ができます。
数百とか数千の機能もある過去機種の後継開発において、どの機能を削減すればよいか分からないとかなった場合はユースケースシナリオを書いてみると、本当に必要な機能を整理できると思います。
開発文書的には、こういった無味乾燥なものなのですが、
サービスの広告を作成するための企画資料になったりもします。
こんなときに使えますよ～と端的で解りやすいですね。
lineapiusecase.com
ユースケース記述
ユースケース記述は、各機能の振る舞いを表にまとめた記述法ですね。
wikipediaで掲載するくらい、有名な記述法なんですね。
この記述簡単そうで意外に書けないもので、結構書くのに苦労する人が多いです。
しかも、めちゃくちゃ重要でこれが書けていないと、そのあとの設計書だったり、開発者テストがひどいありさまになるんですよね。
実際の開発では、会社ごとに項目が違ってそこがノウハウだったりしますね～。
| 項目 | 備考 |
| ユースケース | 機能名を記述することが多い |
| バージョン | 何回改訂したかを記載 |
| 機能概要 | 機能内容を、簡潔な文章で記述 |
| 事前条件 | 機能を実行するための条件 たとえば、webアプリにおいてログインしているかとか |
| 開始条件 | 機能が実行される条件 |
| 基本の処理 | 処理を時系列順に記載する |
| 代替経路 | 基本の処理が実行できないときの処理 |
| 事後条件 | 基本の処理が完了したときにどうなってるべきか |
| 備考 | 性能とかを記述する |
USDM
少し本筋と外れるかもしれませんが、
USDMもユースケース記述として混同して使われている場合があります。
記述する項目が似ているからなんでしょうか。
ただそれぞれ、作成する目的が違っていて、ユースケースは利用者から見たシステムの振る舞いを記述するのに対し、USDMはシステムの内部の振る舞いを記述します。
USDMは使う人の目線はあまり重視されないんですね。
「要求仕様」を書くのがユースケースで、「設計仕様」を書くのがUSDMという理解です。
下記のUSDMに関しては文章が非常に参考になりました。
