需求分析文档范例(教学用)

【原书名】 Software Requirements,SEcond Edition [原书信息] 【原出版社】 Microsoft Press 【作者】 （美）Karl E.Wiegers 【译者】 刘伟琴 刘洪涛

【开本】 185×260 【页码】 357 D

需求文档范例 ................................................................................................................... 1 D.1 前景和范围文档 ........................................................................................................... 2

D.1.1 业务需求 ........................................................................................................... 2 D.1.2 解决方案的前景 ............................................................................................... 3 D.1.3 范围和局限性 ................................................................................................... 3 D.1.4 业务上下文 ....................................................................................................... 4 D.2 用例 ............................................................................................................................... 6 D.3 软件需求规格说明 ..................................................................................................... 10

D.3.1 介绍 ................................................................................................................. 10 D.3.2 总体描述 ......................................................................................................... 10 D.3.3 系统特性 ......................................................................................................... 12 D.3.4 外部接口需求 ................................................................................................. 14 D.3.5 其他非功能性需求 ......................................................................................... 15 D.3.6 附录A 数据字典和数据模型 ....................................................................... 16 D.3.7 附录B分析模型 ............................................................................................ 18 D.4 业务规则 ..................................................................................................................... 19

D 需求文档范例

该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容：  前景和范围文档。

 用例列表和若干用例描述。  部分软件需求规格说明。  某些分析模型。  部分数据字典。  若干业务规则。

因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。

1

这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。

D.1 前景和范围文档

D.1.1

业务需求

1.背景、业务机会和客户需要

目前，Process Impact公司的大多数员工平均每天要花费60分钟去自助食堂选择、购买并用午餐，其中大约有20分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午餐、以及以现金方式或以信用卡方式结算餐费上。当员工出去用午餐时，他们平均有90分钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助食堂准备好他们所选择的午餐。但是，员工并不是总能如愿以偿，因为自助食堂有些食物己卖完，而与此同时，自助食堂又不可避免地会浪费大量的食物，因为有些食物没有卖出去而只好倒掉。早餐和晚餐同样面临着这样的问题，只是到自助食堂用餐的员工人数比午餐要少得多。

许多员工都通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一服务的员工可以节约相当可观的时间，而且订到自己所喜欢的食物的机会也增大了。这既提高了他们的工作生活质量，也提高了他们的生产率。自助食堂提前了解到客户需要哪些食物，就可以减少浪费，并提高自助食堂员工的工作效率。要求送货上门的订餐员工将来还可以从本地的饭店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店的大量购餐协议而有可能节约费用。Process Impact公司也可以只在自助食堂订午餐，而在饭店订早餐、晚餐、特定事件的用餐以及周末会餐。

2.业务目标（Business Objective，BO）和成功标准（Success Criteria，SC）

BO-1：初始版本发布之后的6个月内，自助食堂的食物浪费减少50%。 度量单位（scale）：自助食堂的工作人员每星期所倒掉的食物的价值。

计量（meter）：检查“自助食堂存货系统（Cafeteria Inventory System）”的日志。 过去情况（past）[2002.初步调研]：30% 一般标准（plan）：小于15% 最低标准（must）：小于20%。

注 该范例展示了使用Planguage语言来精确陈述业务目标或其他需求这样一种方法。

BO-2：初始版本发布之后的12个月内，自助食堂的运作费用减少50%。 BO-3：初始版本发布之后的3个月内，每个雇员每天的平均有效工作时间增加20分钟。 SC-1：目前通过自助食堂解决午餐问题的那些员工，在初始版本发布之后的6个月内，他们中有75%的人使用“自助食堂订餐系统”。

SC-2：初始版本发布之后的3个月内，对自助食堂满意度的季度调查评价要提高0.5.而在初始版本发布之后的12个月内，这种满意度要提高1.0。

3.业务风险（Risk）

2

RI-1：“自助食堂雇员联合会（Cafeteria Emp1oyees Union）”可能要求与雇员重新签订合同，以反映新的雇员角色和自助食堂营业时间。（可能性为0.6，影响为3）

RI-2：使用该系统的雇员太少，减少了对系统开发和变更自助食堂经营过程的投资回报。（可能性为0.3.影响为9）

RI-3：本地饭店可能并不认同减价是雇员使用这一系统的正当理由，这会减低雇员对该系统的满意度，并可能会减少他们对这一系统的使用。（可能性为0.4，影响为3）

D.1.2

解决方案的前景

1.前景陈述

对那些希望通过公司自助食堂或本地饭店在线订餐的员工来说，“自助食堂订餐系统”是一个基于Internet的应用程序，它可以接受个人订餐或团体订餐，结算用餐费用，并触发将预订餐送到Process Impact公司内的指定位置。与当前的电话订餐和人工订餐不同，使用“自助食堂订餐系统”的雇员并不需要到食堂内去用餐，这既可以节约他们的时间，又可以增加他们对食物的选择范围。

