XX酒店软件需求分析说明书.docx

文档编号：文档状态：讨论中XX酒店信息管理系统软件需求分析说明书ver2.3PK软件集团有限公司2016-05-01目录1 系统简介31.1系统背景31.2 功能架构31.3环境配置41.4 业务流程52 系统数据模型52.1 系统实体关系图（ERD )62.2 系统数据流图（DFD )72.2.1 顶层数据流图72.2.2 层数据流图82.3 数据定义102.3.1预订表102.3.2顾客信息表112.3.3房卡综合信息表112.3.4客房信息表113 面向对象建模153.1 Use Case 模型153.2 类图173.3 序列图183.3.1预订183.3.2 接待 Gheck-in183.3.3 退房 Check-out194 验收标准201 系统简介1.1系统背景本酒店管理系统是根据位于澳门本岛临海的XX酒店的需求而开发的。该酒店是 一家四星级度假酒店，酒店占地XX平方米，高26层楼。1楼为接待大厅，2楼为酒 店商场，3楼、4楼为餐饮部，5褛是休闲娱乐场所，6楼为酒店的管理部门，726 楼为酒店客房。715层每层各设25间客房，1526层各为20间客房，房间号XXXX 第一位和第二位是楼层号，后两位为所在褛层的房间序号。715层每层各有8间单 人房，10间双人标准房，7间豪华双人标准房。1526层每层各有4间豪华套房，8 间双人标准房，8间豪华双人标准房。由于传统管理方式成本高、效率低，难以处理大量工作。因此期望开发一套功能 完善、操作便捷的信息管理系统，实现对客房、餐饮、收银等模块的信息化管理，以 提高工作效率，规范管理，降低业务处理成本。1.2 功能架构本酒店管理系统主要由前台和后台两大部分组成。由预订管理、接待管理、收银 管理、租赁管理、娱乐管理、餐饮管理、仓储管理、财务管理、人事管理、设施管理、 文档管理等模块组成，如图SRS-1所示。一卡式消费是本系统的一大特色。顾客获得一卡通服务后在酒店客房、餐饮、娱乐等消费时实现自动入账、自动汇总，方便顾客结算。各管理模块可极大地提高各个部门的工作效率，减轻工作负担，帮助整理和分析数据，辅助相应的经营管理。1.3环境配置根据软件功能架构的需求，系统的网络配置如图SRS-2所示。图中，前后台分别用一个虚线框框起，以表示逻辑上的区分。1.4 业务流程图SRS-3是在上述硬件网络环境和软件功能架构基础上，本软件系统需要实现的前台业务流程（考虑到篇幅问题，后面实例中均忽略后台系统。作为范本可以省略，实际项目的分析说明书不能省略！）。前台的业务流程图主要从顾客角度来表现要实现的业务流程，同时也加入了与此有关的酒店工作人员与软件系统的业务关系。2 系统数据模型数据模型主要以ERD、DFD、数据词典三方面明确系统需求。2.1 系统实体关系图（ERD )图SRS-4的ER图是根据前台业务需求考虑的，其中主要考虑的是实体间的关联关系，关于父子类的关系将在类图中描述。这里没有涉及后台各个实体和它们之间的关系。2.2 系统数据流图（DFD )2.2.1 顶层数据流图顶层图大致描述了预订、接待、客房、房卡、收银、租赁、娱乐、餐饮之间的数 据关系，详见图SRS-5。某些数据关系的细化，如顾客表、客房表，将在后续层次图中描述。关于各个数据表的详细定义，请参看数据词典相关内容。2.2.2 层数据流图一层是顶层的细化。图SRS-6主要是关于处理2接待处理的分解，说明接待处理中对于已经预订的顾客，需要查找预订信息，再由接待check-in过程处理；如果没有预订，则直接由check-in过程处理。图中也说明了接待处理与处理3 “房卡处理”， 以及预订表、顾客表、客房表之间的数据关系。SRS-7则是处理4“客房处理”的细化，将“客房处理”分解为41 “入住处理”、 42 “客房服务处理”、43 “退房处理”、44 “赔偿处理”四个子部分；相应数据库 表4 “客房表”也分解为子表41 “客房状态表”、42 “客房服务消费表”、43 “客 房总消费表”、44“客房设备表”。并标明了客房处理与预订处理、房卡处理之间的关系。限于篇幅，其他细化DFD图省略。（作为范本可以省略，实际项目的分析说明书不能省略！）2.3 数据定义 2.3.1预订表2.3.2顾客信息表2.3.3房卡综合信息表房卡一卡通消费是本系统的基本要求。房卡只需与顾客信息表的关联绑定，顾客的其他信息就能从顾客表获得。例如想知道顾客的消费情况，只需将房卡号码与餐饮消费信息表关联，就可以检索出对应的消费记录。2.3.4客房信息表如前面在DFD图 中 所 述，“客房信息表”实际上是由如下一些子表所组成的。 2.3.4.1房间状态信息表2.3.4.2客房服务信息表2.3.4.3房间设备信息表2.3.4.4客房总消费表2.3.5娱乐休闲康体消费表2.3.6餐饮消费表2.3.7设备租赁信息表和客房信息表类似，此表由下列子表组成。2.3.7.1设备租赁情况表2.3.7.2设备租赁消费表限于篇幅，略去员工表等数据表（实际项目不能省略！）。 3 面向对象建模3.1 Use Case 模型Use Case图描述了系统中的参与者和用例，以及它们之间相互使用的关系。图SRS-8的Use Case图表达了顾客、接待员、收银员与软件的预订、接待、各种消费处理之间的关系。顾客除了可以直接预订外，其他都需要通过接待员、收银员等与软件交互。3.2 类图SRS-9所示的类图（Class Diagram)根据面向对象的方法对系统中的一些对象进行了提炼，将接待员、收银员、管理员作为员工类的子类；将各个消费对象中的共性提炼为消费父类，例如，都有房卡、消费项目、消费总额等属性及其操作。从而充分利用父子继承实现软件的复用。3.3 序列图下面以时序图分别描述预订、接待Check-in、退房Check-out过程中各个对象的动态交 互行为。注意对各个对象的操作一定要在这个对象的操作生命线上，以保持对象的封装性。 若要求其他对象的操作，则一定要通过对象交互实现，而不能“越俎代庖”，自行操作。3.3.1预订预订中接待员通过主窗口打开预订窗口，通过顾客对象创建顾客信息，再启动客 房查找过程查找合适客房,之后建立预订记录,更改房态为已预订状态。详见图SRS-10。 这里没有考虑预订的确认问题，如果需要，房态和预订单需增加“预订确认”状态， 并增加相应的确认处理。3.3.2 接待 Gheck-in接待入住中，首先查询是否己经预订，若未预订则创建客户信息，然后创建接待 记录，查找确认客房。确认后修改房态为“已入住”。最后须生成房卡，将客房等信息 写入房卡中，与房卡绑定。详见图SRS-11。3.3.3 退房 Check-out参见图SRS-12，退房中收银员启动收银窗口，通过房卡查询出对应的消费记录和客房入住记录，将消费信息汇总返回，请顾客确认；顾客确认无误后，向收银员支付款项，之后收银员按下收银支付完成确认按钮，软件自动修改房态，更新保存消费记录和接待记录，最后解除房卡与客房、客人的绑定。另外，顾客的消费信息，以及房卡、接待记录等信息也将直接反馈到管理员（值班经理）的电脑上，以便及时监察。4 验收标准本系统验收、维护主要按照计划书与合同中所规定的内容执行。这里根据需求分析中的考虑强调、补充以下几点：1.除由本项目测试人员测试通过外，还需由本公司测试人员配合酒店方人员及第三方人员共同进行测试，三方共同认可后才可签字验收。2.系统需按照本需求规范说明书所要求的目标进行设计、验收，建立满足酒店运营管理要求的软硬件环境。3.系统易于安装使用，界面设置合理清晰，直观易懂，表达准确。酒店员工只需经过简单培训后即可掌握使用。4.系统有较强的安全性，身份验证功能可靠，避免未授权用户通过非正常渠道获取及篡改系统信息。5.系统具有一定的稳定性，验收试用阶段为3个月，其间故障率平均为每48 小时小于等于4次，方可验收支付余款。否则继续延长3个月试用阶段，直到合 格。6.验收后第一年故障率平均每48小时内小于等于3次，第二年故障率平均每48 小时内小于等于2次。故障的发生与修复中不得丢失数据和影响酒店正常运营。7.在项目验收后两年内开发方提供免费维护；两年后提供有偿维护。8.系统的及时响应流畅，每一操作请求平均响应时间应在5秒内。9.系统容量上保证可容纳500台终端同时连接服务器操作。上述SRS实例已经过多次修改，看似不错，但