https://qiita.com/s3imamura/items/e169b7507d59053117e5
の続き
お客様との MTG
RDRA のモデルを説明しながら、お客様から業務のお話を聞いたことにする。
ネット上にあるメニュー表を探していたところ、「びっくりドンキー」のメニューがちょうど良さそうだったので拝借した。
◆ メニュー
・メニューは以下 URL
└ <https://www.bikkuri-donkey.com/menu/>
・時間帯によって提供するメニューが変わる（モーニング／ランチ）
・店舗によらず基本的には同じだが、一部の店舗で提供していないメニューもある
◆ 料金
・22 時以降は深夜料金で 10% 割増となる
◆ 店舗、ユーザー情報
・店舗は複数件あり、それぞれ価格設定が異なる。
・店舗には店長がいるがメニューを作っているわけではない。ただ、メニューの更新などは店舗にいる社員が行いたい。
・店長含め社員は社用のメールアドレス持っているけど、店員はアルバイトも多く、メールアドレス発行されていない。
・パスワード救済はメール通知で行う。
・店員のプライベート端末であっても、制約を設けたうえでアクセス・操作できるようにしてほしい。
└ アルバイトによる不正利用防止のため。
・店員はホールスタッフと調理スタッフで、とくに区別しているわけではない。
◆ 注文カート
・「注文カート」という用語は使っていないけど、他に該当する用語もないから、そのままでよいとのこと。
・客の端末を超えて注文カートは共有しないで OK。
◆ 店員オペレーション
・注文提供や、注文取消、売り切れ対応は店員のオペレーションで OK とのこと。
◆ 他機能
・売り切れからもとに戻す機能は必要。
・座席の統合はいらない。
・他の機能も付けたいけど、まずは動くものを作ってほしい。
店舗が複数あるのかぁ。
メニューも見てみないと何も言えないな。
割増料金もあるし、データ構造変わるなぁ。。。
ひとまず、メニュー確認してみる。
メニューの確認
Web サイトにメニューが載っているので確認してみると、バリエーションが色々ありそう。
・ハンバーグの量を選択できる（150g or 300g）
・トッピングも追加できる（エッグ、チーズ、パイン、おろしそ）
・ライスの量を選択できる（大盛 or 普通 or 小盛）
・ライスの種類を変更できる（ライス or カリフラワーライス）
・サラダを追加できる（なし or 追加）※サラダ単品の販売もあり
・ランチは 11 ～ 17 時の間に注文可能
・モーニングは開店～ 11 時の間に注文可能
・他メニューは常時注文可能（モーニングの時間帯でも注文可能）
・ドリンクもサイズを選択できる（小 or 中 or 大）
・期間限定メニューもある
メニューはライス変更（択一選択）や追加トッピング等（複数選択可）が適用できるデータ形式にしてみる。
ランチタイム、モーニングタイムは同じらしい
社員アカウント
メールアドレスとパスワードで認証するような形式ができそう。
パスワードリセット機能もメールアドレスに送信する形で実現する。
管理社員用のアカウントと一般社員用のアカウントの区別をつける。
メニューと店舗の関連
各店舗のバリエーションは料金と提供有無とのこと。
店舗配下にメニューを登録するというよりは、メニューの中から店舗で提供するものを選択して提供料金を編集できるような形式にしてみる。
モデルの更新
まずは、変更エネルギーコストの低そうなシステムコンテキスト図あたりから更新してく。
変更後のモデル（システムコンテキスト）
店長ではなく、社員とアルバイトという分類にした。
そして社員はさらに、一般社員と管理社員という区分にした。
これに伴いユースケースや他モデル内の用語もすべて置換していく。
参考）前のモデル（システムコンテキスト）
次に新しい用語がいくつか出てきたので、情報モデルも更新する。
変更後のモデル（情報モデル／用語集）
情報モデルも用語が増えてきたので、分類した。
だんだんそれっぽくなってきた。
参考）前のモデル（情報モデル／用語集）
大きいところから進めるということで、ビジネスコンテキスト図を更新する。
このあたりから、ユースケースやデータモデルを更新しつつ何度も更新し直す。
変更後のモデル（ビジネスコンテキスト）
システムコンテキストに合わせてアクターの名称を更新。
業務を大きく全体管理業務、店舗管理業務、店舗運用業務、客業務に分類した。
それぞれの業務フローとそこに現れるユースケースを確認していく。
参考）元のモデル（ビジネスコンテキスト図）
ここからは、ビジネスコンテキスト図で表した業務のフローを細かく確認していく。
システムに関わる業務を新たに発見したら、ビジネスコンテキスト図側に反映してく。
業務フローユースケース関連
社員アカウント管理
店舗管理
メニュー管理
ユースケース一覧
期間終了したメニューとかは、データとしては削除しないけど、表示したくないケースが多いのかな。
状態モデル
今度は状態モデルを更新する。
閉店、開店によって状態が変わるケースも想定される。
データモデル
各ユースケースを満たすように調整していく
変更後のモデル
テーブルが増えた。
トークン発行あたりの流れはスッキリした気がするけど、名前がまだしっくりこない。
メニューオプションもこれで実現できるかどうかちょっと不安。
料金周りはどこに情報を持つのがよいのかイマイチわからない。
参考）元のモデル（ERD）
この後の流れは、
・業務フローを網羅する
・各ユースケースごとにデータモデル＋状態遷移上の整合性をチェックし、不整合が発生する場合は練り直す。
・業務フロー上から例外フローを洗い出す。
・例外フローに対応できるデータモデル＋状態遷移となるように練り直す。
・要求を満たすための画面と画面遷移を考える。
・画面とユースケース、データ同士の不整合がないかチェックする
・異常系のユースケース時の画面遷移を練り直す。
以上で機能に関する要件の整理はひとまず完了の予定。
良かった点
・plantuml でも意外と色々表現できることがわかった。（とくに業務フロー）
・最初のモデルが全然ダメでも、プロセスを経て徐々に整合性が出てくる感じがわかった。
反省点
・全体として UX やユーザー価値などの検討が不足しており、実際の要件定義ではもっと手前の段階でシステム価値を考えなくちゃいけないと思う。
・用語集の作成（英名、説明の記述）は面倒くさかったので端折った。
・今回はひとりでモデルの作成を行ったが、本来はお客様やチームメンバー含めて時間を割いて一緒に実施すべきだった。
・ひとりでもそこそこ時間はかかった（今回の範囲までだと 4 人日くらい ※慣れてないと 10 人日くらいかかりそう）
注意点
・非機能要件の検討やインフラ構成については別途実施する必要あり。
・実際にプロジェクトの開発対象とするスコープはお客様と一緒に決める。
・plantuml はたしかに便利だが、整合性のチェックなどは人間が手動で行う必要があるので、規模が大きいシステムでは専用ツールを使うのもよいと思う。