需求分析文档范例教学用.docx

1、需求分析文档范例教学用软件需求（第2版），清华大学出版社，2004-11-1 【原书名】 Software Requirements,SEcond Edition 原书信息 【原出版社】 Microsoft Press 【作者】 （美）Karl E.Wiegers 【译者】 刘伟琴 刘洪涛 【开本】 185260 【页码】 357 D 需求文档范例 1D.1 前景和范围文档 2D.1.1 业务需求 2D.1.2 解决方案的前景 3D.1.3 范围和局限性 3D.1.4 业务上下文 4D.2 用例 7D.3 软件需求规格说明 11D.3.1 介绍 11D.3.2 总体描述 11D.3.3 系统特

2、性 13D.3.4 外部接口需求 16D.3.5 其他非功能性需求 16D.3.6 附录A 数据字典和数据模型 17D.3.7 附录B分析模型 19D.4 业务规则 20D 需求文档范例该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容： 前景和范围文档。 用例列表和若干用例描述。 部分软件需求规格说明。 某些分析模型。 部分数据字典。 若干业务规则。因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，

3、并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。D.1 前景和范围文档D.1.1 业务需求1.背景、业务机会和客户需要目前，Process I

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

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

6、ccess 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个月内，每个雇员每天的平

7、均有效工作时间增加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.影响

8、为9）RI-3：本地饭店可能并不认同减价是雇员使用这一系统的正当理由，这会减低雇员对该系统的满意度，并可能会减少他们对这一系统的使用。（可能性为0.4，影响为3）D.1.2 解决方案的前景1.前景陈述对那些希望通过公司自助食堂或本地饭店在线订餐的员工来说，“自助食堂订餐系统”是一个基于Internet的应用程序，它可以接受个人订餐或团体订餐，结算用餐费用，并触发将预订餐送到Process Impact公司内的指定位置。与当前的电话订餐和人工订餐不同，使用“自助食堂订餐系统”的雇员并不需要到食堂内去用餐，这既可以节约他们的时间，又可以增加他们对食物的选择范围。2.主要特性（FEature）FE-

9、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

10、：最多比请求的送货时间晚15分钟，自助食堂有送货人员和送货车辆，这样就能满足所有订单的送货要求。DE-1：如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一系统进行双向通信。D.1.3 范围和局限性1.初始版本和后续版本的范围特性版本1版本2版本3FE-1只能从午餐菜单中订标准餐：交货单的费用支付方式只能是从工资中扣除除了午餐订单外，也接受早餐订单和晚餐订单；费用的支付方式可以是信用卡和借记卡FE-2不实现不实现完全实现FE-3如果有时间就实现（具有中等优先级）完全实现FE-4注册的费用支付方式只能是从工资中扣除注册的费用支付方式可以是信用卡和借记卡FE-5送餐地点只能是公司

11、内送餐地点还可以选择在公司外面FE-6完全实现FE-7不实现不实现完全实现FE-8不实现完全实现FE-9完全实现2.局限性（Limitation）和排斥性LI-1：自助食堂的有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单是食堂整个菜单的一个子集。LI-2：“自助食堂订餐系统”只能用于俄勒冈州Clackamas的Process Impact公司总部内的自助食堂。D.1.4 业务上下文1.涉众概览涉 众主要价值态 度主要兴趣约束条件公司管理层提高员工生产率；节约自助食堂的费用强烈承诺完成版本2.如果有条件尽早完成版本3使用该系统所节约的费用必须超过开发此系统的费用和使用此系统的费用

12、无自助食堂工作人员更高效地利用了工作人员的整个工作时间：提高了客户的满意度担心与联合会的关系，担心食堂有可能会裁员；否则很愿意接受新系统保住工作培训工作人员，掌握使用Internet所必需的技能；必须有送货人员和车辆顾客可以更好地选择食物；节约了时间：更加方便积极支持新系统，但使用系统的次数可能没有期望的次数多，这主要是因为顾客考虑到在自助食堂和饭店就餐具有社会价值使用要简单；送货可靠；食物选择的有效性需要访问公司内联网薪资管理部门得不到什么益处：需要建立从工资中扣除餐费的注册方案不愿意采用该软件系统，但认识到对公司和员工的整体利益，所以能以大局为重尽量减少对当前薪资核算软件所做的变更还没有得