2.主要特性（FEature）

FE-1：根据自助食堂提供的选择菜单或送货菜单来订餐。 FE-2：根据本地饭店的送货菜单来订餐。

FE-3：创建、浏览、修改和删除用餐预订服务。 FE-4：注册用餐的付费方式。 FE-5：请求送餐。

FE-6：创建、浏览、修改和删除自助食堂菜单。 FE-7：预订自助食堂菜单上所没有的定做菜。 FE-8：生成自助食堂定做菜的食谱和配料列表。

FE-9：通过公司的内联网可以访问系统，或者授权的员工通过外部Internet访问系统。

3.假设（ASsumption）和依赖（DEpendency）

AS-1：自助食堂内有可以访问公司内联网的计算机和打印机，这样自助食堂的雇员就可以处理期望的订单量，不会遗漏任何送货时间。

AS-2：最多比请求的送货时间晚15分钟，自助食堂有送货人员和送货车辆，这样就能满足所有订单的送货要求。

DE-1：如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一系统进行双向通信。

D.1.3

范围和局限性

版本1 只能从午餐菜单中订标准餐：交货单的费用支付方式只能是从工资中扣除 版本2 除了午餐订单外，也接受早餐订单和晚餐订单；费用的支付方式可以是信用卡和借记卡 版本3 1.初始版本和后续版本的范围 特性 FE-1 3

特性 FE-2 FE-3 FE-4 FE-5 FE-6 FE-7 FE-8 FE-9 不实现 版本1 不实现 完全实现 版本2 版本3 完全实现 如果有时间就实现（具有中等优先级） 注册的费用支付方式只能是从工资中扣除 送餐地点只能是公司内 完全实现 不实现 不实现 完全实现 注册的费用支付方式可以是信用卡和借记卡 送餐地点还可以选择在公司外面 不实现 完全实现 完全实现 2.局限性（Limitation）和排斥性

LI-1：自助食堂的有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单是食堂整个菜单的一个子集。

LI-2：“自助食堂订餐系统”只能用于俄勒冈州Clackamas的Process Impact公司总部内的自助食堂。

D.1.4

业务上下文

主要价值 态 度 强烈承诺完成版本2.如果有条件尽早完成版本3 主要兴趣 使用该系统所节约的费用必须超过开发此系统的费用和使用此系统的费用 无 培训工作人员，掌握使用Internet所必需的技能；必须有送货人员和车辆 约束条件 1.涉众概览 涉 众 公司管理层 自助食堂工作人员 顾客 提高员工生产率；节约自助食堂的费用 更高效地利用了工作人员的整个工作时间：提高了客户的满意度 担心与联合会的关系，担心食堂有可能会裁员；否则很愿意接受新系统 保住工作 可以更好地选择食物；节约了时间：更加方便 积极支持新系统，但使用系统的次数可能没有期望的次数多，这主要是因为顾客考虑到在自助食堂和饭店就餐具有社会价值 使用要简单；送货可靠；食物选择的有效性 需要访问公司内联网 薪资管理部门 饭店经理 得不到什么益处：需要建立从工资中扣除餐费的注册方案 增加了销售额；扩大了销售范园，增加了新客户 不愿意采用该软件系统，但认识到对公司和员工的整体利益，所以能以大局为重 虽然接受，但比较谨慎 尽量减少对当前薪资核算软件所做的变更 尽量少用新技术：关注送餐所需的资源和费用 还没有得到资源来实现薪资软件的变更 可能没有足够的人手和能力来处理订单；可能需要得到Internet访问权 4

2.项目优先级 因素 进度 具体干活者 约束条件 自由度 计划3/l/03前完成第一版，到5/l/03前完成第二版；在不包括责任人评审的情况下，最多可超过期限3个星期 特性 质量 安排1.0版本实现的特性必须完全可操作 必须通过95%的用户验收测试；必须通过全部的安全性测试；所有的安全事务都必须遵守公司的安全标准 工作人员 项目团队规模包括一名半日工作的项目经理，两名开发人员，和一名半日工作的测试人员；如果有必要，还可以另外再增加半日开发人员和半日测试人员 费用 在不包括责任人评审的情况下，财政预算最多可超支15% 5

D.2 用例

各种用户类确认的“自助食堂订餐系统”的用例和主要参与者如下所示：

