餐饮管理系统需求规格说明书1

1、机构图标 项目名称 产品需求规格说明书文件状态： 草稿 正式发布 正在修改文件标识：Company-Project-RD-PRS当前版本：X.Y作 者：完成日期：Year-Month-Day机构公开信息版 本 历 史版本/状态作者参与者起止日期备注 目 录 0. 文档介绍40.1 文档目的40.2 文档范围40.3 读者对象40.4 参考文档40.5 术语与缩写解释41. 产品介绍52. 产品面向的用户群体53. 产品应当遵循的标准或规范54. 产品范围55. 产品中的角色56. 产品的功能性需求66.0 功能性需求分类66.m Feature M66.m.n Function M.N67.

2、产品的非功能性需求77.1 用户界面需求77.2 软硬件环境需求77.3 产品质量需求77.n 其它需求7附录A：需求建模与分析报告8A.1 需求模型18A.n 需求模型N8附录B：需求确认90. 文档介绍0.1 文档目的0.2 文档范围0.3 读者对象0.4 参考文档提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：SPP-PROC-PP SEPG，需求开发规范，机构名称，日期0.5 术语与缩写解释缩写、术语解 释1. 产品介绍提示：（1）说明产品是什么，什么用途。（2）介绍产品的开发背景。2. 产品面向的用户群体提示：

3、（1）描述本产品面向的用户（客户、最终用户）的特征，（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？3. 产品应当遵循的标准或规范提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。4. 产品范围提示：阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。5. 产品中的角色提示：阐述本产品的各种角色及其职责。

4、各种角色的具体行为将在功能性需求中描述。角色名称职责描述6. 产品的功能性需求6.0 功能性需求分类提示：将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。功能类别功能名称、标识符描述Feature AFunction A.1Feature BFunction B.1Feature CFunction C.16.m Feature M提示：此处写一些承上启下的文字。6.m.n Function M.N名称、标识符功能描述优先级输入操作序列输出补充说明7. 产品的非功能性需求7.1 用户界面需求需求名称详细要求7.2 软硬件环境需求

5、需求名称详细要求7.3 产品质量需求主要质量属性详细要求正确性健壮性可靠性性能，效率易用性清晰性安全性可扩展性兼容性可移植性7.n 其它需求附录A：需求建模与分析报告。A.1 系统总体功能模型A.2 大厅服务模块分析用例图：用例说明：用例编号1用例名称查询餐位分部和使用情况事件流基本流：1、 查询餐位分部情况；2、 查询餐位使用情况；3、 是否有顾客；4、 如果有，根据顾客位数安排餐位，并记录台号；5、 保存信息备选流：1、 如果没有，记录可用的各桌台号；前置条件1、 餐位的分部和使用情况的数据能正常取得后置条件1、 数据正确保存；2、 正确的得到餐位情况的状态；其他用例编号2.1用例名称电话

6、预订事件流基本流：1、 派发传单；2、 记录是否有顾客电话预订的信息；3、 如果有，记录顾客点菜的菜式；4、 保存信息；备选流：1、 如果没有，等待顾客电话预订；前置条件1、 顾客电话预订的数据能正常取得后置条件1、数据正确保存；2、 正确的得到顾客预订信息；其他用例编号2.2用例名称网上预订事件流基本流：1、 派发传单；2、 登陆餐厅网址，并观察是否有顾客网上预订；3、 如果有，记录顾客点菜的菜式；4、 保存信息备选流：1、 如果没有，等待顾客网上预订；前置条件1、 顾客网上预订的数据能正常取得；后置条件1、 数据正确保存；2、 正确的得到顾客网上预订信息；其他用例编号2.3用例名称人工预订

7、事件流基本流：1、顾客到餐厅直接预订菜式；2、记录顾客点菜信息；3、记录顾客信息；4、保存信息前置条件1、 顾客预订的数据能正常取得；后置条件1、 数据正确保存；2、 正确的得到顾客预订信息；其他用例图：用例说明：用例编号用例名称菜式详细信息事件流基本流：1、 通过电话预订，得到顾客点菜信息，并准备；2、 通过网上预订，得到顾客点菜信息，并准备；3、 通过人工预订，得到顾客点菜信息，并准备；4、 保存信息；备选流：1、其他途径得到顾客点菜信息，并准备；前置条件1、 顾客预订的数据能正常取得；后置条件1、数据正确保存；2、 正确的得到顾客预订信息；其他用例编号用例名称菜式所需材料事件流基本流：1

8、、得到顾客点菜的菜式信息后，准备相对应的菜式材料；备选流：前置条件后置条件其他用例编号用例名称餐具准备、检查事件流基本流：1、准备、检查餐具，以便及时放菜式；备选流：前置条件后置条件其他用例编号用例名称开始菜式制作事件流基本流：1、得到菜式材料、餐具准备后，开始菜式制作；备选流：前置条件后置条件其他用例编号7.1用例名称上菜通知事件流基本流：1、 菜式制作完成后，打开系统管理；2、 点击“上菜通知”；备选流：前置条件后置条件其他用例图：用例说明：用例编号19.1用例名称端上菜式的材料事件流基本流：1、 记录厨师所需的材料；2、 对材料进行一定的清洗；3、 端上菜式的材料；备选流：1、 材料不足