13、到资源来实现薪资软件的变更饭店经理增加了销售额；扩大了销售范园，增加了新客户虽然接受，但比较谨慎尽量少用新技术：关注送餐所需的资源和费用可能没有足够的人手和能力来处理订单；可能需要得到Internet访问权2.项目优先级因素具体干活者约束条件自由度进度计划3/l/03前完成第一版，到5/l/03前完成第二版；在不包括责任人评审的情况下，最多可超过期限3个星期特性安排1.0版本实现的特性必须完全可操作质量必须通过95%的用户验收测试；必须通过全部的安全性测试；所有的安全事务都必须遵守公司的安全标准工作人员项目团队规模包括一名半日工作的项目经理，两名开发人员，和一名半日工作的测试人员；如果有必要，

14、还可以另外再增加半日开发人员和半日测试人员费用在不包括责任人评审的情况下，财政预算最多可超支15%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 W

15、iegerss最后更新者Jack McGillicutty创建日期2002年10月21日最后更新日期2002年11月7日参与者顾客描述顾客从公司内联网或从家里访问“自助食堂订餐系统”，随意查看某一天的菜单，选择自己想要的食物，提交订单并要求在特定的时间窗口（15分钟）内送货到指定的地点前置条件1.顾客登录到“自助食堂订餐系统” 2.顾客注册的付费方式是从工资中扣除后置条件1.订单在“自助食堂订餐系统”中的存储状态是“已接受”2.根据这一订单的食物条目来更新食物存货3.根据这一次的送货请求，对请求的时间窗口更新剩余的送货能力主干过程1.0 订一份餐1.顾客要求查看某一天的菜单2.系统显示有效食物

16、菜单和当日特色菜3.顾客从菜单中选择一种或多种食物4.顾客表明订餐完成5.系统显示所订菜单条目、单价和总价格，包括应交纳的税和送货费用6.顾客确认订餐订单或请求修改订餐订单（回到第3步）7.系统显示那一天中有效的送餐时间8.顾客选择送餐时间和指定送餐地点9.顾客指定付费方式10.系统确认接收订单11.系统向顾客发送电子邮件，确认订单细节、价格和送餐说明12.系统将订单存储在数据库中，并发送电子邮件通知自助食堂工作人员，将食物信息发送给自助食堂库存系统，并更新有效的送餐时间分支过程1.1 订多份餐（第4步之后分支出来）1.顾客要求预订另一份餐2.返回到第2步1.2 同样的餐订多份（第3步之后分支

17、出来）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.系统通知顾客它所能提供的同样食物曲多份餐

18、的最大数量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.如果顾客不要

19、求送餐，那么“请求注册付费方式是从工资中扣除”这一前置条件就不适用3.这一用例的峰值使用负载是当地时间早晨8点到10点用例ID号UC-5用例名称注册从工资中扣除餐费的付费方式创建者Karl Wiegers最后更新者Chris Zambito创建日期2002年10月21日最后更新日期2002年10月31日参与者顾客，薪资核算系统（Payroll System）描述使用“自助食堂订餐系统”并要求送餐的自助食堂顾客，必须注册从工资中扣除餐费的付费方式。 “自助食堂订餐系统”不支持现金购买，自助食堂会向“薪资核算系统”发出付费请求，这将从下次雇员工资中扣除餐费或是在发薪日直接交款前置条件1.顾客登录到

20、“自助食堂订餐系统”后置条件1.顾客注册从工资中扣除餐费的付费方式主干过程5.0 注册从工资中扣除餐费的付费方式1.顾客请求注册从工资中扣除餐费的付费方式2.系统调用“认证用户身份（Authenticate User s Identity）” 用例3.如果顾客符合注册从工资中扣除餐费的付费方式，那么系统请求薪资核算系统4.薪资核算系统确认顾客具有合法资格5.系统通知顾客他有合法资格选择从工资中扣除餐费的付费方式6.系统要求顾客确认他期望注册的是从工资中扣除餐费的付费方式7.顾客确认他期望注册的是从工资中扣除餐费的付费方式8.系统要求薪资核算系统建立从顾客的工资中扣除餐费。9.薪资核算系统确认已

