2.1業務模組化
A. 業務流程模組化。
B. 領域模組化。
2.2需求規格說明
A. 系統用例圖。
B. 用例詳述文本。
UC3：退貨
範圍：便利店POS應用
級别：使用者目标
主要參與者：收銀員、顧客
涉衆及其關注點：
④ 收銀員：希望能夠準确、快速地收取顧客應付金額。
⑤ 顧客：希望以最小代價完成付款活動并得到快速服務。希望便捷、清晰地看到所輸入的商品項目和價格。希望有購買憑證，以作為購買清單和作為退貨的憑據。
⑥ 公司：希望準确地記錄交易，滿足顧客要求。希望能夠自動、快速地更新賬務和庫存資訊。希望系統足夠健壯和容錯性，當系統出現一些小問題時，也可以完成收銀。
④經理：希望能夠快速執行超控操作，并易于更正收銀員的不當操作。
前置條件：收銀員必須經過确認和認證。
成功保證（或後置條件）：存儲銷售資訊。準确計算稅金。更新賬務和庫存資訊。記錄提成。生成票據。記錄支付授權的準許。
主成功場景：
1、顧客攜帶所購商品或服務到收銀台通過POS機付款。
2、收銀員開始一次新的開單記錄。
3、收銀員輸入商品條碼。
4、系統逐條記錄出售的商品，并顯示該商品的描述、價格和累計額。價格通過一組價格規則來計算。
收銀員重複3~4步，知道輸入結束。
5、系統顯示總額和所計算的稅金。
6、收銀員告知顧客總額，并請顧客付款。
7、顧客付款，系統處理支付。
8、系統記錄完整的銷售資訊，并将銷售和支付資訊發送到外部的賬務系統（進行賬務處理和提成）和庫存系統（更新庫存）。
9、系統列印票據。
10、顧客攜帶商品和票據離開（如果有）。
擴充：
*a、經理在任意時刻要求進行超控操作：
1、系統進入經理授權模式、
2、經理或收銀員執行某一經理模式的操作。
3、系統回複到收銀員授權模式。
*b、系統在任意時刻失敗：
為了支援恢複和更正賬務處理，要保證所有交易的敏感狀态和事件都能夠從場景的任何一步中完全恢複。
1、收銀員重新開機系統，登入，請求恢複上次狀态。
2、系統重建上次狀态。
2a、系統在恢複過程中檢測到異常：
1、系統向收銀員提示錯誤，記錄次錯誤，并進入一個初始狀态。
2、收銀員開始一次新的銷售交易。
1a、客戶或經理需要恢複一個中斷的銷售交易。
1、收銀員執行恢複操作，并且輸入ID以提取相應的銷售交易。
2、系統顯示被恢複的銷售交易狀态及其小計。
2a、未發現對應的銷售交易。
1、系統向收銀員提示錯誤。
2、收銀員可能會開始一個新銷售交易，并重新輸入是以商品。
3、收銀員繼續該次銷售交易（可能要輸入更多的商品或處理支付）。
2-4a、顧客告訴收銀員其免稅狀況（例如年長者、本國人等）。
1、收銀員進行核實，并輸入免稅狀況編碼。
2、系統記錄該狀況編碼（在計算稅金時使用）。
3a、無效商品ID（在系統中未發現）：
1、系統提示錯誤并拒絕輸入該ID。
2、收銀員響應該錯誤。
2a、商品ID可讀（例如，數字型的UPC）：
1、收銀員手動輸入商品ID。
2、系統顯示商品項目的描述和價格。
2a、無效商品ID：系統提示錯誤。收銀員嘗試其他方式。
2b、系統内不存在該商品ID，但是該商品附有價簽：
1、收銀員請求經理執行超控操作。
2、經理執行相應的超控操作。
3、收銀員選擇手工輸入價格，輸入價簽上的價格，并請求對該價目進行标準計稅。（因為沒有産品資訊，計稅引擎無法确定如何計稅。）
2c、收銀員通過執行尋找産品幫助以擷取正确的商品ID及其價格。
2d、另外，收銀員可以向其他員工詢問商品ID或價格，然後手工輸入ID或價格（參見以上内容）。
3b、當有多個商品項目屬于同一類别的時候（如5瓶可樂），不必記錄每個商品項目的唯一辨別：
1、收銀員可以輸入類别的辨別和商品的數量。
3c、需要手工輸入類别和價格（例如，花卉或紙牌及其價格）：
1、收銀員手工輸入特定的類别代碼及其價格。
3-6a、顧客要求收銀員從所購商品中去掉一項：
所去除商品的價格必須小于收銀員權限，否則需要經理執行超控操作。
1、收銀員輸入商品ID并将其删除。
2、系統删除該項目并顯示更新後的累計額。
2a、商品價格超過了收銀員權限：
1、系統提示錯誤，并建議經理超控。
2、收銀員請求經理超控，完成超控後，重做該操作。
3-6b、顧客要求收銀員取消銷售交易：
1、收銀員在系統中取消銷售交易。
3-6c、收銀員延遲銷售交易：
1、系統記錄銷售交易資訊，使其能夠在任何POS登入中恢複操作。
2、系統顯示用來恢複銷售交易的“延遲票據”，其中包含商品項目和銷售交易ID。
5a、系統檢測到與外部稅務計算系統服務的通信故障：
1、系統在POS機節點上重新開機次服務，并繼續操作。
1a、系統檢測到該服務無法重新開機。
1、系統提示錯誤。
2、收銀員手工計算和輸入稅金，或者取消該銷售交易。
5b、顧客聲稱他們符合打折條件（例如，是雇員或重要顧客）：
1、收銀員提出打折請求。
2、收銀員輸入顧客ID。
3、系統按照打折規則顯示折扣總計。
5c、顧客要求兌現賬戶積分，用于此次銷售交易：
1、收銀員送出積分請求。
2、收銀員輸入顧客ID。
3、系統應用積分直到價格為0，同時扣除結餘積分。
6a、顧客要求現金付款，但所攜帶現金不足：
1、顧客要求使用其他支付方式。
1a、顧客要求取消此次銷售交易，收銀員在系統上取消該銷售交易。
7a、現金支付：
1、收銀員輸入收取的現金額。
2、系統顯示找零金額，并彈出現金抽屜。
3、收銀員放入收取的現金，并給顧客找零。
4、系統記錄改現金支付。
7b、信用卡支付：
1、顧客輸入信用卡賬戶資訊。
2、系統顯示其支付資訊以備驗證。
3、收銀員确認。
3a、收銀員取消付款步驟。
1、系統回複到“商品輸入”模式。
4、系統向外部支付授權服務系統發送支付授權請求，并請求準許該支付。
4a、系統檢測到與外部系統協作時的故障：
1、系統向收銀員提示錯誤。
2、收銀員請求顧客更換支付方式。
5、系統受到準許支付的應答并提示收銀員，同時彈出現金抽屜（以便放入簽名後的信用卡支付票據）。
5a、系統受到拒絕支付的應答：
1、系統向收銀員提示支付被拒絕。
2、收銀員請求顧客更換支付方式。
5b、應答逾時。
1、系統提示收銀員應答逾時。
2、收銀員重試，或者請求顧客更換支付方式。
6、系統記錄信用卡支付資訊，其中包括支付準許。
7、系統顯示信用卡支付的簽名輸入機制。
8、收銀員請求顧客簽署信用卡支付。顧客輸入簽名。
9、如果在紙質票據上簽名，則收銀員将改票據放入現金抽屜并關閉抽屜。
7c、收銀員取消支付步驟：
1、系統回到“商品輸入”模式。
7d、顧客出示優惠券：
1、在處理支付之前，收銀員記錄每張優惠券，系統扣除相應金額。系統記錄已使用的優惠券以備賬務處理之用。
1a、輸入的優惠券不适用于所購商品：
1、系統向收銀員提示錯誤。
9a、存在産品回扣：
1、系統對每個具有回扣的商品給出回扣表單和票據。
9b、顧客索要贈品票據（不顯示價格）：
1、收銀員請求贈品票據，系統給出贈品票據。
9c、列印票據。
1、如果系統能夠檢測到錯誤，給出提示。
2、收銀員更換紙張。
3、收銀員請求列印其他票據。
特殊需求：
•使用大尺寸平面顯示器觸摸屏UI。文本資訊可見距離為1米。
•90%的信用卡授權響應時間小于30秒。
•由于某些原因，我們希望在通路遠端服務失敗的情況下具有比較強的恢複能力。
•支援文本顯示的語言國際化。
•在步驟3和步驟7中能夠加入可插拔的業務規則。
技術與資料變元表：
*a.經理超控需要在鍵盤上輸入授權碼。
3a.商品ID可以用條碼掃描槍或鍵盤輸入。
3b.商品ID可以使用UPC、EAN、JAN或SKU等任何一種編碼方式。
7a.信用卡賬戶資訊可以用讀卡器或鍵盤輸入。
7b.記錄在紙質票據上的信用卡支付簽名。
發生頻率：可能會不斷地發生。
未解決問題：
•稅法如何變化？
•研究遠端服務的恢複問題。
•針對不同的業務需求怎樣進行定制？
•收銀員是否必須在從系統登出後帶走他們的現金抽屜？
•顧客是否可以直接使用讀卡器，還是必須由收銀員完成？
2.3 補充性規格說明
UC4:
1、功能性
①日志和錯誤處理
在持久性存儲中記錄所有錯誤。
②可插撥規則
在幾個用例的不同場景點執行任意一組規則，以支援對系統功能的定制。
③安全性
任何使用都需要經過使用者認證。
④國際化
支援文本顯示的語言國際化，以便于處理與外國顧客的交易。
2、可用性
①銷售經理能盡快找到退貨商品。
②快捷、無錯的退貨處理極為重要，因為購買者希望快速離開，否則會給他們的購買體驗（和對經理的評價）帶來負面影響。
3、可靠性
①可恢複性
如果在使用外部服務時出現錯誤，為了完成退貨處理，需要嘗試采用本地方案加以解決。
4.健壯性
系統對于規範要求以外的輸入情況的處理能力強。當使用者對系統的操作不規範時，系統能夠識别這些操作，并且能有效合理的處理。
5、接口
①重要硬體和接口
（1）觸摸屏（作業系統将此視為普通螢幕，且觸摸動作也視為滑鼠事件）。
（2）票據列印機。
（3）信用卡讀卡器
（4）簽名讀取裝置
②軟體接口
由于存在衆多外部協作系統（稅金電腦等），我們需要采用不同的接口，接入不停的系統。
6、所關注領域内的資訊
當退貨完成後，退貨商品金額可以根據客戶要求退還現金或經過第三方退款。
4.3 相關的資料庫
CREATE TABLE `salereturn` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`createDateTime` datetime NOT NULL,
`reason` varchar(36) DEFAULT NULL,
`saleReturnNo` varchar(36) NOT NULL,
`total` int(11) NOT NULL DEFAULT '0',
`saleorder_id` int(11) DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `FK_gds3450u1f5d52y0p5756alu` (`saleorder_id`),
CONSTRAINT `FK_gds3450u1f5d52y0p5756alu` FOREIGN KEY (`saleorder_id`) REFERENCES `saleorder` (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8; CREATE TABLE `salereturnitem` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`saleOrderItem_id` int(11) DEFAULT NULL,
`salereturn` int(11) NOT NULL,
PRIMARY KEY (`ID`),
KEY `FK_143oq14xx974usdtdmjej8daj` (`saleOrderItem_id`),
KEY `FK_liebtms8kyrnkoekonwtfsv5x` (`salereturn`),
CONSTRAINT `FK_143oq14xx974usdtdmjej8daj` FOREIGN KEY (`saleOrderItem_id`) REFERENCES `saleorderitem` (`ID`),
CONSTRAINT `FK_liebtms8kyrnkoekonwtfsv5x` FOREIGN KEY (`salereturn`) REFERENCES `salereturn` (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8; 轉載于:https://my.oschina.net/changda/blog/415574