酒店軟件需求分析說明書

1、文檔編號：文檔狀態(tài)：討論中XX酒店信息管理系統(tǒng)軟件需求分析說明書ver2.3PK軟件集團(tuán)有限公司2016-05-01目錄1 系統(tǒng)簡介31.1系統(tǒng)背景31.2 功能架構(gòu)31.3環(huán)境配置41.4 業(yè)務(wù)流程52 系統(tǒng)數(shù)據(jù)模型52.1 系統(tǒng)實體關(guān)系圖（ERD )62.2 系統(tǒng)數(shù)據(jù)流圖（DFD )72.2.1 頂層數(shù)據(jù)流圖72.2.2 層數(shù)據(jù)流圖82.3 數(shù)據(jù)定義102.3.1預(yù)訂表102.3.2顧客信息表112.3.3房卡綜合信息表112.3.4客房信息表113 面向?qū)ο蠼?53.1 Use Case 模型153.2 類圖173.3 序列圖183.3.1預(yù)訂183.3.2 接待 Gheck-in18

2、3.3.3 退房 Check-out194 驗收標(biāo)準(zhǔn)201 系統(tǒng)簡介1.1系統(tǒng)背景本酒店管理系統(tǒng)是根據(jù)位于澳門本島臨海的XX酒店的需求而開發(fā)的。該酒店是 一家四星級度假酒店，酒店占地XX平方米，高26層樓。1樓為接待大廳，2樓為酒 店商場，3樓、4樓為餐飲部，5褸是休閑娛樂場所，6樓為酒店的管理部門，726 樓為酒店客房。715層每層各設(shè)25間客房，1526層各為20間客房，房間號XXXX 第一位和第二位是樓層號，后兩位為所在褸層的房間序號。715層每層各有8間單 人房，10間雙人標(biāo)準(zhǔn)房，7間豪華雙人標(biāo)準(zhǔn)房。1526層每層各有4間豪華套房，8 間雙人標(biāo)準(zhǔn)房，8間豪華雙人標(biāo)準(zhǔn)房。由于傳統(tǒng)管理方式

3、成本高、效率低，難以處理大量工作。因此期望開發(fā)一套功能 完善、操作便捷的信息管理系統(tǒng)，實現(xiàn)對客房、餐飲、收銀等模塊的信息化管理，以 提高工作效率，規(guī)范管理，降低業(yè)務(wù)處理成本。1.2 功能架構(gòu)本酒店管理系統(tǒng)主要由前臺和后臺兩大部分組成。由預(yù)訂管理、接待管理、收銀 管理、租賃管理、娛樂管理、餐飲管理、倉儲管理、財務(wù)管理、人事管理、設(shè)施管理、 文檔管理等模塊組成，如圖SRS-1所示。一卡式消費是本系統(tǒng)的一大特色。顧客獲得一卡通服務(wù)后在酒店客房、餐飲、娛樂等消費時實現(xiàn)自動入賬、自動匯總，方便顧客結(jié)算。各管理模塊可極大地提高各個部門的工作效率，減輕工作負(fù)擔(dān)，幫助整理和分析數(shù)據(jù)，輔助相應(yīng)的經(jīng)營管理。1.3

4、環(huán)境配置根據(jù)軟件功能架構(gòu)的需求，系統(tǒng)的網(wǎng)絡(luò)配置如圖SRS-2所示。圖中，前后臺分別用一個虛線框框起，以表示邏輯上的區(qū)分。1.4 業(yè)務(wù)流程圖SRS-3是在上述硬件網(wǎng)絡(luò)環(huán)境和軟件功能架構(gòu)基礎(chǔ)上，本軟件系統(tǒng)需要實現(xiàn)的前臺業(yè)務(wù)流程（考慮到篇幅問題，后面實例中均忽略后臺系統(tǒng)。作為范本可以省略，實際項目的分析說明書不能省略！）。前臺的業(yè)務(wù)流程圖主要從顧客角度來表現(xiàn)要實現(xiàn)的業(yè)務(wù)流程，同時也加入了與此有關(guān)的酒店工作人員與軟件系統(tǒng)的業(yè)務(wù)關(guān)系。2 系統(tǒng)數(shù)據(jù)模型數(shù)據(jù)模型主要以ERD、DFD、數(shù)據(jù)詞典三方面明確系統(tǒng)需求。2.1 系統(tǒng)實體關(guān)系圖（ERD )圖SRS-4的ER圖是根據(jù)前臺業(yè)務(wù)需求考慮的，其中主要考慮的是實

