この記事はユースケース駆動開発実践ガイドメモの振る舞い要求（ユースケース作成）について記載します。
ドメインモデリングで定義した言葉を使ってユースケースを作成していきます。
##ユースケースを作成する理由
本書では、以下のように記載されてます。
ユースケースは「ユーザーがこのシステムで何をしたいか？」「ユーザは何を得たいのか？」の手助けになる。
ユースケースはエンジニア以外でも理解できるし作成できるので、ユースケースが多かったり複雑な場合は工数が大きくなる理由を伝えやすいし、伝わりやすいです。
予定よりも工数がかかりそうなら特定の機能は初回リリースからは外すなどのアクションも取れるので、規模が大きい案件ほど大事な工程だと感じてます。
ユースケースを作成する時間は実案件ではなかなか取れないかと思いますが、仕様を明確にする武器として使っていけるかと思います。
また、DDDを取り組む際にもユースケースは有用ですので、本記事で少しでもその足掛かりになればと思います。
##ユースケースの抽出
ユーザのアクションとそれに対応するシステムの振る舞いを基本コースと代替コースのそれぞれ記載します。
ここでの題材は前回のハンバーガーショップを例にします。
商品一覧から商品をショッピングカートに入れるまでを考えてみます。
前回のドメインモデル同様、正解はないのでチーム内での意見がまとまれば良いと思います。
###基本コース
基本コースは正常範囲内のケースを記載します。
システムは商品一覧ページを表示する。
ユーザは商品一覧から商品をクリックする。
システムは商品詳細ページを表示する。
ユーザは数量を選択してショッピングカートに追加ボタンをクリックする。
システムは選択した数量の商品をショッピングカートに追加する。
###代替コース
代替コースは正常範囲外のケースを記載します。
想定外の数量が選択されて、ショッピングカートに追加しようとした場合
システムはエラーメッセージを表示し数量を0にする。
販売終了した商品が選択されていて、ショッピングカートに追加しようとした場合
システムはエラーメッセージを表示し商品一覧ページを表示する。
アクター、バウンダリ(画面名)、振る舞いが記述されていることがわかります。
振る舞いはコードを実装する際のコントローラ部分となることが多いです。
商品一覧ページを表示
商品詳細ページを表示
ショッピングカートに追加
もし、この基本コースがログインしている前提なら事前条件を記載したくなりますが、それはまたログインに焦点を合わせた別の基本コースとして書くべきです。
シンプルかつ言葉を明確に書くことで抜け漏れを減らすことができます。
もし、入力フォームなどの基本コースを記載する場合、システムによっては入力項目が多くなることが予想されますが、その場合は以下のようにシンプルで大丈夫です。
システムはアカウント作成ページを表示する。
ユーザはユーザ情報（名前、メールアドレス、パスワードなど）を入力して登録ボタンをクリックする。
システムは顧客アカウントを作成してをメッセージを表示する。
フィールド名が多い場合はまとめてクラス名で記載して良いです。
厳密にするともっとユースケースがありますが、大まかな内容は以上になります。
##まとめ
ユースケースは「ユーザーがこのシステムで何をしたいか？」「ユーザは何を得たいのか？」の手助けになりますし、全体の規模感も見え始めて早いタイミングでやるやらないの材料ともなります。