https://qiita.com/s3imamura/items/41949e5a76a8d19f2acd の続き
ユースケースと情報モデルの整合性を合わせる
ユースケースと情報モデルの整合性を確認してみる。
とりあえず、現状確認
ユースケース一覧
情報モデル
情報モデルの更新
まずは、ユースケース上で出てくる用語の内、情報モデルに含まれていないものがないか確認する。
ユースケースに出てくる文言「注文料理」「料理提供」を追加した。
ユースケースと情報モデルの関連付け
ユースケースと情報の関連を繋いでみる。
「オーダーストップ」と「メニュー」の関連はなんか変な感じ。
店舗情報として営業時間、最終注文時刻（オーダーストップ）を設けるべきと思う。
曜日によって、営業時間は異なるかかどうかでデータの持ち方が変わるだろうか。
「テーブル」の管理はユースケースに必要かも。
お客さんの人数によっては、テーブルを統合させたりするケースもありそうだ。
とりあえずこのシステムにおいては以下を想定する。
→ 曜日は問わず、11:00 ～ 14:00（LO:13:30）、17:30 ～ 22:00（LO:21:30）営業
→ 店の配置席数自体が大きく変わることはないが、お客さんの人数によっては、複数のテーブルをひとつに統合したりする場合もある。
ユースケースと情報の関連付け修正
さっきの懸念点を踏まえて、ユースケース情報関連、情報モデル、ユースケース一覧を修正してみる。
次は、サイトマップ（画面一覧）を作成しながら、ユースケースを調整する
ユースケースと画面の整合性
まずは、どんな画面が必要か思いつくままにリストアップしてみる。
店舗側とお客さん側両方の画面をそれぞれ考える。
おそらく、店舗のフロアスタッフとしては、現在の店舗のテーブルステータス（満空状況、未提供の料理注文数、合計金額）を俯瞰して把握できる画面がほしいだろう。
また店舗の調理スタッフとしては、現在の料理注文のステータス（何がいつ注文されて、未提供なのか）を俯瞰して把握できる画面がほしいだろう。
お客さん側には必要ないけど、店舗側には ID ／パスワード等による認証機能が必要だろう。
ユースケースと画面の関連をつなぐ
一覧で出した画面とユースケースをひとまず思いつくままにつないでみる。
不足する画面やユースケースが存在する場合は適宜更新する。
追加、更新した要素は、黄緑色にした。
・ユースケースの文言を「QR コードを印刷する」→「QR コードを発行する」に変更した。
・ユースケースの文言を「注文された料理を見る」→「料理の注文状況を見る」に変更した。
・ユースケース「ログイン／ログアウトする」を追加した。
・画面「テーブル詳細」を分割した。
論理 ERD のたたき台を作成
RDRA の範疇からは外れてしまうが、ユースケースの整合性合わせたり、ここではじめて気づくこともあるので、要件定義の中でも早めに論理 ERD を作成していく。
※物理は考えない
とりあえず、今のユースケースを満たすようなデータ構造を考える。
ユースケース外でも必要と思われるデータがあれば適宜追加する。
思ったこと
- アカウントって複数必要なんだろうか？
- 1 コで良い気がする
- QR コードは有効期限が必要と思う
- 発行から 2~3 時間くらい？
- QR コードは「再発行」じゃなくて「再印刷」のほうが良いかも
- 「発行」だとトークンも変わってしまうイメージがした
- テーブルの状態遷移はもう少し考えるほうが良さそう
- 「（テーブル統合による）非活性化、活性化」と「食事中、食事終了」のステータスは分けて考えるほうがよい
- 「伝票に登録しているけど注文確定していない状態からのキャンセル」と「注文確定からの取消」を区別できるようにしなきゃいけない
- データ構造だけでなく、用語も考え直すべき
- 取消とキャンセルって一緒じゃねーか）
- （ほんとは前から思ってたけど、無視してたら、ここに来てやっぱり問題になった感じ）
- データ構造だけでなく、用語も考え直すべき
- 金額はどこに持つか？
- 売り切れとオーダーストップは、同じステータスで管理してもよいか？
- というか「QR コード」って発行するものじゃなくて、単なる出力形式か
- 本当に発行しているのは「トークン」
- 注文確定させる前の仮置場のようなもの
- ショッピングカートの概念に近い
- お客様側で使っている用語がなければ「注文カート」とする。
- あれ、というか、注文カートってデータ持たないほうがよいな。
- 複数人で同時に注文とかした場合とか、勝手に注文されたり、気づかずに重複して注文したりして、店舗側のオペレーションがめんどくさくなりそう
- ということをお伝えして、注文カートは各端末で管理。すなわち DB では関与しないとする
- ユースケース、情報モデルにも反映する
- まとめて料理を注文する際の単位も業務上、大きな意味はなさそうなので「注文伝票」「注文伝票明細」テーブルは「料理注文」にまとめる
上記考慮して ERD 更新する。
いったんここまで。
論理 ERD で色々と考えることがあったので、清書も兼ねて他のモデルにも反映させていく。
それができたら、お客様に説明しつつ懸念点など一緒に確認してもらう予定。