1、项目名称,《产品需求规格说明书》 机构图标 传智播客餐饮管理系统 产品需求规格说明书 文件状态: [√] 草稿 [ ] 正式发布 [ ] 正在修改 文件标识: Company-Project-RD-PRS 当前版本: 0.1 作 者: 完成日期: 2014-2-5 北京传智播客教育科技有限公司 版 本 历 史 版本/状态 作者 参与者 起止日期 备注 0.1/草稿 杨洪波 2013-12-2014-2-5
2、目 录 0. 文档介绍 4 0.1 文档目的 4 0.2 文档范围 4 0.3 读者对象 4 0.4 参考文档 4 0.5 术语与缩写解释 4 1. 产品介绍 5 2. 产品面向的用户群体 5 3. 产品应当遵循的标准或规范 5 4. 产品范围 5 5. 产品中的角色 5 6. 产品的功能性需求 6 6.0 功能性需求分类 6 6.m Feature M 6 6.m.n Function M.N 6 7. 产品的非功能性需求 7 7.1 用户界面需求 7 7.2 软硬件环境需求 7 7.3 产品质量需求 7 7.n 其它需求 7 附录A:需求建模与分
3、析报告 8 A.1 需求模型1 8 A.n 需求模型N 8 附录B:需求确认 9 0. 文档介绍 0.1 文档目的 本说明书对餐饮管理系统的架构与范围,以及商机需求和软件中的模块规划和相关业务《用户需求说明书》是软件项目开发的首要工作,本文档从用户角度说明餐饮管理系统要实现的用户需求,包括几百蚊需求和其他需求,为项目开发和后续扩展提供基础与约束的定义作了的明确定义和描述,并作为开发者下一步设计工作的重要依据。 0.2 文档范围 0.3 读者对象 0.4 参考文档 ----杨洪波 日期:2014.2.5 机构: 北京传智播客教育科技有限公司 0.5 术语与缩写
4、解释 缩写、术语 解 释 … 1. 产品介绍 随着餐饮业的不断发展,餐饮管理系统的内容对于餐饮业的决策者和管理者来说都非常重要。本系统主要包括餐桌显示,消费查询、会员管理和商品管理等几大部分,本系统具有良好的用户体验,使用方便。具有完善的查询,对维护系统起到辅助决策的作用,能即使、方便、灵活地进行查询、修改、删除等维护性操作。餐饮管理系统有足够的存储容量,满足九点每日营业的变动,另外,对于操作用户有一定的管理,并对用户的权限有一定的设置。 2. 产品面向的用户群体 此餐饮操作系统适合大多数餐饮业. 使用此餐饮管理系统方便您日常管理酒店,需要您熟练
5、操作window系统即可 3. 产品应当遵循的标准或规范 提示:阐述本产品应当遵循什么标准、规范或业务规则(Business Rules),违反标准、规范或业务规则的产品通常不太可能被接受。 4. 产品范围 5. 产品中的角色 提示:阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。 6. 产品的功能性需求 6.0 功能性需求分类 提示:将功能性需求先粗分再细分,下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。 功能类别 功能名称、标识符 描述 收银员业务 收银 当日、当班情况汇总
6、 大厅服务员业务 餐位分布、使用信息查询 餐位预定管理 厨师 显示点菜信息 登记菜式制作过程信息 领料登记 经理 7. 产品的非功能性需求 7.1 用户界面需求 7.2 软硬件环境需求 序号 需求名称 需求描述 1 操作系统 Windows XP SP2(中文版和英文版) 2 数据库系统 SQL Server2005中文版 3 开发工具 VS2008 4 编程语言 C# 5 支撑软件 .NET Framework3.5 6 运行环境 Windows xp 7 测
7、试平台 Windows xp 7.3 产品质量需求 序号 需求名称 需求描述 1 正确性 无明显BUG 2 可靠性 运行稳定,不会出现错误 3 易用性 用户不经培训即可轻松掌握使用方法 4 兼容性 兼容Windows 2000以上 5 安全性 用户资料要保密 7.4 性能要求 序号 需求名称 需求描述 1 吞吐量需求 可处理15桌以上的客人就餐信息,加100以上员工信息 2 容量 按照理论,数据库应无客户及事物上限,但考虑实际情况,设计用户容量100人。 附录A:需求建模与分析报告 。 A.1 系统
8、总体功能模型 用例图: 总体功能说明: (简单文字说明系统总的功能) A.2 收银员业务需求 用例图: 用例说明: 用例编号 9 用例名称 收银 事件流 基本流: 1、 选择已经消费的台号; 2、 点击“结账”按钮; 3、 显示消费清单和金额汇总; 4、 输入实收金额; 5、 计算并显示找零; 6、 点击“结账完毕”; 备选流: 1、 挂单处理:在3之后点击“挂单”按钮,结束结账; 2、 免单处理:在3之后点击“免单”按钮,结束结账; 3、 打折处理:在3之后,点击“打折”; 4、 输入折扣比例; 5、 计算应收金额,回到基本流3;
9、 前置条件 1、 所有正在消费的台号数据能正常取得; 后置条件 1、 数据正确保存; 2、 正确保存结账状态(正常结账、折扣结账、免单、挂单); 其他 用例编号 10.1.1 用例名称 汇总当日消费流水 事件流 基本流: 1. 点击“汇总当日流水”; 2. 列表显示当日已结账的所有台位消费清单; 3. 显示汇总金额; 4. 可以打印; 备选流: 前置条件 1. 当日消费数据存在; 后置条件 其他 用例编号 10.1.2 用例名称 当日消费未收汇总 事件流 基本流: 5. 点击“汇总当日流水”; 6. 列表显
10、示当日已结账的所有台位消费清单; 7. 显示汇总金额; 8. 可以打印; 备选流: 前置条件 2. 当日消费数据存在; 后置条件 其他 A.3 大厅服务员业务需求 用例图: 附录B:需求确认 提示:需求确认规程请参见SPP-PROC-RM,主要分两步:(1)需求评审,(2)需求承诺。对需求的评审应当采用“正式技术评审方式”,将产生一份“需求评审报告”,规程请参见SPP-PROC-TR。在获取责任人(Stakeholders)对需求的承诺之前,该《产品需求规格说明书》必须先通过需求评审。 需求评审报告摘要 需求文档 输入名称,标识符
11、版本,作者,完成日期,… 需求评审报告 输入名称,标识符,评审日期,… 评审结论 [ ] 工作成果合格,“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格,需要作少量的修改,之后通过审核即可。 [ ] 工作成果不合格,需要作比较大的修改,之后必须重新对其评审。 评审意见 评审小组成员 输入评审小组成员 需求承诺 需求文档 输入名称,标识符,版本,作者,完成日期 客户承诺 承诺… 签字,日期 项目经理承诺 承诺… 签字,日期 Ó 机构名称,2002 Page 17 of 17