21、建立了从工资中扣除餐费10.系统通知顾客已建立了从工资中扣除餐费.并向顾客提供注册交易的确认号分支过程无异常5.0.E.1 顾客身份认证失败（第2步）1 系统再给用户两次机会来纠正身份认证2a.如果认证成功，则顾客继续进行用例2b.如果3次尝试都认证失败，则系统通知顾客，将无效的认证尝试记入日志，并终止用例5.0.E.2 顾客没有资格从工资中扣除餐费（第4步）1.系统通知顾客他没有资格从工资中扣除餐费，并给出具体理由2.系统终止用例5.0.E.3 顾客己经有资格从工资中扣除餐费（第4步）1.系统通知顾客他已经注册了从工资中扣除餐费的付费方式2.系统终止用例包含验证用户身份（Authentica

22、te Users Identity）优先级高使用频率平均每个雇员一次业务规则BR-86和BR-88决定雇员是否有资格从工资中扣除餐费特别需求1.按照公司制定的中等安全应用程序的标准来执行用户认证假设无注意和问题系统发布之后的最初两星期，预计会相当频繁地执行这一用例用例ID号UC-11用例名称修改菜单创建者Karl Wiegers最后更新者创建日期2002年10月21日最后更新日期参与者菜单经理（Menu Manager）描述自助食堂菜单经理可修改菜单的有效食物和特定日的价格，以反映有效食物或价格的变更，或者也可以定义当日特色菜前置条件1.菜单已存在于系统中后置条件1.修改的菜单已经保存起来主干

23、过程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.系统终止用例包含创建菜单优先级

24、高使用频率每星期每个用户大约使用20次业务规则BR-24特别需求1.菜单经理可以在任何时候取消菜单修改功能。如果菜单已经发生了变更，则系统会请求对取消进行确认假设1.对Process Impact公司的每一个工作日都创建一个菜单，包括按照计划雇员要在公司加班的周末和节假日D.3 软件需求规格说明D.3.1 介绍1.目标软件需求规格说明描述了“自助食堂订餐系统（Cafeteria Ordering System，COS）”1.0版本的软件功能性需求和非功能性需求。这一文档计划由实现和验证系统正确功能的项目团队成员来使用。除非在其他地方另有说明，这里指定的所有需求都具有高优先级，而且都要在版本1.

25、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.p

26、rocesSI(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 #

27、 2.0 , E Wl tt # www.procesSI PI=internet=ui=std.docD.3.2 总体描述1.产品远景规划“自助食堂订餐系统”是一个新系统，它取代了当前在Process Impact公司自助食堂内以手工方式和电话方式预定和选择午餐的过程。图D.1是一幅关联图，它演示了1.0版本的外部实体和系统接口。期望系统演化若干个版本，最终与本地若干饭店的Internet订餐服务相连接，并提供信用卡和借记卡授权服务。图D.1 “自助食堂订膂系统”版本1.0的关联图2.用户类和用户特性用户类描述顾客（优先考虑） 顾客是俄勒冈州Clackamas的Process Impact公

28、司的雇员，他们希望从公司的自助食堂订餐并能送货上门。大约有600名潜在顾客，其中估计有400人预计平均每星期每人使用“自助食堂订餐系统”4次（来源：根据当前自助食堂的使用数据）。顾客有时会由于团体事件或有来宾而订好多份餐。估计90%的订单是通过公司的内联网而提交的，10%的订单是从家里提交的。所有的顾客都可以从他们的办公室访问公司内联网。有些顾客希望建立固定的订餐，每天送同样的饭菜，或者是自动送当日特色菜。顾客必须能推翻对某一具体日期的订餐自助食堂工作人员 Process Impact公司自助食堂目前雇佣了大约20名“自助食堂工作人员”，他们从“自助食堂订餐系统”接受订单，准备饭菜，对要送货上

29、门的饭菜进行打包，打印送餐说明，并请求送餐。自助食堂工作人员需要接受培训.学会如何使用计算机、Web浏览器和“自助食堂订餐系统”菜单经理菜单管理人是自助食堂的雇员，也许就是食堂经理，他负责建立并维护自助食堂有效的食物条目日常菜单，和某一天每一个食物条目的有效时间。有些饭菜不适宜于送货上门。菜单管理人也要定义食堂的每日特色菜。菜单经理还需要定期编辑菜单，以反映计划内的无效的或价格发生了变更的食物送餐人员当自助食堂工作人员准备订单所要求送的饭菜时，他们打印送餐说明并向送餐人员发出送餐请求，送餐人员是食堂的其他雇员或者是承包人。送餐人员为每餐都要挑选食物和准备送餐说明，并将它送到顾客手里。送餐人员与系统的主要交互将是偶尔重新打印送餐说明并确认餐已送到（或没有送到）顾客手中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