概略ユースケースに代替パスと例外パスを追加

代替パスはユースケースを書いていくにしたがって浮き上がってきたもうひとつの別のシナリオのことです。 前述の「ビールを注ぐのが店員の場合か客の場合か？」などもその候補で、元のシナリオが店員が注ぐことになっていたら、客が注ぐケースは代替パスになります。

例外パスは途中でアクシデントなどが起こってエラーとなる場合です。まずは考え付く限りの例外パスを記載します。

　■タイトル
　ユースケース１ビールを飲む

　■アクター
　客（ビールを飲む人）
　店員（ビールを飲む人）

　■シナリオ
　１．店員がビールのプルタブを開ける。
　２．店員がグラスに注ぐ
　３．客が乾杯する。
　４．客がビールを飲む
　５．店員がグラスを洗う。
　６．店員がビールの缶を捨てる。

　■代替パス
　・手順２でお客さん同士で注ぎあう場合

　■例外パス
　１．ビールが品切れだった場合
　２．店員がビールのグラスを割ってしまった場合
　３．店員がビールをこぼしてお客さんにかけてしまった場合
　４．客がビールを飲んで酔っ払ってしまい、前後不覚になってしまった場合
　５．急に大地震が来た場合
　６．停電で真っ暗になってしまった場合
　７．客がビールを飲んでいる間に閉店になってしまった場合

　■要検討事項
　１．ビールは缶ビールのみで良いか？瓶ビールの場合は？
　　　→瓶ビールの場合は栓抜きを購入する必要があるのでコストが増す。
　２．何人で飲むのか？乾杯する必要はあるか？
　３．グラスを洗う必要はあるか？他のモジュールで洗ってくれるのではないか？
　４．ビール缶はどこに捨てるか？自治体によってリサイクルが行われているのでは？
　　　→顧客は社内用で群馬県内で使うといっていたのでリサイクルの必要はないと思われる。

極端な例ですみませんが、代替パス、例外パスともに（確率はさておき）起こりえることです。 実際は「ビールを飲む」ユースケースに大地震がきたりすることは書いても意味無いかも知れませんが、どこまで検討するかは物によります。飛行機や自動車のソフトウェアなどでは、生命の危険があるケースは出来る限り列挙しないといけないかも知れません。

意外に見落としがちな例外パスは７のようなものです。これは十分ありえるにも係わらず、これを検討しないで実装して、テスト段階やお客さんが受け入れ試験したり、あるいは実運用で始めて気がついてバグ修正するということになりがちです。 設計段階で気づけば少なくともそれに対応しないことによるリスク分析くらいは出来るはずです。