5、體間的關(guān)聯(lián)關(guān)系，關(guān)于父子類的關(guān)系將在類圖中描述。這里沒有涉及后臺各個實體和它們之間的關(guān)系。2.2 系統(tǒng)數(shù)據(jù)流圖（DFD )2.2.1 頂層數(shù)據(jù)流圖頂層圖大致描述了預(yù)訂、接待、客房、房卡、收銀、租賃、娛樂、餐飲之間的數(shù) 據(jù)關(guān)系，詳見圖SRS-5。某些數(shù)據(jù)關(guān)系的細(xì)化，如顧客表、客房表，將在后續(xù)層次圖中描述。關(guān)于各個數(shù)據(jù)表的詳細(xì)定義，請參看數(shù)據(jù)詞典相關(guān)內(nèi)容。2.2.2 層數(shù)據(jù)流圖一層是頂層的細(xì)化。圖SRS-6主要是關(guān)于處理2接待處理的分解，說明接待處理中對于已經(jīng)預(yù)訂的顧客，需要查找預(yù)訂信息，再由接待check-in過程處理；如果沒有預(yù)訂，則直接由check-in過程處理。圖中也說明了接待處理與處理3

6、 “房卡處理”， 以及預(yù)訂表、顧客表、客房表之間的數(shù)據(jù)關(guān)系。SRS-7則是處理4“客房處理”的細(xì)化，將“客房處理”分解為41 “入住處理”、 42 “客房服務(wù)處理”、43 “退房處理”、44 “賠償處理”四個子部分；相應(yīng)數(shù)據(jù)庫 表4 “客房表”也分解為子表41 “客房狀態(tài)表”、42 “客房服務(wù)消費表”、43 “客 房總消費表”、44“客房設(shè)備表”。并標(biāo)明了客房處理與預(yù)訂處理、房卡處理之間的關(guān)系。限于篇幅，其他細(xì)化DFD圖省略。（作為范本可以省略，實際項目的分析說明書不能省略?。?.3 數(shù)據(jù)定義 2.3.1預(yù)訂表2.3.2顧客信息表2.3.3房卡綜合信息表房卡一卡通消費是本系統(tǒng)的基本要求。房卡只

7、需與顧客信息表的關(guān)聯(lián)綁定，顧客的其他信息就能從顧客表獲得。例如想知道顧客的消費情況，只需將房卡號碼與餐飲消費信息表關(guān)聯(lián)，就可以檢索出對應(yīng)的消費記錄。2.3.4客房信息表如前面在DFD圖 中 所 述，“客房信息表”實際上是由如下一些子表所組成的。 2.3.4.1房間狀態(tài)信息表2.3.4.2客房服務(wù)信息表2.3.4.3房間設(shè)備信息表2.3.4.4客房總消費表2.3.5娛樂休閑康體消費表2.3.6餐飲消費表2.3.7設(shè)備租賃信息表和客房信息表類似，此表由下列子表組成。2.3.7.1設(shè)備租賃情況表2.3.7.2設(shè)備租賃消費表限于篇幅，略去員工表等數(shù)據(jù)表（實際項目不能省略?。?。 3 面向?qū)ο蠼?.1

8、Use Case 模型Use Case圖描述了系統(tǒng)中的參與者和用例，以及它們之間相互使用的關(guān)系。圖SRS-8的Use Case圖表達(dá)了顧客、接待員、收銀員與軟件的預(yù)訂、接待、各種消費處理之間的關(guān)系。顧客除了可以直接預(yù)訂外，其他都需要通過接待員、收銀員等與軟件交互。3.2 類圖SRS-9所示的類圖（Class Diagram)根據(jù)面向?qū)ο蟮姆椒▽ο到y(tǒng)中的一些對象進(jìn)行了提煉，將接待員、收銀員、管理員作為員工類的子類；將各個消費對象中的共性提煉為消費父類，例如，都有房卡、消費項目、消費總額等屬性及其操作。從而充分利用父子繼承實現(xiàn)軟件的復(fù)用。3.3 序列圖下面以時序圖分別描述預(yù)訂、接待Check-in