9、，进行仓库补给；2、 回到1之后；前置条件后置条件其他用例编号19.2用例名称端上盘子接菜事件流基本流：1、 检查、清洗餐具；2、 洗刷完成后，等待厨师叫唤；3、 端上餐具；备选流：前置条件后置条件其他用例编号用例名称接收服务员通过顾客点菜的信息，并告知事件流基本流：1、 等待服务员发放信息；2、 接收到信息后，传送到厨师；3、 等待厨师的吩咐；备选流：前置条件后置条件其他用例图：用例说明：用例编号用例名称当日消费流水事件流基本流：1、 点击“当日消费流水”2、 列表显示当日已结账的所有台位消费清单；3、 显示汇总金额；4、 可以打印；备选流：前置条件后置条件其他用例编号用例名称当日消费未收事

10、件流基本流：1、 点击“当日消费流未收”2、 列表显示当日未结账的所有台位消费清单；3、 显示未结账总金额；4、 可以打印；备选流：前置条件后置条件其他用例编号.1.2用例名称当班情况事件流基本流：1、 汇总当班消费流水；2、 汇总当班消费未收；备选流：前置条件后置条件其他用例图：用例说明：用例编号3.1用例名称上菜事件流基本流：1、 输入要上菜的点菜单台号；2、 根据输入的台号显示点菜单详细信息；3、 上菜：选择要退的菜，点“上菜”操作，数据记录标记；4、 保存信息；备选流：1、 输入的台号错误（不是正在消费的台号），提示重新输入，回到基本流1；2、 点菜单数据保存失败，回到基本流2；前置条

11、件1、有正在消费的台号，且台号输入正确；后置条件1、 数据正确保存；2、 以标记上菜的信息可在厨房准确显示；其他用例编号20.1用例名称增加新的菜式事件流基本流：1、输入要修改的点菜单台号；2、根据输入的台号显示点菜单详细信息；3、新增菜式：显示总菜单进行复选，提交后将选择的菜式加入到点菜单详细信息中，回到2；4、取消菜式：选择要取消的菜式，点“取消”操作，数据记录标记；5、修改菜式数量；6、保存信息；备选流：1、 输入的台号错误（不是正在消费的台号），提示重新输入，回到基本流1；2、 所选“取消”的菜式已经上菜，提示并回到基本流2；3、 点菜单数据保存失败，回到基本流2;前置条件1、有正在消

12、费的台号，且台号输入正确；后置条件1、数据正确保存；2、新增菜式、取消菜式、新增数量均可在厨房准确显示；其他用例编号20.2用例名称删除旧的菜式事件流基本流：1、输入要修改的点菜单台号；2、根据输入的台号显示点菜单详细信息；3、退菜：选择要退的菜，点“退菜”操作，数据记录标记，根据需要记录退菜备注（退菜原因）；4、取消菜式：选择要取消的菜式，点“取消”操作，数据记录标记；5、修改菜式数量；6、保存信息；备选流：1、 输入的台号错误（不是正在消费的台号），提示重新输入，回到基本流1；2、 所选“取消”的菜式已经上菜，提示并回到基本流2；3、 点菜单数据保存失败，回到基本流2;前置条件1、有正在消

13、费的台号，且台号输入正确；后置条件1、数据正确保存；2、退菜信息、取消菜式、均可在厨房准确显示；其他用例图：用例说明：用例编号.1用例名称挂单事件流基本流：1、选择已经消费的台号；2、点击“结账“按钮；3、显示消费清单和金额汇总；4、点击“挂单处理“，并结束结账；5、保存信息；备选流：1、 打折处理，在3之后，点击打折；2、 输入折扣比例；3、 计算应收金额，回到基本流3；前置条件1、所有正在消费的台号数据能正常取得；后置条件1、数据正确保存；2、正确保存结账状态（正常结账、折扣结账、挂单）；其他用例编号.2用例名称埋单事件流基本流：1、选择已经消费的台号；2、点击“结账“按钮；3、显示消费清单和金额汇总；4、点击“埋单处理“，并结束结账；5、保存信息；备选流：4、 打折处理，在3之后，点击打折；5、 输入折扣比例；6、 计算应收金额，回到基本流3；前置条件1、所有正在消费的台号数据能正常取得；后置条件1、数据正确保存；2、正确保存结账状态（正常结账、折扣结账、埋单）；其他附录B：需求确认提示：需求确认规程请参见SPP-PROC-RM，主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”，规程请参见SPP-PROC-TR。在获取责任人（Stakeholders）对需求的承诺之前，该产品需求规格说明书必须先通