<aside> 💡 專案指標
與公司＆需求方（業務部門）確認 MRD：希望透過此產品與支付產品的結合，拓展更多內用以及小型連鎖店家，經評估過後將產品 Roadmap 切分成兩個階段， MVP 先以取代原系統＆轉換「既有客戶（街邊店或單店類型）」為目標，後續再增加內用與小型連鎖店家所需功能（日結）。
接著便利用「Use Case」與工程師確定功能範圍，產出「User Story」確認實作可行性，並確保每位專案成員對於功能細節的想像與方向一致，最後撰寫「規格功能表」提供給其他部門，作為上線交付時盤點依據與教學資源之一。
<aside> 👩🏻💻 Use Case
產品已實際落地
以內用與小型連鎖為目標，增加交班與日結功能
</aside>
<aside> 👩🏻💻 User Story
以下內容皆為摘錄
| As A | I Want | So That |
|---|---|---|
| 店員 | 結帳時有計算找零的功能 | 收到客人大鈔時快速算出要找多少錢 |
| 店員 | 系統協助判斷統編或載具是否有輸入錯誤，並在錯誤時阻擋結帳 | 避免發票經常開立錯誤 |
| 店員 | 當訂單金額被調整後，發票也會根據新的金額重新開立 | 避免忘記開立正確金額發票 |
| 店員 | 可以輸入臨時收入或支出的金額與原因的功能 | 正確計算該班次的錢箱金額 |
| 店長 | 系統可以自動計算應收與實收是否產生短溢 | 避免人工出錯或蓄意報錯金額、保持帳務正確 |
| 店長 | 可以有訂單的來源與支付方式的總結報表 | 每天對帳的時候，不用開好幾個平台計算金額 |
| 店長 | 後台可以設定每個登入帳號與該帳號擁有哪些功能 | 落實權限管控，避免新進人員操作錯誤或員工蓄意報復亂用 |
| </aside> |
<aside> 👩🏻💻 功能規格表
以下內容皆為摘錄
</aside>
每個階段性功能開發完成，會先於部門展開功能測試與回歸測試。系統全部開發完成，即準備產品落地，製作教育訓練文件，並召開跨部門GTM會議，介紹產品痛點與如何使用。
<aside> 👩🏻💻 GTM會議與系統教學
</aside>