主要参与者 1.订餐 2.变更订单 3.取消订单 4.查看菜单 顾客 5.注册从工资中扣除餐费的付费方式 6.取消注册的从工资中扣除餐费的付费方式 7.订购标准餐 8.修改所订的标准餐 9推翻所订的标准餐 10.创建菜单 菜单经理 11.修改菜单 12.定义特色菜 13.准备餐 自助食堂工作人员 14.生成付费请求 15.请求送货 16.生成系统使用报告 17.送餐 送餐人员 18.记录送餐情况 19.打印送餐说明 用例ID号 用例名称 创建者 最后更新者 创建日期 最后更新日期 参与者 描述 UC-1 订餐 Karl Wiegerss Jack McGillicutty 2002年10月21日 2002年11月7日 顾客 顾客从公司内联网或从家里访问“自助食堂订餐系统”，随意查看某一天的菜单，选择自己想要的食物，提交订单并要求在特定的时间窗口（15分钟）内送货到指定的地点 1.顾客登录到“自助食堂订餐系统” 2.顾客注册的付费方式是从工资中扣除 1.订单在“自助食堂订餐系统”中的存储状态是“已接受” 后置条件 2.根据这一订单的食物条目来更新食物存货 3.根据这一次的送货请求，对请求的时间窗口更新剩余的送货能力 1.0 订一份餐 1.顾客要求查看某一天的菜单 主干过程 2.系统显示有效食物菜单和当日特色菜 3.顾客从菜单中选择一种或多种食物 4.顾客表明订餐完成

6

用 例 前置条件 主要参与者 用 例 5.系统显示所订菜单条目、单价和总价格，包括应交纳的税和送货费用 6.顾客确认订餐订单或请求修改订餐订单（回到第3步） 7.系统显示那一天中有效的送餐时间 8.顾客选择送餐时间和指定送餐地点 9.顾客指定付费方式 10.系统确认接收订单 11.系统向顾客发送电子邮件，确认订单细节、价格和送餐说明 12.系统将订单存储在数据库中，并发送电子邮件通知自助食堂工作人员，将食物信息发送给自助食堂库存系统，并更新有效的送餐时间 1.1 订多份餐（第4步之后分支出来） 1.顾客要求预订另一份餐 2.返回到第2步 1.2 同样的餐订多份（第3步之后分支出来） 分支过程 1.顾客请求预订指定数量的同样食物的多份餐 2.返回到第4步 1.3 订当日特色菜（第2步之后分支出来） 1.顾客从菜单中订当日特色菜 2 返回到第5步 1.0.E.1 订单截止时间在当前时间之前（第1步） 1.系统通知顾客今天订餐已太晚了 2a，顾客取消订单 2b.系统终止用例 3a，顾客请求选择另一个日期 3b 系统重新启动用例 1.0.E.2 没有有效的送餐时间（第1步） 1.系统通知顾客送餐日己没有有效的送餐时间 2a.顾客取消订单 2b.系统终止用例 3.顾客请求在自助食堂选择订单（跳过第7步和第8步） 12.E.1 不能完成指定数量的同样食物的多份餐（第1步） 1.系统通知顾客它所能提供的同样食物曲多份餐的最大数量 2 顾客变更所订的同样食物的份数，或者取消订单 异常 包含 优先级 使用频率 业务规则 无 高 大约400名用户，平均每天使用一次 BR-1，BR-2，BR-3，BR-4，BR-8，BR-11，BR-12，BR-33 特别需求 1.顾客在确认订单之前的任何时间都可以取消订单 2.顾客能查看自己前6个月的全部订餐，并可以重复其中的任一次订餐作为新的订餐，只要所有食物在请求送餐日的菜单中都有效。（优先级为中） 1.假设30%的顾客会订当日特色菜（来源：根据前6个月的自助食堂数据所得） 假设 7

主要参与者 用 例 1.如果客户在今天的截止时间之前使用系统，那么默认的日期是当前日期。否则，默认日期是注意和问题 自助食堂的下一个营业日 2.如果顾客不要求送餐，那么“请求注册付费方式是从工资中扣除”这一前置条件就不适用 3.这一用例的峰值使用负载是当地时间早晨8点到10点 UC-5 注册从工资中扣除餐费的付费方式 Karl Wiegers Chris Zambito 2002年10月21日 2002年10月31日 顾客，薪资核算系统（Payroll System） 使用“自助食堂订餐系统”并要求送餐的自助食堂顾客，必须注册从工资中扣除餐费的付费方用例ID号 用例名称 创建者 最后更新者 创建日期 最后更新日期 参与者 描述 式。 “自助食堂订餐系统”不支持现金购买，自助食堂会向“薪资核算系统”发出付费请求，这将从下次雇员工资中扣除餐费或是在发薪日直接交款 前置条件 后置条件 1.顾客登录到“自助食堂订餐系统” 1.顾客注册从工资中扣除餐费的付费方式 5.0 注册从工资中扣除餐费的付费方式 1.顾客请求注册从工资中扣除餐费的付费方式 2.系统调用“认证用户身份（Authenticate User’ s Identity）” 用例 3.如果顾客符合注册从工资中扣除餐费的付费方式，那么系统请求薪资核算系统 4.薪资核算系统确认顾客具有合法资格 主干过程 5.系统通知顾客他有合法资格选择从工资中扣除餐费的付费方式 6.系统要求顾客确认他期望注册的是从工资中扣除餐费的付费方式 7.顾客确认他期望注册的是从工资中扣除餐费的付费方式 8.系统要求薪资核算系统建立从顾客的工资中扣除餐费。 9.薪资核算系统确认已建立了从工资中扣除餐费 10.系统通知顾客已建立了从工资中扣除餐费.并向顾客提供注册交易的确认号 分支过程 无 5.0.E.1 顾客身份认证失败（第2步） 1 系统再给用户两次机会来纠正身份认证 2a.如果认证成功，则顾客继续进行用例 2b.如果3次尝试都认证失败，则系统通知顾客，将无效的认证尝试记入日志，并终止用例 5.0.E.2 顾客没有资格从工资中扣除餐费（第4步） 1.系统通知顾客他没有资格从工资中扣除餐费，并给出具体理由 2.系统终止用例 5.0.E.3 顾客己经有资格从工资中扣除餐费（第4步） 1.系统通知顾客他已经注册了从工资中扣除餐费的付费方式 2.系统终止用例 异常 包含 优先级 使用频率 业务规则 特别需求

