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