软件需求文档范例模板(共23页).doc

精选优质文档-倾情为你奉上XXX系统软件需求文档组长成员 年 月 日修改记录版本号变更控制报告编号更改条款及内容更改人审批人更改日期1.0初稿1.1添加数据流图1.2添加业务规则专心-专注-专业目 录该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容：n 前景和范围文档。n 用例列表和若干用例描述。n 部分软件需求规格说明。n 某些分析模型。n 部分数据字典。n 若干业务规则。因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。1 前景和范围文档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）RI-1：“自助食堂雇员联合会（Cafeteria Emp1oyees Union）”可能要求与雇员重新签订合同，以反映新的雇员角色和自助食堂营业时间。（可能性为0.6，影响为3）RI-2：使用该系统的雇员太少，减少了对系统开发和变更自助食堂经营过程的投资回报。（可能性为0.3.影响为9）RI-3：本地饭店可能并不认同减价是雇员使用这一系统的正当理由，这会减低雇员对该系统的满意度，并可能会减少他们对这一系统的使用。（可能性为0.4，影响为3）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：如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一系统进行双向通信。1.3 范围和局限性1.初始版本和后续版本的范围特性版本1版本2版本3FE-1只能从午餐菜单中订标准餐：交货单的费用支付方式只能是从工资中扣除除了午餐订单外，也接受早餐订单和晚餐订单；费用的支付方式可以是信用卡和借记卡FE-2不实现不实现完全实现FE-3如果有时间就实现（具有中等优先级）完全实现FE-4注册的费用支付方式只能是从工资中扣除注册的费用支付方式可以是信用卡和借记卡FE-5送餐地点只能是公司内送餐地点还可以选择在公司外面FE-6完全实现FE-7不实现不实现完全实现FE-8不实现完全实现FE-9完全实现2.局限性（Limitation）和排斥性LI-1：自助食堂的有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单是食堂整个菜单的一个子集。LI-2：“自助食堂订餐系统”只能用于俄勒冈州Clackamas的Process Impact公司总部内的自助食堂。1.4 业务上下文1.涉众概览涉 众主要价值态 度主要兴趣约束条件公司管理层提高员工生产率；节约自助食堂的费用强烈承诺完成版本2.如果有条件尽早完成版本3使用该系统所节约的费用必须超过开发此系统的费用和使用此系统的费用无自助食堂工作人员更高效地利用了工作人员的整个工作时间：提高了客户的满意度担心与联合会的关系，担心食堂有可能会裁员；否则很愿意接受新系统保住工作培训工作人员，掌握使用Internet所必需的技能；必须有送货人员和车辆顾客可以更好地选择食物；节约了时间：更加方便积极支持新系统，但使用系统的次数可能没有期望的次数多，这主要是因为顾客考虑到在自助食堂和饭店就餐具有社会价值使用要简单；送货可靠；食物选择的有效性需要访问公司内联网薪资管理部门得不到什么益处：需要建立从工资中扣除餐费的注册方案不愿意采用该软件系统，但认识到对公司和员工的整体利益，所以能以大局为重尽量减少对当前薪资核算软件所做的变更还没有得到资源来实现薪资软件的变更饭店经理增加了销售额；扩大了销售范园，增加了新客户虽然接受，但比较谨慎尽量少用新技术：关注送餐所需的资源和费用可能没有足够的人手和能力来处理订单；可能需要得到Internet访问权2.项目优先级因素具体干活者约束条件自由度进度计划3/l/03前完成第一版，到5/l/03前完成第二版；在不包括责任人评审的情况下，最多可超过期限3个星期特性安排1.0版本实现的特性必须完全可操作质量必须通过95%的用户验收测试；必须通过全部的安全性测试；所有的安全事务都必须遵守公司的安全标准工作人员项目团队规模包括一名半日工作的项目经理，两名开发人员，和一名半日工作的测试人员；如果有必要，还可以另外再增加半日开发人员和半日测试人员费用在不包括责任人评审的情况下，财政预算最多可超支15%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.顾客表明订餐完成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个月的自助食堂数据所得）注意和问题1.如果客户在今天的截止时间之前使用系统，那么默认的日期是当前日期。否则，默认日期是自助食堂的下一个营业日2.如果顾客不要求送餐，那么“请求注册付费方式是从工资中扣除”这一前置条件就不适用3.这一用例的峰值使用负载是当地时间早晨8点到10点用例ID号UC-5用例名称注册从工资中扣除餐费的付费方式创建者Karl Wiegers最后更新者Chris Zambito创建日期2002年10月21日最后更新日期2002年10月31日参与者顾客，薪资核算系统（Payroll System）描述使用“自助食堂订餐系统”并要求送餐的自助食堂顾客，必须注册从工资中扣除餐费的付费方式。 “自助食堂订餐系统”不支持现金购买，自助食堂会向“薪资核算系统”发出付费请求，这将从下次雇员工资中扣除餐费或是在发薪日直接交款前置条件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 Users Identity）优先级高使用频率平均每个雇员一次业务规则BR-86和BR-88决定雇员是否有资格从工资中扣除餐费特别需求1.按照公司制定的中等安全应用程序的标准来执行用户认证假设无注意和问题系统发布之后的最初两星期，预计会相当频繁地执行这一用例用例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公司的每一个工作日都创建一个菜单，包括按照计划雇员要在公司加班的周末和节假日3 需求规格说明书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# (2) Karl Wiegers BT#P9 Process Impact Intranet Development standard HR.# 1.3, EWlitE www.procesSI intranet=dev=std.doc(3) Christine Zambito BT#Pi Process Impact BuSIness Rules CataIog, EWil#www.procesSI(4) Christine Zambito BT#P9 Process Impact Internet Application USEr InterfaceStandard HR # 2.0 , E Wl tt # www.procesSI PI=internet=ui=std.doc3.2 综合描述1. 产品前景“自助食堂订餐系统”是一个新系统，它取代了当前在Process Impact公司自助食堂内以手工方式和电话方式预定和选择午餐的过程。图1是一幅关联图，它演示了1.0版本的外部实体和系统接口。期望系统演化若干个版本，最终与本地若干饭店的Internet订餐服务相连接，并提供信用卡和借记卡授权服务。图1 “自助食堂订膂系统”版本1.0的关联图2. 产品功能在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能，在描述功能时应该针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能，在陈述本软件产品主要功能的作用领域时，也需要对应陈述本软件产品的非作用领域，以利读者理解本软件产品。为了很好地组织产品功能，使每个读者都容易理解，可以采用列表的方法给出。也可以采用图形方式，将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示，这种表示方法是很有用的。3.用户类和用户特性用户类描述顾客（优先考虑） 顾客是俄勒冈州Clackamas的Process Impact公司的雇员，他们希望从公司的自助食堂订餐并能送货上门。大约有600名潜在顾客，其中估计有400人预计平均每星期每人使用“自助食堂订餐系统”4次（来源：根据当前自助食堂的使用数据）。顾客有时会由于团体事件或有来宾而订好多份餐。估计90%的订单是通过公司的内联网而提交的，10%的订单是从家里提交的。所有的顾客都可以从他们的办公室访问公司内联网。有些顾客希望建立固定的订餐，每天送同样的饭菜，或者是自动送当日特色菜。顾客必须能推翻对某一具体日期的订餐自助食堂工作人员 Process Impact公司自助食堂目前雇佣了大约20名“自助食堂工作人员”，他们从“自助食堂订餐系统”接受订单，准备饭菜，对要送货上门的饭菜进行打包，打印送餐说明，并请求送餐。自助食堂工作人员需要接受培训.学会如何使用计算机、Web浏览器和“自助食堂订餐系统”菜单经理菜单管理人是自助食堂的雇员，也许就是食堂经理，他负责建立并维护自助食堂有效的食物条目日常菜单，和某一天每一个食物条目的有效时间。有些饭菜不适宜于送货上门。菜单管理人也要定义食堂的每日特色菜。菜单经理还需要定期编辑菜单，以反映计划内的无效的或价格发生了变更的食物送餐人员当自助食堂工作人员准备订单所要求送的饭菜时，他们打印送餐说明并向送餐人员发出送餐请求，送餐人员是食堂的其他雇员或者是承包人。送餐人员为每餐都要挑选食物和准备送餐说明，并将它送到顾客手里。送餐人员与系统的主要交互将是偶尔重新打印送餐说明并确认餐已送到（或没有送到）顾客手中4.运行环境（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：“自助食堂订餐系统”将允许用户通过公司内联网来访问，如果用户被授权在公司的外部穿过防火墙来访问，那么用户也可以在家里通过Internet来访问该系统。5.设计和实现的约束条件（constraint）CO-1：系统的设计、编码和维护文档将遵照Process Impact Intranet Development Standard（Process Impact公司内联网开发标准）版本1.3 2。CO-2：系统将采用公司标准的当前Oracle数据库引擎。CO-3：所有HTML代码将遵照HTML4.0标准。CO-4：所有脚本都用Perl语言来编写。6.用户文档（User Documentation，UD）UD-1：系统将提供一个分层的和跨链接的HTML联机帮助系统，它描述并演示了所有系统功能。UD-2：如果是一个新用户第一次使用该系统，系统可以根据用户的要求，提供一个联机教程，这样用户可以使用静态教程菜单来具体实践一下如何订餐。系统不会将采用这一模板的订餐订单存储到数据库中，也不会将这种订单提交给自助食堂。7.假设（ASsumption）和依赖（DEpendency）AS-1：只要是要求员工在岗的每一个公司工作日，自助食堂在早餐、午餐和晚餐时都会营业。DE-1：“自助食堂订餐系统”的运行依赖于“薪资核算系统”所做出的变更，它接受用“自助食堂订餐系统”订餐的付费请求。DE-2：“自助食堂订餐系统”的运行依赖于“自助食堂库存系统”所做出的变更，当接受“自助食堂订餐系统”订单后，它更新食物条目的有效性。3.3 外部接口需求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：“薪资管理系统”。“自助食堂订餐系统”通过程序界面与“薪资管理系统”进行通信，完成下面这些操作：SI-2.1：允许顾客注册从工资中扣除餐费的付费方式。SI-2.2：允许顾客取消所注册的从工资中扣除餐费的付费方式。SI-2.3：检查顾客是否注册了从工资中扣除餐费的付费方式。SI -2.4：为所购餐提交付费请求。SI-2.5：退还全部或部分上面的费用，其原因是因为顾客拒绝了所订的餐，或对它不满意，也可能是因为没能按照送餐说明完成送餐任务。4.通信接口（Communications Interfaces，CI）CI-1:“自助食堂订餐系统”将向顾客发送电子邮件消息，以确认收到订单、价格和送餐说明。CI-2：“自助食堂订餐系统”将向顾客发送电子邮件消息，以报告订单接受之后订单中或送餐中存在的问题。3.4 系统特性需要进行详细的需求记录，详细列出与该系统功能相关的详细功能需求，并且，唯一地标识每一项需求。这是必须提交给用户的软件功能，使得用户可以使用所提供的功能执行服务或者使用所指定的使用实例执行任务。描述软件产品如何响应己知的出错条件、非法输入、非法动作。如果每一项功能需求都能用一项，也只需要用一项测试用例就能进行验证，那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例，或者必须使用多项测试用例才能验证，那么该项功能需求的描述必然存在某些问题。功能需求是根据系统功能，即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容，也可以便用这些元素的组合。总而言之，必须选择一种是读者容易理解预期产品的组织方案。用简短的语句说明功能的名称，例如：“1. 订餐”。按照组织的顺序，逐条阐述系统功能。无论说明的是何种功能，都应该针对该系统功能重复叙述（1）（3）这三个部分。可以通过各种方式来组织这一部分内容，例如采用：使用实例、运行模式、用户类、对象类、功能等级等，也可以采用它们的组合。其最终目的是，让读者容易理解即将开发的软件产品。一般来说，每个使用实例都对应一个系统功能，因而按照使用实例来组织内容比较容易让用户理解。对应一些被共享的独立使用实例，可以定义一些公用系统功能。必须特别注意的是，在综合描述部分“产品的功能”中描述的全部需求，以及它们的规格说明；必须在某个系统功能描述中有所反映，而且不应重复。1.订餐（1）描述和优先级自助食堂的顾客其身份得到验证之后，他们就可以订餐，并可以要求送到公司内指定的地点，也可以去食堂内就餐。只要所订餐还没有准备好，顾客就可以取消或改变订单。优先级为高。（2）刺激/响应序列刺激：顾客请求订餐，可以是一份或多份。响应：系统向顾客询问订餐细节、付费方式和送餐说明。刺激：顾客请求改变订单。响应：如果订单状态是“已接受”，则系统允许用户编辑以前的订单。刺激：顾客请求取消订单。响应：如果订单状态是 “已接受”，则系统取消订单。（3）功能性需求Order.Place登录到“自助食堂订餐系统”的顾客可以通过该系统订餐，订一份或多份都可以Order.Place.Register系统将确认订餐的顾客所注朋的付费方式是从工资中扣除餐费的付费方式Order.Plaoe.Register.No如果顾客没有注册从工资中扣除餐费的付费方式，那么系统将为顾窑提供一些选择方案，顾客可以现在注册并继续进行订餐，也可以订餐后去食堂月餐（不送餐），或者还可以退出“自助食堂订餐系统”Order.Place.Date系统将提示顾客输入用餐日期（请参见BR-8）Order.Place.Date.Cutoff如果订餐日期是当前日期，而订餐时间已过了截止时间，那么系统将通知顾客订餐太晚了，今天己不能订餐了。顾客可以政变订餐日期，或者也可以取消订单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-12Order.Conf1rm.Prompt系统提示顾客确认订餐的订单Order.Conf1rm.Not如果顾客不确认订单，那么顾客既可以编辑订单，也可以取消订单Order.Conf1rm.More顾客可以通过系统再另外订餐，可以是同一天的，也可以不是同一天的。BR-3和BR-4与在单一订单中订多份餐有关系Ordcr.Pay.Method当顾客表明他已经完成订餐时，系统会要求用户逸择一种付费方式。Order.Pay.Deliver请参见BR-llOrder.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为该订单分配下一个有效的订单号并存储这一订单，其订单的初始状态设置为“已接受”Order,Donc'Inventory向“自助食堂存货系统”发送一条消息，包括订单中每种食物条目的份数Order.Done.Menu更新当前订单的订餐日期所对应的菜单，从自助食堂存货中扣除订单中的食物条目数量，以反映所有食物条目的最新状况Order.Done,Times更新订餐日期中剩余的有效送餐时间Order.Done.Patron向顾客发送电子邮件消息，消息包括订单和支付费用的有关信息Order.Done.Cateteria向自助食堂工作人员发送电子邮件消息，消息包括订单的有关信息Order.Done.Failure如果Order.Donc中的任何一步不成功，则系统将回滚事务，通知用户订单不成功，并说明失败的原因Order.Previous.Period系统允许顾客浏览前6个月的全部订餐。 【优先级为中】Order.Previous.Reorder顾客可以重新预订他前6个月所订过的任一餐，只要新订率中的所有食物条目在用餐日的菜单中有效即可。 【优先级为中】（本范例不提供改变和取消订