背景
最近食事にいくと、テーブルに置かれた QRコードを読み取ってそこからスマホで注文する形式の飲食店が増えている気がする。
もし、このシステムを構築してくれと頼まれたときを想定して、RDRA で要件定義してみる。
※本来は、Saas のテナント型の仕組みになっていそうだけど、今回は無視して考える。
コンテキストモデル
まずは、登場人物とシステム、外部システムを洗い出す。
使ったことは無いが、おそらく店舗側の管理サイトがあるだろう。
QRコードの印刷機も連携して毎回印刷していると思う。
システム構築の目的については、整理した後で記述する。
システム要求
システムへの要求事項を以下にリストアップした。
要求一覧
- QR コードを読み取って、スマホからメニューを注文できるようにしたい
- 注文したメニューは、各スマホから履歴を確認したい
- 注文する際は、いくつかのメニューをまとめて注文したい
- キッチンでは、何が注文されたかリアルタイムで把握したい
- メニューは店舗オーナーが登録できるようにしたい
- 売り切れメニューは注文できないようにしたい
- スマホから会計（注文終了）したい
- 決済自体はシステム上で行わずに、店舗の既存システム上で行う
一旦このままにしておく。
あとで図示する。
ビジネスコンテキスト
主要な業務を洗い出す。
飲食店の業務はなんとなく想像で書いてみる。
おそらく、店長がメニュー作成してたりするんじゃなかろうか。。。
この辺の業務は、MTG 時に詳しく確認したい。
情報モデル
システムの中で使われていそうな用語（概念）を関連づける。
とりあえず最初のモデルとして、用語の洗い出しと関連付けをしてみた。
QRコード発行のあたりが怪しい気がする。
後からどんどん増えると思うが、いったん置いておく。
状態モデル
状態が変化していく情報があれば、ここで洗い出す。
テーブル
注文伝票
メニュー
以外といくつか出てきた。
ユースケース
ひとまず一覧で書き出す
思ったこと
- おそらく、メニューやカテゴリーは事前にマスターデータの登録が必要。
- QR コードの印刷タイミングは、お客さんがテーブルに着いた後なのか、事前なのかは確認しておきたい。
- お客さんから注文された料理はキッチン側でリアルタイムに確認できないといけないし、調理し終わったらステータスを変更できるようにしなきゃいけないだろう。（操作端末はタブレットとか？）
- 料理のステータスとして「調理済み」と「提供済み」は分ける必要があるだろうか？（調理して完成しているが、まだテーブルに運んでいないというステータスは重要？）
- 注文の追加（未確定）の状態は、客同士の端末で共有する必要があるか？
今回のシステムにおいて
→ QR コードはお客さんが来店する前から印刷して、テーブルに用意しておくことにする。
→「調理済み」というステータスは考えないことにする。
→ キッチンには、タブレット端末を 2 台、モニターを 1 台設置する設定。
→ 客同士の端末で、注文未確定の状態も共有することにする。
業務フローからユースケースを書き出す
メニュー表作成
注文～食事～会計
思ったこと
- ラストオーダーの概念が必要か？
- お客さんからシステム経由でなく直接注文された場合など、お客さん側の操作を店員側でも実施できる必要があるか？
- テーブルステータスは食事中にどのタイミングで更新すべきか？他にステータスは持たなくて良いか？
- 客「QR コード無くした」と言われたら、再発行必要？
- 客「間違って大量に注文した、キャンセルしてくれ」と言われたら、注文取消できる機能必要？
今回のシステムにおいて
→ ラストオーダーの概念は必要
→ 店員側でお客さんの操作ができる必要あり
→ 最初のメニューをお客さんが注文した時点でテーブルのステータス変更とする
→ QR コードの再発行も必要とする
→ 確定済みの注文の取消も店員側でのみ可能とする
不足しているフローを追加する
注文代行
QR コード再発行
ラストオーダー
注文取消
フローを書き出せたので、今度は状態遷移を再検討する
料理注文の状態遷移
・ステータスを 4 種類用意した
・「注文を追加する」から「料理を注文伝票に追加する」に変更した
・「注文を確定する」から「注文伝票内の料理注文を確定する」に変更した
この時点のユースケースの一覧を確認する
次は、情報との整合性を確認する
いったん終了。
この後、ユースケースと情報を洗練させていく感じで進める予定。（架空）