酒店点餐系统需求规格说明书

D.3.1介绍D. 3需求规格说明书酒店点餐系统1.0版本制作人：XXX2010-12-531.目标-32.项目范围和产品特征33.参考文献3总体描述31.产品远景规划32.用户类和用户特征-43.运行环境54.设计和实现条件约束55.用户文档56.假设和依赖-6系统特性 6查看菜单优先级1生成、修改、6（1）描述和-6- 7/| -2-）-激-励- -/-应 响序列6- 7/| -3一-）- -功- -匕匕 一能-性需求6-2管员m 二理加 增、查看、员改更信 工息-7- 7/| -1-）-描- -述- -和优先级-7- 7/| -2-）-激-励- -/-应 响序列-7- 7/| -3一-）- -功- -匕匕 一能-性需求8-3- - -支- - -付账单9-4用户成 生、修改删、点 除餐-9- 7/| -1-）-描- -述- -和优先级9- 7/| -2-）-激-励- -/-应 响序列9- 7/| -3一-）- -功- -匕匕 一能-性需求10-5- -用-户- -要-求加菜-1 -11 - - -6艮 服务人员看 查点餐117服务人员送餐给顾客或房客-118收银人员对账单存根119 厨 师 查 看 用 户 要 求 的 菜 品 并 完 成 菜 品 11D.3.2 外 部 接 口 需 求- 11品远景规划1.产112.硬件接口113.软件接口124.通信接口12其他非功厶匕能性需求121.安全性需求132.软件质量属性13D.3.1 介绍1. 目标软件需求规格说明书描述了“酒店点餐系统” 1.0 版本的软件功能性需求和 非功能性需求。 这一文档计划由实现和验证系统正确功能的项目团队来使用。 除 非在其他地方另有说明，这里制定的搜有需求都具有最高优先级，而且都要在 1.0 版本中加以实现。2. 项目范围和产品特征“酒店点餐系统”允许用户向酒店的服务员点餐后，酒店的服务人员利用该系统对客户的菜品进行管理(增删改查)并在就餐完毕后生成账单，完成付账和 账单管理。详细的项目描述请参见“ 025赵晓晓059黄婷-酒店订餐系统前景和 范围文档”。这一部分的标题为“初始版本和后续版本的范围”，列出了按照进 度计划在这一版本中实现的全部或部分特性。3. 参考文献(1) Karl E.Wiegers 所著的 Software Requirements 第 2 版总体描述1. 产品远景规划“酒店点餐系统”是一个新系统，它取代了该酒店以人工方式点菜和传菜单 的过程。图D.1是一幅关联图，它演示了 1.0版本的外部实体和系统接口。付账系统付款要求-菜单内容菜单经理顾客付餐费点餐菜单员工信息A酒店点餐系统管理员饭菜信息点餐记录酒店目录系 统图D.1“酒店点餐系统”版本1.0的关联图2. 用户类和用户特征用户类 描述 服 务人员 酒店的服务人员是本系统的直接操作者，他们希望摆脱人工记忆（优 先考 或者手写完成点餐过程的方式，有足够的设备可以供给他们完成 虑）从顾客要求点餐，到完成点餐和交付菜单给厨房以及生成账单等功能。大约有50家酒店需要这种系统，而系统的潜在用户则多达 1000人，他们每天都与本系统相伴完成他们的工作。服务人员需 要根据学历的不同程度进行培训，学会如何使用该点餐客户端， 知道如何交付菜单给厨房；何时，如何生成账单等细节。收银处每间酒店大约会有1-2个就餐处的收银人员，他们通过本系统接收顾客上菜完毕后服务人员生成的账单，计算相应税费，根据本 系统进行收银和账单管理（对账单的存根，交付给酒店账目管理 系统）。并且他们要求本系统能够使用不同的收费方式，如现金、 银行卡、支票等支付方式。厨房工作人酒店的厨房工作人员可以视为一个整体，每间酒店的此类人员约员20人，他们通过本系统从服务人员客户端获得传来的菜单，完成菜品后通知服务人员取餐并告知他们改菜品是那一桌所点顾客顾客是在使用本系统的酒店用餐的人员，是本系统的间接用户，他们希望他们在酒店用餐时的心情是愉快的，即点餐和付账时， 菜品和账目都不会出现差错，结账是的项目都足够清晰。他们虽 不直接操作该系统，但他们对酒店的要求和态度会直接影响到系 统的功能内容3. 运行环境（Operating Environment ， OE）OE-1： “酒店点餐系统”的服务人员采用遥控器上的java小程序完成点餐OE-2: “酒店点餐系统”的收银人员采用 windows2K及以上版本的客户端OE-3: “酒店点餐系统”的厨房工作人员采用 windows2K及以上版本的客户端。4. 设计和实现条件约束( COnstraint )CO-1: “酒店点餐系统”数据库采取当前酒店采用的Oracle数据库引擎。CO-2：“酒店点餐系统”存在可连接“酒店账目管理系统”的接口。5. 用户文档(User Documentation, UD)UD-1：系统在收银处客户端和厨房客户端提供联机帮助，而点餐客户端采用纸质说明书。它们描述和演示了所有系统功能。UD-2:如果是一个新用户第一次使用前两种系统，系统可以根据用户的要求。 提供一个联机教程， 这一教程可引导用户将所有流程实现一遍。 这样用户可以使 用静态教程菜单来具体实践收银处如何结账和账单存根以及厨房如何接受点菜 菜单及通知服务人员取餐送餐。系统不会将这一模块操作存储到数据库中。6. 假设(ASsumption)和依赖(DEpendency)AS-1:只要酒店餐厅开始营业(06:00-02:00 )则点餐、结账、厨房三个客 户端都处于开启状态AS-2：只要是要求员工在岗的每一个工作日，酒店餐厅在早餐、中餐、晚餐 及夜宵时都处于营业状态。DE-1： “酒店点餐系统”的运行依赖于“账目管理系统”和“薪资核算系统” 的变更，它接受“酒店点餐系统”的菜单更新要求后，增删相应的菜品。D.3.3 系统特性1 、生成、修改、查看菜单( 1 )描述和优先级酒店餐饮部的厨师其身份得到验证之后， 他们就可以对菜单进行 “增、 删、 改、查”操作(修改后需要通过管理员，即酒店经理验证，则这些操作有效，如2小时内无响应，则这些人员的操作无效，菜品不会有任何改变。)(2) 刺激/响应序列刺激：厨师登陆后对菜单进行操作。响应：系统对厨师的每一个设计更改的操作提示。刺激：厨师完成对菜单的修改后要求交替给管理员审阅。响应：在管理员接收到此更改后系统提示厨师请求已提交。刺激：管理员认为更改合理或不合理，提交通过更改或不通过。响应：系统接收管理员操作交付厨师。(3) 功能性需求Kitche n.logon厨师输入验证信息登录本系统Kitche n.search厨师查看已有菜单Kitche n.create厨师创建新的菜单Kitche n.delete厨师删除菜单中的菜品Kitche n. submit厨师将修改的内容提交给经理Kitche n. update厨师修改菜单中的内容Kitche n.pass管理员师对菜单的修改Kitche n.deny管理员对菜单的修改Kitche n.return未通过的菜单被恢复到原来状态Kitche n.timer厨师对菜单的修改完成后启动该方法，超时则调用return 方法Kitche n.reflctio n将管理员的操作反馈给厨师Kitche n. exit.厨师退出登录2管理员增加、查看、更改员工信息(1) 描述和优先级当管理员成功登录到本系统时，能够对员工信息进行查看和修改。优先级(2) 刺激/响应序列刺激：管理员请求登录到本系统。响应：系统显示登录界面及验证管理员身份信息。刺激：管理员请求查看某员工信息。响应：系统显示该员工信息。刺激：管理员请求修改某员工信息。响应：系统显示为员工信息编辑界面。刺激：管理员请求增添新员工。响应：系统创建一新员工，并等待管理员对其信息进行编辑。(3) 功能性需求Man ager.log on系统显示管理员登录界面Man ager.welcome管理员信息经过系统验证后，管理员进入欢迎界面Man ager.select管理员选择查看或者修改某员工信息服务Man ager.fi nd管理员输入所要查找信息员工的员工号Man ager.fi nd.display若系统中存在所要查找的员工号，则显示该员工信息；若不存在，则显示“此员工号不存在”Man ager.update管理员输入所要更新信息员工的员工号系统根据员工号查找到某员工并将信息显示出 来，等待管理员编辑Man ager.update.c onform系统提示管理员确认编辑信息系统将刚刚编辑完成的员工信息显示出来。Man ager.add管理员请求增添新员工信息系统为新员工分配一员工号，并等待管理员将新员工信息补充完整Man ager.add.c onform系统提示管理员确认补充信息系统将刚刚增添完成的员工信息显示出来Man ager.delete管理员请求删除离职员工信息系统根据离职员工的员工号查找到该员工Man ager.delete.c onform系统提示管理员确认删除员工信息Man ager.delete.c on form.yes管理员确认删除系统显示员工信息已删除Man ager.logoff管理员退出登录3. 支付账单（该范例不提供细节）4. 用户生成、修改、删除点餐（1）描述和优先级顾客进入餐厅，访问点餐系统，浏览当日菜单，选择自己想要的食物。在 顾客提交点餐记录之前，都可以修改和取消菜单，优先级为高。（2）刺激/响应序列刺激：顾客请求查看当日菜单。响应：系统显示菜单和当日特色菜。刺激：顾客请求提交点餐记录。响应：系统显示所点菜品条目、单价和总价格。刺激：顾客请求修改点餐记录。响应：系统允许客户编辑以前的点餐记录。刺激：顾客确认提交点餐记录。响应：系统将点餐记录发往厨房。（3）功能性需求Order.i ndex访问“酒店点餐系统”的顾客可以通过系统点餐Order.me nu系统将显示菜单和当日特色菜Order.me nu.food保存当前顾客点餐记录Order.me nu .submit顾客请求提交点餐记录1. 用户界面( User Interfaces, UI)Order.me nu .display系统显示所点菜品条目、每一菜品条目的单价以及 应该支付多少费用Order.c on form.prompt系统提示顾客确认点餐记录Order.c on form. not如果顾客不确认点餐记录，那么顾客既可以编辑点 餐记录，也可以取消点餐Order.c on form.yes顾客确认点餐记录系统将点餐记录发往厨房如果点餐过程中任何一步不成功，则系统将回滚事 物，通知顾客点餐不成功，并说明失败的原因5 用户要求加菜（该范例不提供细节）6服务人员查看点餐（该范例不提供细节）7服务人员送餐给顾客或房客（该范例不提供细节）8. 收银人员对账单存根（该范例不提供细节）9. 厨师查看用户要求的菜品并完成菜品（该范例不提供细节）外部接口需求UI-1 ：“酒店点餐系统”的屏幕画面将遵照本公司各方式客户端应用程序用 户的标准用户界面。UI-2 ：系统对收银端和厨房端的每一个操作都提供帮助连接， 解释如何使用 这些操作。UI-3 ：收银客户端采用鼠标或键盘的方式对个操作进行控制， 点餐客户端采 用遥控器上的按钮进行操作，厨房客户端采用触摸屏的方式对每个操作进行控 制。2. 硬件接口硬件接口还没有确定3. 软件接口( Software Interfaces, SI )SI-1 ：酒店账目管理系统SI-1.1 ：“酒店点餐系统”通过界面将结负的账单传递给“账目管理系统” 用于存根及月底核算SI-1.2 ：“酒店账目管理系统”将酒店餐饮部的收入支出进行统计生成财务 报表，生成下一季度该部门的财务筹措，提交给“酒店点餐系统”保存，此举将 影响到酒店餐饮部的采购预算。从而决定本季度的菜品数量。SI-2 ：酒店薪资核算系统SI-2.1 ：“酒店点餐系统”记录的管理员、收银员、厨师、服务生他们相应 的等级、薪酬、奖金、罚金来自酒店“薪资核算系统”的数据传输。SI-2.2 ：“薪资核算系统”接受“酒店点餐系统”的人员调动情况，对相应 人员进行“增删改查”操作。SI-3 ：客房服务订餐系统SI-3.1 ：“客房服务订餐系统”将房客要求的菜品通过客房的客户端传递给酒店点餐系统”生成相应菜品和账单SI-3.2 ：“酒店点餐系统”讲完成菜品信息交付送餐人员及“客房服务订餐 系统”通知菜品完成并即将送到。SI-4 ：酒店客房结算系统SI-4.1 ： “酒店点餐系统”接受“客房订餐系统”的菜品要求完成菜品后 生成账单交付酒店客房结算系统和 “酒店账目管理系统” 作为酒店餐饮部收入之 一。4. 通信接口 (Communications Interface ，CI)CI-1 ：“酒店点餐系统”支持银行卡、支票支付，则需将顾客的银行卡、支 票信息交付银行加以确认该客户合法。D.3.5 其他非功能性需求1.安全性( SEcurity )需求SE-1:所有涉及功能信息会个人身份信息的事务，都要进行加密操作。SE-2:顾客的访问受酒店内系统访问控制策略的限制。SE-3：酒店的工作人员，只有那些授权为菜单经理的成员，才能通过系统创建和编辑菜单。SE-4：酒店的工作人员，只有那些授权为系统管理员的成员，才能通过系统增添，查找和删除员工信息。SE-5：系统只允许顾客修改他们尚未提交的点餐记录，并且只能浏览自己的点餐记录，而不能浏览其他顾客的点餐记录。2软件质量属性Robustness (健壮性)-1 :如果在点餐得到确认或取消之前，用户和系统的 连接中断，那么用户能通过该系统恢复不完整菜单。Integrity (完整性) -1 ：只有拥有管理员访问特权的用户才可以查看和修 改酒店员工信息。Usability （易用性） -1 ：一个从没使用过“酒店点餐系统”的用户应该可 以在平均 5 分钟的时间内，能够使用该系统点餐。