9、、退房Check-out過程中各個對象的動態(tài)交 互行為。注意對各個對象的操作一定要在這個對象的操作生命線上，以保持對象的封裝性。 若要求其他對象的操作，則一定要通過對象交互實現(xiàn)，而不能“越俎代庖”，自行操作。3.3.1預(yù)訂預(yù)訂中接待員通過主窗口打開預(yù)訂窗口，通過顧客對象創(chuàng)建顧客信息，再啟動客 房查找過程查找合適客房,之后建立預(yù)訂記錄,更改房態(tài)為已預(yù)訂狀態(tài)。詳見圖SRS-10。 這里沒有考慮預(yù)訂的確認(rèn)問題，如果需要，房態(tài)和預(yù)訂單需增加“預(yù)訂確認(rèn)”狀態(tài)， 并增加相應(yīng)的確認(rèn)處理。3.3.2 接待 Gheck-in接待入住中，首先查詢是否己經(jīng)預(yù)訂，若未預(yù)訂則創(chuàng)建客戶信息，然后創(chuàng)建接待 記錄，查找確認(rèn)客

10、房。確認(rèn)后修改房態(tài)為“已入住”。最后須生成房卡，將客房等信息 寫入房卡中，與房卡綁定。詳見圖SRS-11。3.3.3 退房 Check-out參見圖SRS-12，退房中收銀員啟動收銀窗口，通過房卡查詢出對應(yīng)的消費記錄和客房入住記錄，將消費信息匯總返回，請顧客確認(rèn)；顧客確認(rèn)無誤后，向收銀員支付款項，之后收銀員按下收銀支付完成確認(rèn)按鈕，軟件自動修改房態(tài)，更新保存消費記錄和接待記錄，最后解除房卡與客房、客人的綁定。另外，顧客的消費信息，以及房卡、接待記錄等信息也將直接反饋到管理員（值班經(jīng)理）的電腦上，以便及時監(jiān)察。4 驗收標(biāo)準(zhǔn)本系統(tǒng)驗收、維護(hù)主要按照計劃書與合同中所規(guī)定的內(nèi)容執(zhí)行。這里根據(jù)需求分析中

11、的考慮強(qiáng)調(diào)、補(bǔ)充以下幾點：1.除由本項目測試人員測試通過外，還需由本公司測試人員配合酒店方人員及第三方人員共同進(jìn)行測試，三方共同認(rèn)可后才可簽字驗收。2.系統(tǒng)需按照本需求規(guī)范說明書所要求的目標(biāo)進(jìn)行設(shè)計、驗收，建立滿足酒店運營管理要求的軟硬件環(huán)境。3.系統(tǒng)易于安裝使用，界面設(shè)置合理清晰，直觀易懂，表達(dá)準(zhǔn)確。酒店員工只需經(jīng)過簡單培訓(xùn)后即可掌握使用。4.系統(tǒng)有較強(qiáng)的安全性，身份驗證功能可靠，避免未授權(quán)用戶通過非正常渠道獲取及篡改系統(tǒng)信息。5.系統(tǒng)具有一定的穩(wěn)定性，驗收試用階段為3個月，其間故障率平均為每48 小時小于等于4次，方可驗收支付余款。否則繼續(xù)延長3個月試用階段，直到合 格。6.驗收后第一年故障率平均每48小時內(nèi)小于等于3次，第二年故障率平均每48 小時內(nèi)小于等于2次。故障的發(fā)生與修復(fù)中不得丟失數(shù)據(jù)和影響酒店正常運營。7.在項目驗收后兩年內(nèi)開發(fā)方提供免費維護(hù)；兩年后提供有償維護(hù)。8.系統(tǒng)的及時響應(yīng)流暢，每一操作請求平均響應(yīng)時間應(yīng)在5秒內(nèi)。9.系統(tǒng)容量上保證可容納500臺終端同時連接服務(wù)器操作。上述SRS實例已經(jīng)過多次修改，看似不錯，但如果你能“前后一貫，左顧右盼”