2.1業務建模
業務建模(Business Modeling)對領域內企業管理和業務對象進行建模。包括業務流程建模和領域建模。業務流程建模描述系統內各單位、人員之間業務關係、做業順序和管理信息流向。領域建模是從現實的問題域中找到最有表明性的概念對象，抽象成分析類。java
A. 業務流程建模。安全
u 使用UML活動圖分析目標系統所支持的業務流程。網絡
UC1銷售開單用例併發
UC2收銀用例性能
u 使用文字對流程中每一個活動的涉衆、業務規則、使用到的單據進行必要的說明。ui
涉衆：顧客、收銀員、酒店經理spa
業務規則：設計
ID日誌 |
規則對象 |
可變性 |
來源 |
規則1 |
顧客折扣規則。如： 酒店經理：10%折扣額 |
高，沒每間酒店都有不一樣規則 |
酒店政策 |
使用到的單據：
收款票據，內容包括：酒店名稱，開單時間，臺號，經理工號，消費詳細，商品單價，商品數量，應收金額，實收金額，找零金額等
B. 領域建模。
u 使用UML類圖構建領域模型。
2.2需求規格說明
需求規格說明書(Software Requirements Specification)描述了系統的功能需求。構建系統用例模型描述功能需求。
A. 系統用例圖。繪製整個系統的UML用例圖。
B. 用例詳述文本。
對全部業務活動用例採用詳述風格（包括前置條件、後置條件、主事件流，擴展、業務規則等）進行描述。
範圍：POS應用
主要參與者：經理，收銀員
前置條件：收銀員和經理必須通過確認和認證
成功保證（後置條件）：存儲消費信息。準確計算稅金，準確計算消費總額，生成票據。
主成功場景：
1．經理給用戶開臺
2．顧客物色好菜式後，經理給顧客點菜
3．經理把顧客所點的菜式輸入POS系統
4．顧客用餐
5．顧客用餐完畢要求結帳
6．收銀員進行結帳，系統顯示總額和所計算的稅金，並打印出小票
7．經理憑票據向顧客收款
8．顧客付款
擴展：
*a.系統在任意時刻失敗：
1. 收銀員或經理重啓系統，登陸，請求恢復上次狀態。
2. 系統重建上次狀態
1a.顧客因人數或者喜愛須要換桌
經理進入系統，修改這次消費訂單對應的臺號
4a.顧客用餐過程須要加菜
經理給顧客進行加單，而且輸入系統對應的消費訂單
4b.顧客用餐過程因等待過久或者因菜式有問題須要進行退單
經理確認狀況給顧客進行退單，而且更新系統對應的消費訂單
7a.顧客覈對本身的消費詳細記錄，發現有有誤及時提出
1.經理覈對具體狀況，確認無誤後進入系統更新訂單
2.繼續第6步
2.3 補充性規格說明
補充性規格說明補貨並肯定其餘類型的需求，如可靠性（如10000人併發訪問）、可用性（如1米外輕鬆看到文本）、接口（如支持錢箱、支持網銀支付接口）等。也能夠包括其餘跨越多個用例的功能性需求如報表、安全性、日誌和錯誤處理、數據備份、數據導入導出等。
簡要描述本項目最終系統數據查詢與報表，系統權限管理的功能需求。也能夠描述項目組計劃實現的其餘需求。
功能性
1、日誌和錯誤處理
在持久性存儲中記錄全部錯誤。
2、可插拔規則
在幾個用例的不一樣場景點執行任意一組規則，以支持對系統功能的定製。
3、安全性
任何使用都須要通過用戶認證。
可用性
1、避免使用通常色盲人羣難以辨認的顏色。
2、快捷、準確的結帳處理及其重要，由於顧客但願快速結束結帳過程，不然會給他們的購買體驗帶來負面影響。
可靠性
1. 性能
須要體現出系統的穩定性以及反應速度。
2、數據備份
系統支持定時或實時的對數據進行備份，避免數據的破壞或者丟失，如處理消費交易過程當中，系統出現閃退或者奔潰狀況下致使的數據丟失或者須要從新錄入。
可支持性
1、可適應性
不一樣客戶在處理銷售時有其特有的業務規則和處理需求。所以，在場景中的幾個預約之處（如開始新的銷售交易時，增長新的商品時），須要可以啓用可插拔的業務規則。
2、可配置性
系統具有必定的可配置能力以適應該店對其POS系統的不一樣的網絡配置需求。
實現約束
使用的程序設計語言爲java，其具有易於開發，可以提升遠期的移植和可支持性能力。
購買構件
稅金計算器，必須支持用於不一樣國家的可插拔計算器。
免費開源構件
建議使用免費的Java技術開源構件。
接口
重要硬件和接口
顯示屏（顯示POS系統）。
票據打印機
信用卡、借記卡讀卡器