验证用户身份（Authenticate User’s Identity） 高 平均每个雇员一次 BR-86和BR-88决定雇员是否有资格从工资中扣除餐费 1.按照公司制定的中等安全应用程序的标准来执行用户认证 8

主要参与者 假设 注意和问题 用例ID号 用例名称 创建者 最后更新者 创建日期 最后更新日期 参与者 描述 前置条件 后置条件 无 用 例 系统发布之后的最初两星期，预计会相当频繁地执行这一用例 UC-11 修改菜单 Karl Wiegers 2002年10月21日 菜单经理（Menu Manager） 自助食堂菜单经理可修改菜单的有效食物和特定日的价格，以反映有效食物或价格的变更，或者也可以定义当日特色菜 1.菜单已存在于系统中 1.修改的菜单已经保存起来 11.0 编辑已存在的菜单 1.菜单经理请求查看某一特定日期的菜单 2 系统显示菜单 主干过程 3.菜单经理修改菜单以添加新的食物项、删除或变更食物项、创建或变更特色菜、或者变更价格 4.菜单经理请求保存修改过的菜单 5.系统保存修改过的菜单 分支过程 无 11.0.E.1 指定日期的菜单不存在（第1步） 1.系统通知菜单经理这一指定日期的菜单不存在 2.系统询问菜单经理他是否要创建这一指定日期的菜单 3a.菜单经理回答“是” 3b.系统调用“创建菜单”用例 4a.菜单经理回答“否” 4b.系统终止用例 11.0.E.2 指定的日期已过去了（第1步） 1.系统通知菜单经理请求日期的菜单不能修改 2.系统终止用例 异常 包含 优先级 使用频率 业务规则 特别需求 创建菜单 高 每星期每个用户大约使用20次 BR-24 1.菜单经理可以在任何时候取消菜单修改功能。如果菜单已经发生了变更，则系统会请求对取消进行确认 1.对Process Impact公司的每一个工作日都创建一个菜单，包括按照计划雇员要在公司加班的周末和节假日 假设

9

D.3 软件需求规格说明

D.3.1

介绍

1.目标

软件需求规格说明描述了“自助食堂订餐系统（Cafeteria Ordering System，COS）”1.0版本的软件功能性需求和非功能性需求。这一文档计划由实现和验证系统正确功能的项目团队成员来使用。除非在其他地方另有说明，这里指定的所有需求都具有高优先级，而且都要在版本1.0中加以实现。

2.项目范围和产品特性

“自助食堂订餐系统”允许Process Impact公司雇员向公司的自助食堂在线订餐，并送餐到公司内的指定地点。详细的项目描述请参见Cafeteria Ordering System Vision and Scope Document（自助食堂订餐系统前景和范围文档）【1】。文档中这一部分的标题为“初始版本和后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。 3.参考文献

