https://qiita.com/s3imamura/items/bdc516e2234744855d20
の続き
現状のモデルを見直し
ERD を描く段階で色々と更新箇所が出てきたので、いったんお客様へ確認する用として現状の各モデルをお清書する。
システムコンテキスト図
【目的】
システムに関わる人（役割）・外部システムを洗い出し、関係者間で合意すること。
【主要な確認事項】
システムの目的は過不足ないか？
モデル上に記載される用語は、普段業務の中で用いている用語と合っているか？
システムを利用するにも関わらず、モデル上に記載されていない役割の人はいないか？
システムを利用しないにも関わらず、モデル上に記載されている役割の人はいないか？
システムと連携するにも関わらず、モデル上に記載されていない外部システムはないか？
システムを連携しないにも関わらず、モデル上に記載されている外部システムはないか？
【確認を怠った場合に懸念されるリスク】
実際にシステムを利用するにも関わらずモデルに描画されていない役割の人が存在する場合、その役割からの「要求」や関わる「業務」が今後の検討から漏れる可能性があります。その場合、システムが完成して実際に使い始めてから「使いづらい」「システム化の意味がない」という声をいただくことになる可能性が高いです。
実際にシステムと連携するにも関わらずモデルに描画されていない外部システムが存在する場合、その外部システムとの連携の検討が遅れてしまい、当初のスケジュール通りに連携を実現できない可能性があります。
ビジネスコンテキスト／ビジネスユースケース図
【目的】
システムがどういった業務環境下で使われるのか、システム化対象となる業務を明示すること。
【主要な確認事項】
業務とアクター、システムの関連は適切か？
全体としていくつの業務があるのか明確になっているか？
業務ごとの粒度感は適切か？
価値を提供する単位に分割できているか？（ビジネスユースケース）
【確認を怠った場合に懸念されるリスク】
システムが利用される環境となる業務が漏れている場合、業務上の条件やバリエーションを十分に洗い出せない可能性があります。特に例外的なパターンへの対応などは、システムが利用される環境を十分に整理できていないと見逃されてしまい、「融通の効かないシステム」となる可能性が高いです。
情報モデル／用語集
【目的】
システム化対象となる業務に関連している用語・概念を構造化し、関係者間で合意すること。
用語の意味を定義し、プロジェクト関係者間での認識齟齬を防ぐこと。
【主要な確認事項】
現場で使われているが、モデルに記載されていない用語はないか？網羅されているか？
同義語、類義語がないか？
業務の中で用いられる語彙で言い換えられないか？
用語の説明は過不足ないか？（用語集）
用語の英語名は正しいか？（用語集）
【確認を怠った場合に懸念されるリスク】
プロジェクト関係者間同士の認識齟齬がほぼ必ず発生し、その対応のための手戻りでプロジェクトが遅延します。
同義語（英語）がプロジェクト間のコミュニケーションおよびソースコード内に頻発し、保守性が低下、バグ混入率が上昇します。
ユースケース／関連図
【目的】
構築対象のシステムにおいて、利用者および外部システムができること／できないことを明示すること。
また、システムの利用ケース各々が、業務上の流れ、起点となる画面および情報に不整合性がないかを確認すること。
【主要な確認事項】
ユースケースの粒度は揃っているか？
業務の流れとユースケースに不整合はないか？
画面とユースケースに不整合はないか？
情報とユースケースに不整合はないか？
【確認を怠った場合に懸念されるリスク】
システムの機能実現を妨げる要因の発見が遅れ、プロジェクトが遅延します。
関係者同士で機能の背景認識齟齬が発生し、想定と異なる成果物が作成される可能性が高くなります。
ユースケース一覧
業務フロー・ユースケース関連
マスター情報設定
注文～食事～会計
注文代行
QR コード再印刷
ラストオーダー
注文取消
画面・ユースケース関連
状態モデル
状態モデル一覧
| 情報 | ステータス |
|---|---|
| 食事ステータス | 食事中 |
| 食事終了 |
| 情報 | ステータス |
|---|---|
| メニューステータス | 注文可能 |
| 売り切れ | |
| オーダーストップ |
| 情報 | ステータス |
|---|---|
| 注文カートステータス | 空 |
| 未注文 |
| 情報 | ステータス |
|---|---|
| 料理注文ステータス | 注文済み |
| 提供済み | |
| 取消済み |
状態モデル図
論理 ERD／ユースケース対応表
（※お客様にモデル自体を確認してもらうというよりは、適宜こちらから懸念点を聞いていくスタイルで進める）
【目的】
構築対象のシステムで管理されるべきデータとその構造について、ビジネス上の妥当性を確認すること。
【主要な確認事項】
管理対象データに過不足はないか？
エンティティ同士の関係性は、業務上の関係性と一致するか？
各ユースケースを実現できるか？
【確認を怠った場合に懸念されるリスク】
システムの機能実現を妨げる要因の発見が遅れ、プロジェクトが遅延します。
ユースケース・データ対応マトリクス
| ログインアカウント | 営業時間 | カテゴリー | メニュー | テーブル | トークン発行 | 食事 | 料理注文 | |
|---|---|---|---|---|---|---|---|---|
| ログインする | R | - | - | - | - | - | - | - |
| ログアウトする | - | - | - | - | - | - | - | - |
| 営業時間を参照する | - | R | - | - | - | - | - | - |
| 営業時間を更新する | - | CUD | - | - | - | - | - | - |
| 最終注文時刻を参照する | - | R | - | - | - | - | - | - |
| 最終注文時刻を更新する | - | CUD | - | - | - | - | - | - |
| テーブルを登録する | - | - | - | - | C | - | - | - |
| テーブルを参照する | - | - | - | - | R | - | - | - |
| テーブルを更新する | - | - | - | - | U | - | - | - |
| テーブルを削除する | - | - | - | - | D | - | - | - |
| カテゴリーを登録する | - | - | C | - | - | - | - | - |
| カテゴリーを参照する | - | - | R | - | - | - | - | - |
| カテゴリーを更新する | - | - | U | - | - | - | - | - |
| カテゴリーを削除する | - | - | D | - | - | - | - | - |
| メニューを登録する | - | - | - | C | - | - | - | - |
| メニューを参照する | - | - | - | R | - | - | - | - |
| メニューを更新する | - | - | - | U | - | - | - | - |
| メニューを削除する | - | - | - | D | - | - | - | - |
| トークンを発行する | - | - | - | - | R | RUC | - | - |
| QR コードを印刷する | - | - | - | - | R | R | - | - |
| QR コードを再印刷する | - | - | - | - | R | R | - | - |
| メニュー一覧を見る | - | - | R | R | - | - | - | - |
| 料理を注文カートに追加する | - | R | R | R | - | - | - | - |
| 料理を注文カートから削除する | - | R | R | R | - | - | - | - |
| 料理注文を確定する | - | R | R | R | R | R | RUC | C |
| 料理の注文状況を見る | - | - | R | R | R | R | R | R |
| メニューを売り切れにする | - | - | - | U | - | - | - | - |
| 料理注文を取消する | - | - | - | R | R | R | R | U |
| 料理を提供済みにする | - | - | - | - | R | R | R | U |
| テーブルの注文履歴を見る | - | - | R | R | R | R | R | R |
| 食事の合計金額を見る | - | - | R | R | R | R | R | - |
| テーブルの食事を終了する | - | - | - | - | R | U | U | R |
主要な確認事項
メニューのバリエーション
- 店舗で現在実際に提供しているメニュー表を共有いただけるか？
- （単純にカテゴリー／メニューというデータ形式で表現しきれるのかどうかを懸念して）
- （ソースやご飯の種類を選択できるなどのバリエーションはあるか？）
- （セットメニュー／コースメニューはあるか？）
アカウント管理
- 店舗サイトへのアクセスは、店舗が個別に用意する端末からのみを想定しているか？もしくは店員のプライベート端末からもアクセスされる想定か？
- 店舗サイトは ID とパスワードによる認証を設ける想定だが問題ないか？
- パスワードを忘れた場合の救済については、運用上で賄う想定だが問題ないか？アプリケーション上に設ける必要があるか？
- マスター操作等は店長のみが実施できるような制約が必要か？それはなぜか？ その他アクセスするアカウントによって表示内容や操作権限を調整する必要があるか？
注文カート
-
料理をまとめて注文するために、一時的にストックしておくための場所を、モデル上ではひとまず「注文カート」としているが、店舗でよく利用する言葉が存在するのであれば置き換えたい。そういった言葉はあるか？
-
複数人が同時に各々のスマホ端末で、注文操作（注文カートへストック → 注文確定）を行うケースも想定する。
- このとき「注文カート」を共通データとしてサーバ側で管理し各端末へ共有する仕組みにすると、自端末の操作中に、他端末の操作でカート中の料理が注文されるケースも発生し得る。
- その結果、お客さんが気づかずに重複した注文を行ったり、その対応として店員が手動で取消を実施するなどの、オペレーションを発生させる恐れがある。
- そのため、以前の要望では「注文カート」は各端末で独立して保持する（端末を超えて共有しない）方式として問題ないか？
注文提供、注文取消
-
料理をお客さんへ提供する度に、店員（ホールスタッフ）がスマホ or タブレット端末からデータを更新（提供済みへとステータス更新）操作する想定だが、オペレーションとして問題ないか？
-
注文の取消は、店員（ホールスタッフ）がスマホ or タブレット端末からデータを更新（取消済みへとステータス更新）操作する想定だが、オペレーションとして問題ないか？
-
注文取消のタイミングとしては、「注文を受けて料理を作り始める前」から「注文を受けて料理を作りお客さんへのテーブルに提供後」のどのタイミングも有り得る想定であり、とくに制約を設けていないが問題ないか。
売り切れ対応
- 売り切れ設定については、店員（調理スタッフ or ホールスタッフ）が食材の残量を確認してメニューごとに個別でスマホやタブレット端末から操作する想定だが、オペレーションとして問題ないか？
- 売り切れ設定したメニューを、元に戻すケースはあるか？
その他機能要望
- 注文履歴から再注文する機能
- 店員呼び出し機能
- 税率設定機能
- 決済機能（クレカ）
- POS レジ連携機能
- 売上の日次、月次レポート等の表示、csv 出力機能
モデルのイマイチな点
- 用語「料理注文」や「トークン発行」が一般的な用語ではない
- 用語「注文履歴」が ERD にない
- テーブルの状態遷移周りが怪しい
- 食事終了してから、次のお客さんが着席して食事を注文するまでのフローを明確にする必要がある
整理したモデルとその他確認事項をもってお客様との打ち合わせに臨む。
※情報モデル／システムコンテキストに対応する、用語集（用語＋分類＋説明）や画面一覧表も併せて作成・共有しておく、画面の UI とかはもうちょいあとで作成する