はじめに
UMLは覚えておくべき(概念編) の続編です。
個人的に、ユースケース記述はアジャイル開発では必須だと考えています。
アジャイル開発でなくても、自分の整理のために作っておくのは有効です。
TDD,BDDをもっとうまくする訓練にもなるので、一度は作ってみてください。
記載する内容
| 項目名 | 概要 |
|---|---|
| ユースケース名 | ユースケース名を表示 |
| 概要 | 概要を入力 |
| アクター | 関連するアクターを表示 |
| 事前条件 | 事前条件を入力 |
| 事後条件 | 事後条件を入力 |
| 基本フロー | 基本の処理 |
| 代替フロー | 処理が継続できる処理フロー |
| 例外フロー | 処理が継続できなくなる処理フロー |
| シナリオ | 上記内容を具体化した項目で入力する |
何が大事なのか
ユースケース記述を記載するのは、漠然と捉えているシステムをできるだけ具体化するためです。
ただし、ユースケース記述のシナリオ以外はあまり具体的に書くと、保守性が落ちるので具体的には書かないほうがよいです。
例えば、下記に記載した例では、「通知する」、という概要にとどめておき、それがメールなのか、プッシュ通知なのか、という点は記載しません。
ユースケース名、概要に記載すること
どういう機能を実現するかを記載します。
アクターに記載すること
登場しうる人物、および権限(ロール)を書くものです。
ユーザー、管理者、保守者等々。
ここに他システムを表現するかどうかはちょっとわかりません…。
下記例だと、slackAppがアクターとして表現するのか、それともシステム化対象の内容なので登場しないのか…。
正確には、BoltがSlackとやり取りしているので、システム化対象はBolt、アクターとしてSlackは出てきてもおかしくはないと思いますが、bolt自体がslackAppを作るためのフレームワークだということを考えると、悩みます…。
事前条件に記載すること
文字通りですが、ここがどれだけ具体化されているかで後工程が楽になると思います。
例えば、以下の2点では「決済画面」でも実装すべき内容が異なると思います。 - 「代引きで商品購入できるようにしよう」 - 「PayPayで商品購入ができるようにしよう」
ここで具体化しておかないと、後で他の人に「決済画面既に作ったんじゃないの？」みたいな指摘が入る可能性があります。
何をどこまで考慮しているのか、というのを明文化しておくことが大事になります。
WaterFallなら、最終的に要望は全部作ることになると思いますが、アジャイルだと優先度が高いものから作る、という性質上、どこまで作ったか、考慮したかはあるべきだと思います。
事後条件に記載すること
これが無いとテストが書けません。
正直、最初にこれを書くのはしんどいので、コードを書きながら考えたい気持ちはあるのですが、TDDで開発するのであれば、ある程度は考えておかないと手戻りが発生します。
基本フローに記載すること
ユースケースを満たすために必要な処理を記載します。
この時、アクターの行動はシステムに対してどういう要求をするのか、逆にシステムがアクターに対して何を返却するのかを明確にするために、それぞれ別で書くと良いと思います。
代替フロー、例外フローに記載すること
代替フローも例外フローも基本フローではない例外ですが、そのあとの処理が違います。
代替フローは基本フローに戻ることができる処理を記載します。
例外フローは基本フローに戻ることができない処理を記載します。
また、代替フロー、例外フローは、個人的には重要な項目だと考えています。
なぜなら、誰もがシステムの処理で一番興味が無い部分だからです。
言われたら、「そのケースも考慮しないとね」って話は膨らみますが、最初からこのフローを考えつくのは相当な専門家くらいだと思います。
逆に、ここを網羅できるようであれば、システムとしては完璧なものになっていると自信をもっていいと考えています。
代替フローの詳細
どういう条件で、どこの処理に復帰するか、という点を記載します。
例として、存在しない郵便番号を入力すると、修正するまで基本フローに戻れない、等。
備考ですが、基本フローと代替フロー、例外フローが自動で連携するエディタ、およびツールはまだ存在しないので、書くのは非常にめんどくさいです…。
1つ項番がずれただけで、全部後続の項番を直す作業は非常に大変…。
例外フローの詳細
例として、注文中に対象の商品が完売したので、購入できません。
といった基本フローに戻れない処理を記載します。
なお、ここで記載するのは業務上の起こりうる内容だけで良いです。
処理中にシステムダウンした場合、等々まで含めるとキリがないですから…。
シナリオに記載すること
ユースケース記述と異なり、具体的に記載します。
具体的に記載することで、曖昧な理解を取り除くことができます。
1週間分のデータ、という表現が当日を含めるのか、含めないのかがわかるように具体的に記載します。
シナリオはそのまま、BDD(振る舞い駆動開発)として使うことができます。
Gherkin記法で表現できるので、エンジニアがテストとして使いつつ、一般の人に理解してもらう仕様書としても利用できます。
Gherkin記法
| 記載方法 | 記載する内容 |
|---|---|
| GIVEN | 事前条件 |
| WHEN | 処理 |
| THEN | 事後条件 |
実際のプロジェクトでは使ったことはありませんが、Cucumberというライブラリで実装できます。
具体的にはどういうことを書くか
Challenge-Every-MonthコミュニティのCem太郎にコントリビュートしたときに、脳内で描いていたものを記載します。
- ユースケース名
- 中間振り返りを行う
- 概要
- 月末・月初に立てた目標を中旬に振り返り、コミュニティの参加者に報告する
- アクター
- 挑戦者(目標を立てた人)
- コミュニティ参加者
- 事前条件
- 挑戦者が登録されている
- 月末・月初に目標を立てていること
- 目標をコミュニティ全員に報告していること
- 目標の完了報告を行っていないこと
- 事後条件
- コミュニティ全員に中間報告していること
- 基本フロー
- 挑戦者がシステムに中間報告を開始することを通知する
- システムが挑戦者に中間報告が開始できる画面を通知する
- 挑戦者がシステムに中間報告を行う
- システムが挑戦者が行った中間報告をコミュニティ全員に報告する
- 代替フロー
iii. 中間報告の際に必須項目が入力されていない- 必須項目を入力するまで報告できない
- 基本フローiii.に復帰する
- 例外フロー
iv.中間報告中に月末の完了報告を行った
- 処理対象の目標が無いことを通知する
- 処理を終了する
- シナリオ1
- 挑戦者が月中に目標作成、および発表を行った内容を中間振り返りする。
- シナリオ詳細
- きり丸が4/15に目標作成し、4/15に発表した目標を4/20に中間振り返りする。
- 事前条件
- きり丸が挑戦者として登録されている
- きり丸が4/15に目標作成している
- きり丸が4/15に目標を発表している
- 事後条件
- 中間報告用チャンネルに中間報告を行われている
- フロー
- きり丸がSlackのスラッシュコマンド(cem_progress)でSlackに中間報告開始を通知する
- Slackがきり丸に中間報告のできる画面を表示する
- きり丸が中間報告に必要な内容をすべて記載し、保存ボタンを選択する
- Slackが中間報告用チャンネルに中間報告の内容を表示する
- シナリオ2
- 挑戦者が月末に目標作成、月初に発表を行った内容を中間振り返りする。
- シナリオ詳細
- きり丸が3/31に目標作成し、4/2に発表した目標を4/20に中間振り返りする。
- 事前条件
- きり丸が挑戦者として登録されている
- きり丸が3/31に目標作成している
- きり丸が4/2に目標を発表している
- 事後条件
- 中間報告用チャンネルに中間報告を行われている
- フロー
- きり丸がSlackのスラッシュコマンド(cem_progress)でSlackに中間報告開始を通知する
- Slackがきり丸に中間報告のできる画面を表示する
- きり丸が中間報告に必要な内容をすべて記載し、保存ボタンを選択する
- Slackが中間報告用チャンネルに中間報告の内容を表示する
- シナリオ3
- 挑戦者が複数たてた目標を一度に中間振り返りする
- シナリオ詳細
- きり丸が3/31に1つ、4/1に2つ目標作成し、4/2に発表した目標を4/20に中間振り返りする。
- 事前条件
- きり丸が挑戦者として登録されている
- きり丸が3/31に1つ目標作成している
- きり丸が4/1に2つ目標作成している
- きり丸が4/2に目標を発表している
- 事後条件
- 中間報告用チャンネルに3つとも中間報告を行われている
- フロー
- きり丸がSlackのスラッシュコマンド(cem_progress)でSlackに中間報告開始を通知する
- Slackがきり丸に目標3つとも中間報告のできる画面を表示する
- きり丸が中間報告に必要な内容をすべて記載し、保存ボタンを選択する
- Slackが中間報告用チャンネルに中間報告の内容を表示する
終わりに
例で記載したのは、複雑ではないので書く労力と比べるとトントンですかね…。
実際のシステムでは、理解度が低いほど書くたびに理解が明確になっていくので、かなり有効でした。
流石に、実際のシステムの内容を書くわけにはいかないので、伝わりづらかったと思いますが、記事を見てくださった方の一助になればと思います。