(l) Karl Wiegers FE%W1Cafeterla Ordering System ViSIon and Scope Document, EWli[# www.procesSImpact.com/projects/COS/COS=viSIon-and_scope.doc

(2) Karl Wiegers BT#P9 Process Impact Intranet Development standard HR.# 1.3, E WlitE www.procesSImpact.com/corporate/standards/PI intranet=dev=std.doc (3) Christine Zambito BT#Pi Process Impact BuSIness Rules CataIog, EWil# www.procesSImpact.com/corporate/po1icies/PI-buSIness=ru1es.doc

(4) Christine Zambito BT#P9 Process Impact Internet Application USEr Interface

Standard HR # 2.0 , E Wl tt # www.procesSImpact.com/corporate/standards/ PI=internet=ui=std.doc

D.3.2

总体描述

1.产品远景规划

“自助食堂订餐系统”是一个新系统，它取代了当前在Process Impact公司自助食堂内以手工方式和电话方式预定和选择午餐的过程。图D.1是一幅关联图，它演示了1.0版本的外部实体和系统接口。期望系统演化若干个版本，最终与本地若干饭店的Internet订餐服务相连接，并提供信用卡和借记卡授权服务。

10

图D.1 “自助食堂订膂系统”版本1.0的关联图

2.用户类和用户特性 用户类 顾客（优描述 顾客是俄勒冈州Clackamas的Process Impact公司的雇员，他们希望从公司的自助食堂订餐并能统”4次（来源：根据当前自助食堂的使用数据）。顾客有时会由于团体事件或有来宾而订好多份餐。估计90%的订单是通过公司的内联网而提交的，10%的订单是从家里提交的。所有的顾客都可以从他们的办公室访问公司内联网。 有些顾客希望建立固定的订餐，每天送同样的饭菜，或者是自动送当日特色菜。顾客必须能推翻对某一具体日期的订餐 自助食堂Process Impact公司自助食堂目前雇佣了大约20名“自助食堂工作人员”，他们从“自助食堂订餐堂工作人员需要接受培训.学会如何使用计算机、Web浏览器和“自助食堂订餐系统” 菜单经理 菜单管理人是自助食堂的雇员，也许就是食堂经理，他负责建立并维护自助食堂有效的食物条目日常菜单，和某一天每一个食物条目的有效时间。有些饭菜不适宜于送货上门。菜单管理人也要定义食堂的每日特色菜。菜单经理还需要定期编辑菜单，以反映计划内的无效的或价格发生了变更的食物 送餐人员 当自助食堂工作人员准备订单所要求送的饭菜时，他们打印送餐说明并向送餐人员发出送餐请求，送餐人员是食堂的其他雇员或者是承包人。送餐人员为每餐都要挑选食物和准备送餐说明，并将它送到顾客手里。送餐人员与系统的主要交互将是偶尔重新打印送餐说明并确认餐已送到（或没有送到）顾客手中 先考虑） 送货上门。大约有600名潜在顾客，其中估计有400人预计平均每星期每人使用“自助食堂订餐系工作人员 系统”接受订单，准备饭菜，对要送货上门的饭菜进行打包，打印送餐说明，并请求送餐。自助食 3.运行环境（Operation Environment，OE）

OE-1：“自助食堂订餐系统”的操作将通过如下的Web浏览器来完成：Microsoft Internet Explorer版本5.0和6.0，Netscape Communicator版本4.7和Netscape版本6和版本7。 OE-2：“自助食堂订餐系统”将运行在一个服务器中，该服务器运行当前由公司批准的Red Hat Linux版本和Apache HTTP Server。

OE-3：“自助食堂订餐系统”将允许用户通过公司内联网来访问，如果用户被授权在公司的

11

外部穿过防火墙来访问，那么用户也可以在家里通过Internet来访问该系统。

4.设计和实现的约束条件（constraint） CO-1：系统的设计、编码和维护文档将遵照Process Impact Intranet Development Standard（Process Impact公司内联网开发标准）版本1.3【2】。 CO-2：系统将采用公司标准的当前Oracle数据库引擎。 CO-3：所有HTML代码将遵照HTML4.0标准。 CO-4：所有脚本都用Perl语言来编写。

5.用户文档（User Documentation，UD）

UD-1：系统将提供一个分层的和跨链接的HTML联机帮助系统，它描述并演示了所有系统功能。

UD-2：如果是一个新用户第一次使用该系统，系统可以根据用户的要求，提供一个联机教程，这样用户可以使用静态教程菜单来具体实践一下如何订餐。系统不会将采用这一模板的订餐订单存储到数据库中，也不会将这种订单提交给自助食堂。

6.假设（ASsumption）和依赖（DEpendency）

AS-1：只要是要求员工在岗的每一个公司工作日，自助食堂在早餐、午餐和晚餐时都会营业。

DE-1：“自助食堂订餐系统”的运行依赖于“薪资核算系统”所做出的变更，它接受用“自助食堂订餐系统”订餐的付费请求。

DE-2：“自助食堂订餐系统”的运行依赖于“自助食堂库存系统”所做出的变更，当接受“自助食堂订餐系统”订单后，它更新食物条目的有效性。

D.3.3

系统特性

1.订餐

（1）描述和优先级

自助食堂的顾客其身份得到验证之后，他们就可以订餐，并可以要求送到公司内指定的地点，也可以去食堂内就餐。只要所订餐还没有准备好，顾客就可以取消或改变订单。优先级为高。

（2）刺激/响应序列

刺激：顾客请求订餐，可以是一份或多份。

响应：系统向顾客询问订餐细节、付费方式和送餐说明。 刺激：顾客请求改变订单。

响应：如果订单状态是“已接受”，则系统允许用户编辑以前的订单。 刺激：顾客请求取消订单。

响应：如果订单状态是 “已接受”，则系统取消订单。 （3）功能性需求

Order.Place Order.Place.Register Order.Plaoe.Register.No

登录到“自助食堂订餐系统”的顾客可以通过该系统订餐，订一份或多份都可以 系统将确认订餐的顾客所注朋的付费方式是从工资中扣除餐费的付费方式 如果顾客没有注册从工资中扣除餐费的付费方式，那么系统将为顾窑提12

供一些选择方案，顾客可以现在注册并继续进行订餐，也可以订餐后去食堂月餐（不送餐），或者还可以退出“自助食堂订餐系统” Order.Place.Date Order.Place.Date.Cutoff 系统将提示顾客输入用餐日期（请参见BR-8） 如果订餐日期是当前日期，而订餐时间已过了截止时间，那么系统将通知顾客订餐太晚了，今天己不能订餐了。顾客可以政变订餐日期，或者也可以取消订单 Order.Deliver.SElect Order.Deliver.Location Order.Deliver.Notimes Order.Deliver.Times Order.Menu.Date Order'Menu.Available Order.Units.Food Order,Units.Multiple Order.Units.TooMany Order.Units.Change Order.Confrm.Display 顾客将指定只是订餐或者是还要求送餐 如果订单是要求送餐，雨且送餐日仍有有效的送餐时间，那么顾客将提供一个有效的送餐地点 如果送餐日己没有有效的送餐时间，那么系统将通知顾客。顾客既可以取消订单，也可以选择去食堂就餐 系统将显示订餐日剩余的有效送餐时间。顾客可以从显示的送餐时间中选择一个时间，也可以将订单改为去食堂就餐，或者也可以取消订单 系统将显示指定日期的菜单 当前日期的菜单只显示至少在自助食堂存货的一个供应间中有货的那些食物 系统允许顾客表明他希望订餐的每个菜单条目的份数 系统允许用户订多份同样的餐，但其最大份数只能是订单中的所有菜单条目的有效份数中的最小值 如杲顾客所订的某一菜单项的份数超过了目前自助食堂存货中的数量，那么系统将通知顾客他所能订的食物条目的最大份数 如果食堂存货中的食物不能满足顾客的数量要求，那么顾客可以改变所订的份数，也可以改变所订的同样餐的份数，或者也可以取消订餐 如果顾客表明他不希望再订食物了，那么系统将显示他所订的食物条目，每一食物条目的单价，以及应该支付多少费用，具体计算方法请参见BR-12 Order.Conf1rm.Prompt Order.Conf1rm.Not Order.Conf1rm.More Ordcr.Pay.Method Order.Pay.Deliver Order.Pay.Pickup Order.Pay.Details Order.Pay.Conf1rm Order.pay.Congfirm.Deduct Ordcr.Bg.Confrm.OK Mer.Pay.Con8rm.NG Order.Done Ordcr.Done.Store

系统提示顾客确认订餐的订单 如果顾客不确认订单，那么顾客既可以编辑订单，也可以取消订单 顾客可以通过系统再另外订餐，可以是同一天的，也可以不是同一天的。BR-3和BR-4与在单一订单中订多份餐有关系 当顾客表明他已经完成订餐时，系统会要求用户逸择一种付费方式。 请参见BR-ll 如果顾客选择在食堂就餐，那么系统会让顾客选择付费方式，可以是从工资中扣除，也可以是在就餐时支付现金 系统将显示所订的食物条日、费用、付费方式和送货说明 顾客可以确认订单，也可以请求编辑订单，或者也可以请求取消订单 如果顾客确认订单，并选择了从工资中扣除餐费的付费方式，那么系统将向“薪资核算系统”发出一个付费请求 如果付费请求被接受，那么系统将显示一条消息来确认订单已接受，消息中包括从工资中扣除餐费的事务号 如果付费请求被拒绝，系统将显示一条消息来说明拒绝的理由。顾客可以取消订单，也可以改为现金支付方式，或者是去食堂就餐 当顾客确认了订单时，系统会将下面几步作为一个事务来处理 为该订单分配下一个有效的订单号并存储这一订单，其订单的初始状态13

设置为“已接受” Order,Donc'Inventory Order.Done.Menu Order.Done,Times Order.Done.Patron Order.Done.Cateteria Order.Done.Failure Order.Previous.Period Order.Previous.Reorder 向“自助食堂存货系统”发送一条消息，包括订单中每种食物条目的份数 更新当前订单的订餐日期所对应的菜单，从自助食堂存货中扣除订单中的食物条目数量，以反映所有食物条目的最新状况 更新订餐日期中剩余的有效送餐时间 向顾客发送电子邮件消息，消息包括订单和支付费用的有关信息 向自助食堂工作人员发送电子邮件消息，消息包括订单的有关信息 如果Order.Donc中的任何一步不成功，则系统将回滚事务，通知用户订单不成功，并说明失败的原因 系统允许顾客浏览前6个月的全部订餐。 【优先级为中】 顾客可以重新预订他前6个月所订过的任一餐，只要新订率中的所有食物条目在用餐日的菜单中有效即可。 【优先级为中】 （本范例不提供改变和取消订餐订单的功能性需求）

2.创建、浏览、修改和删除订餐 （该范例不提供细节） 3.注册订餐的付费方式 （该范例不提供细节） 4.请求送餐

（该范例不提供细节）

5.创建、浏览、修改和删除自助食堂菜单 （该范例不提供细节）

D.3.4

外部接口需求

1.用户界面（User Interfaces，UI）

UI-1：“自助食堂订餐系统”的屏幕画面将遵照Process Impact Internet Application User Interface standard（Process Impact公司的Internet应用程序用户界面标准）版本2.0【4】。 UI-2：系统对所显示的每个HTML网页都提供帮助链接，解释如何使用这些网页。

UI-3：Web页面的全部导航和食物条目选择，除了综合使用鼠标和键盘共同完成外，还可以只通过键盘来单独完成。

2.硬件接口

硬件接口还没有确定。

3.软件接口（Software Interfaces，SI） SI-1： 自助食堂存货系统。 SI-1.1：“自助食堂订餐系统”通过程序界面向“自助食堂存货系统”发送所订的食物条目数量。 SI-1.2：“自助食堂订餐系统”将轮询“自助食堂存货系统”，以确定请求的食物是否有效。 SI-1.3：当“自助食堂存货系统”通知“自助食堂订餐系统”某一指定的食物条目已经没货时，“自助食堂订餐系统”会从当日的菜单中将该食物条目删除。

SI-2：“薪资管理系统”。“自助食堂订餐系统”通过程序界面与“薪资管理系统”进行通信，完

14

成下面这些操作：

SI-2.1：允许顾客注册从工资中扣除餐费的付费方式。

SI-2.2：允许顾客取消所注册的从工资中扣除餐费的付费方式。 SI-2.3：检查顾客是否注册了从工资中扣除餐费的付费方式。 SI -2.4：为所购餐提交付费请求。

SI-2.5：退还全部或部分上面的费用，其原因是因为顾客拒绝了所订的餐，或对它不满意，也可能是因为没能按照送餐说明完成送餐任务。

4.通信接口（Communications Interfaces，CI）

CI-1:“自助食堂订餐系统”将向顾客发送电子邮件消息，以确认收到订单、价格和送餐说明。 CI-2：“自助食堂订餐系统”将向顾客发送电子邮件消息，以报告订单接受之后订单中或送餐中存在的问题。

D.3.5

其他非功能性需求

1.性能（PErformance）需求

PE-1：在当地时间早晨8点到10点这一段高峰期间，系统将能适应400个用户，平均每个会话估计持续8分钟。 PE-2：系统生成的所有Web页面，通过速率为40KBps的调制解调器在不超过10秒的时间内可以全部下载下来。

PE-3：用户提交了查询之后，对查询的响应时间不能超过7秒，在此时间内要将查询结果显示在屏幕上。

PE-4：用户向系统提交信息后，系统将在4秒内向用户显示确认消息。

2.防护性需求

防护性需求还没有确定。

3.安全性（SEcurity）需求

SE -1：所有涉及功能信息或个人身份信息的网络事务，都要按照BR-33进行加密操作。 SE-2：除浏览菜单外，用户必须登录到“自助食堂订餐系统”才能完成其他所有操作。 SE-3：顾客的登录受计算机系统访问控制策略的，具体请参照BR-35。

SE-4：自助食堂的工作人员，只有那些授权为菜单经理的成员，才能通过系统创建或编辑菜单，具体请参照BR-24。

SE-5：只有那些被授权可以在家访问公司内联网的用户，才可以在公司以外的地方使用“自助食堂订餐系统”。

SE-6：系统只允许顾客浏览他们自己以前的订单，而不能浏览其他顾客的订单。

4.软件质量属性

Availability（可用性）-1：“自助食堂订餐系统”将对公司内联网的用户可用，拨号用户在当地时间早晨5点到晚上12点99.9%的时间可用，当地时间晚上12点到早晨5点则95%的时间可用。

Robustness（健壮性）-1：如果在订单得到确认或取消之前，用户和系统的连接中断，那么用户应该能通过“自助食堂订餐系统”恢复不完整的订单。

15

D.3.6

附录A 数据字典和数据模型

送餐说明 ＝顾客名字

+顾客电话号码 +用餐日期 +送餐地点 +送餐时间窗口

送餐地点＝*将所订的餐送到哪个大楼和房间*

送餐时间窗口＝*送餐的时间间隔是15分钟；以每一刻钟开始和结束*

雇员ID号＝*订餐雇员在公司中的ID号：是由6个字符数字组成的字符串* 食物条目描述＝*菜单中食物条目的文本描述，最多100个字符*

食物条目价格＝*一份菜单食物条目的税前费用，以美元和美分来计算* 用餐日期＝*送餐或就餐日期；格式为MM/DD/YYYY；如果订单截止日期在当前日期之后，则用餐日期的默认值为当前日期，否则为第二天；用餐日期不可能在当前日期之前*

订单 ＝订单号

+订单日期 +用餐日期

+1:m（所订的食物条目｝ +送货说明

+订单状态

订单号＝*系统为接受的每一个订单分配一个惟一的、顺序的整数；初始值是1*

订单状态＝[未完成｜已接受｜己准备｜送餐期间｜已送餐丨已取消]* 请参看图D.3的状态转换图*

结算餐费 ＝餐费价格

+付费方式

+（从工资中扣除餐费的事务号）

菜单 ＝菜单日期

+1:m｛菜单食物条目｝ +0:1｛特色菜｝

菜单日期＝*某一特定的食物条目菜单有效的日期；格式是MM/DD/YYYY*

菜单食物条目 ＝食物条目描述

+食物条目价格

订单截止日期＝*所有订单必须在此之前提交的那天的具体时间* 订单日期＝*顾客提交订单的日期：格式是MM/DD/YYYY*

所订的食物条目 ＝菜单食物条目

+所订的数量

16

顾客 ＝顾客名字

+雇员D号 +顾客电话号码 +顾客地点 +顾客电子邮件

顾客电子邮件＝*提交订单的雇员的电子邮件地址；由50个字母数字组成* 顾客地点＝*提交订单的雇员所在的大楼和房间号；由50个字母数字组成* 顾客名字＝*提交订单的雇员的名字；由30个字母数字组成*

顾客电话号码＝*提交订单的雇员的电话号码；格式为AAA-EEE-NNNN xXXXX，分别表示区号、电话局号、号码和扩展号码*

所付餐费＝*以美元和美分表示的一个订单的总价格，具体计算按照BR-12* 付费方式＝[从工资中扣除｜现金］*从版本2开始添加其他付费方式*

从工资中扣除餐费的事务号＝*“薪资核算系统”为它所接受的每个从工资中扣除餐费的事务分配一个数字，该数字是由8位数字组成的顺序整数*

订餐数量＝*顾客订的每一个食物条目的份数；默认值为1；最大值为日前的存货数量*

特色菜 ＝特色菜描述

+特色菜价格

*菜单经理可以为每个菜单定义一个或多个特色菜，这些特色菜是以优惠价将某些食物条目组合在一起*

特色菜描述＝*每日特色菜的文本描述：最多为100个字符* 特色菜价格＝*以美元和美分表示的一份特色菜的价钱*

图D.2是“自助食堂订餐系统”1.0版本的部分数据模型，展示了数据字典中描述的实体以及它们之间的关系。

17

图D.2 “自助食堂订餐系统”1.0版本的部分数据模型

D.3.7

附录B分析模型

图D.3是一幅状态转换图，它展示了可能的订单状态和允许的状态变更。

18

图D.3 订单状态的状态转换图

D.4 业务规则

下面是单独业务规则（Business Rule，BR）类别的一个范例：

ID BR-1 BR-2 BR-3 BR-4 BR-8 BR-11 BR-12 规则定义 送餐的时间窗口是15分钟，以每一刻钟开始 送餐必须在当地时间上午10点和下午2点之间完成 一张订单上的所有饭菜必须送到同一个地点 一张订单上的所有饭菜必须采用同一种付费方式来支付费用 订餐必须在用餐日前14天内预 如果是送餐上门的订单，则顾客必须通过从工资中扣除餐费的方式来支付餐费 计算订单价格的方法是每一种食物条目的单价乘以所订的这种食物条目的数量，加上应该交纳的销售税，如果订单是要求送货上门，而送餐地点在免费送餐区域范围之外，则还要再加上送餐费 BR-24 BR-33 BR-35 BR-86 BR-88 只有由自助食堂经理指定为菜单经理的那些自助食堂雇员，才有权创建、修改或删除自助食堂菜单 在网络上传输的信息，如果涉及财务信息或个人身份信息，则要求采用128位的加密 （这里不列出有关受限的计算机系统访问策略的细节） 只有正式员工才能注册从工资中扣除餐费的支付方式来为公司购餐 如果由于其他原因从员工薪资总额中扣除费用，则只有在当前己扣除的费用不超过工资总额40%的情况下，那么他才能注册从工资中扣除在自助食堂订餐的费用 约束 动态 约束 静态 计算 动态 规则类型 事实 约束 约束 约束 约束 约束 静态或 动态 静态 动态 静态 静态 动态 动态 来 源 自助食堂经理 自助食堂经理 自助食堂经理 自助食堂经理 自助食堂经理 自助食堂经理 自助食堂策略：州税收规则(state tax code) 自助食堂策略 约束 约束 约束 静态 静态 静态 公司安全策略 公司安全策略 公司会计部经理 公司会计部经理

19