软件需求文档范例模板.docx
《软件需求文档范例模板.docx》由会员分享，可在线阅读，更多相关《软件需求文档范例模板.docx（35页珍藏版）》请在冰豆网上搜索。
软件需求文档范例模板
XXX系统
软件需求文档
组长
成员
年月日
修改记录
版本号
变更控制报告编号
更改条款及内容
更改人
审批人
更改日期
1.0
初稿
1.1
添加数据流图
1.2
添加业务规则
该附录通过“自助食堂订餐系统（CafeteriaOrderingSystem，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。
这里包括如下这些内容：
⏹前景和范围文档。
⏹用例列表和若干用例描述。
⏹部分软件需求规格说明。
⏹某些分析模型。
⏹部分数据字典。
⏹若干业务规则。
因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。
我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。
在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。
这些文档中的信息能够以多种其他合理的方式来组织。
基本的目标是确保需求文档清晰明了、完整和易使用。
这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。
有时，会将几个部分合并起来，这是为了避免信息重复。
每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。
1前景和范围文档
1.1业务需求
1.背景、业务机会和客户需要
目前，ProcessImpact公司的大多数员工平均每天要花费60分钟去自助食堂选择、购买并用午餐，其中大约有20分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午餐、以及以现金方式或以信用卡方式结算餐费上。
当员工出去用午餐时，他们平均有90分钟时间不在岗。
有些员工提前给自助食堂打电话预订午餐，请自助食堂准备好他们所选择的午餐。
但是，员工并不是总能如愿以偿，因为自助食堂有些食物己卖完，而与此同时，自助食堂又不可避免地会浪费大量的食物，因为有些食物没有卖出去而只好倒掉。
早餐和晚餐同样面临着这样的问题，只是到自助食堂用餐的员工人数比午餐要少得多。
许多员工都通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的日期和时间内将所订的午餐送到公司的指定地点。
通过这样一个系统，使用这一服务的员工可以节约相当可观的时间，而且订到自己所喜欢的食物的机会也增大了。
这既提高了他们的工作生活质量，也提高了他们的生产率。
自助食堂提前了解到客户需要哪些食物，就可以减少浪费，并提高自助食堂员工的工作效率。
要求送货上门的订餐员工将来还可以从本地的饭店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店的大量购餐协议而有可能节约费用。
ProcessImpact公司也可以只在自助食堂订午餐，而在饭店订早餐、晚餐、特定事件的用餐以及周末会餐。
2.业务目标（BusinessObjective，BO）和成功标准（SuccessCriteria，SC）
BO-1：
初始版本发布之后的6个月内，自助食堂的食物浪费减少50%。
度量单位（scale）：
自助食堂的工作人员每星期所倒掉的食物的价值。
计量（meter）：
检查“自助食堂存货系统（CafeteriaInventorySystem）”的日志。
过去情况（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：
“自助食堂雇员联合会（CafeteriaEmp1oyeesUnion）”可能要求与雇员重新签订合同，以反映新的雇员角色和自助食堂营业时间。
（可能性为0.6，影响为3）
RI-2：
使用该系统的雇员太少，减少了对系统开发和变更自助食堂经营过程的投资回报。
（可能性为0.3.影响为9）
RI-3：
本地饭店可能并不认同减价是雇员使用这一系统的正当理由，这会减低雇员对该系统的满意度，并可能会减少他们对这一系统的使用。
（可能性为0.4，影响为3）
1.2解决方案的前景
1.前景陈述
对那些希望通过公司自助食堂或本地饭店在线订餐的员工来说，“自助食堂订餐系统”是一个基于Internet的应用程序，它可以接受个人订餐或团体订餐，结算用餐费用，并触发将预订餐送到ProcessImpact公司内的指定位置。
与当前的电话订餐和人工订餐不同，使用“自助食堂订餐系统”的雇员并不需要到食堂内去用餐，这既可以节约他们的时间，又可以增加他们对食物的选择范围。
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
版本3
FE-1
只能从午餐菜单中订标准餐：
交货单的费用支付方式只能是从工资中扣除
除了午餐订单外，也接受早餐订单和晚餐订单；费用的支付方式可以是信用卡和借记卡
FE-2
不实现
不实现
完全实现
FE-3
如果有时间就实现（具有中等优先级）
完全实现
FE-4
注册的费用支付方式只能是从工资中扣除
注册的费用支付方式可以是信用卡和借记卡
FE-5
送餐地点只能是公司内
送餐地点还可以选择在公司外面
FE-6
完全实现
FE-7
不实现
不实现
完全实现
FE-8
不实现
完全实现
FE-9
完全实现
2.局限性（Limitation）和排斥性
LI-1：
自助食堂的有些食物不适宜于送货，因此“自助食堂订餐系统”的顾客所用的菜单是食堂整个菜单的一个子集。
LI-2：
“自助食堂订餐系统”只能用于俄勒冈州Clackamas的ProcessImpact公司总部内的自助食堂。
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
用例名称
订餐
创建者
KarlWiegerss
最后更新者
JackMcGillicutty
创建日期
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
用例名称
注册从工资中扣除餐费的付费方式
创建者
KarlWiegers
最后更新者
ChrisZambito
创建日期
2002年10月21日
最后更新日期
2002年10月31日
参与者
顾客，薪资核算系统（PayrollSystem）
描述
使用“自助食堂订餐系统”并要求送餐的自助食堂顾客，必须注册从工资中扣除餐费的付费方式。
“自助食堂订餐系统”不支持现金购买，自助食堂会向“薪资核算系统”发出付费请求，这将从下次雇员工资中扣除餐费或是在发薪日直接交款
前置条件
1.顾客登录到“自助食堂订餐系统”
后置条件
1.顾客注册从工资中扣除餐费的付费方式
主干过程
5.0注册从工资中扣除餐费的付费方式
1.顾客请求注册从工资中扣除餐费的付费方式
2.系统调用“认证用户身份（AuthenticateUser’sIdentity）”用例
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.系统终止用例
包含
验证用户身份（AuthenticateUser’sIdentity）
优先级
高
使用频率
平均每个雇员一次
业务规则
BR-86和BR-88决定雇员是否有资格从工资中扣除餐费
特别需求
1.按照公司制定的中等安全应用程序的标准来执行用户认证
假设
无
注意和问题
系统发布之后的最初两星期，预计会相当频繁地执行这一用例
用例ID号
UC-11
用例名称
修改菜单
创建者
KarlWiegers
最后更新者
创建日期
2002年10月21日
最后更新日期
参与者
菜单经理（MenuManager）
描述
自助食堂菜单经理可修改菜单的有效食物和特定日的价格，以反映有效食物或价格的变更，或者也可以定义当日特色菜
前置条件
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.对ProcessImpact公司的每一个工作日都创建一个菜单，包括按照计划雇员要在公司加班的周末和节假日
3需求规格说明书
3.1引言
1.目标
软件需求规格说明描述了“自助食堂订餐系统（CafeteriaOrderingSystem，COS）”1.0版本的软件功能性需求和非功能性需求。
这一文档计划由实现和验证系统正确功能的项目团队成员来使用。
除非在其他地方另有说明，这里指定的所有需求都具有高优先级，而且都要在版本1.0中加以实现。
2.项目范围和产品特性
“自助食堂订餐系统”允许ProcessImpact公司雇员向公司的自助食堂在线订餐，并送餐到公司内的指定地点。
详细的项目描述请参见CafeteriaOrderingSystemVisionandScopeDocument（自助食堂订餐系统前景和范围文档）[1]。
文档中这一部分的标题为“初始版本和后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。
3.参考文献
（l）KarlWiegersFE%W1CafeterlaOrderingSystemViSIonandScopeDocument,EWli[#www.procesSI
（2）KarlWiegersBT#P9ProcessImpactIntranetDevelopmentstandardHR.#1.3,E
WlitEwww.procesSIintranet=dev=std.doc
（3）ChristineZambitoBT#PiProcessImpactBuSInessRulesCataIog,EWil#
www.procesSI
（4）ChristineZambitoBT#P9ProcessImpactInternetApplicationUSErInterface
StandardHR#2.0,EWltt#www.procesSIPI=internet=ui=std.doc
3.2综合描述
1.产品前景
“自助食堂订餐系统”是一个新系统，它取代了当前在ProcessImpact公司自助食堂内以手工方式和电话方式预定和选择午餐的过程。
图1是一幅关联图，它演示了1.0版本的外部实体和系统接口。
期望系统演化若干个版本，最终与本地若干饭店的Internet订餐服务相连接，并提供信用卡和借记卡授权服务。
图1“自助食堂订膂系统”版本1.0的关联图
2.产品功能
在此只需要概略地总结。
仅从业务层面陈述本软件产品所应具有的主要功能，在描述功能时应该针对每一项需求准确地描述其各项规格说明。
如果存在引起误解的可能，在陈述本软件产品主要功能的作用领域时，也需要对应陈述本软件产品的非作用领域，以利读者理解本软件产品。
为了很好地组织产品功能，使每个读者都容易理解，可以采用列表的方法给出。
也可以采用图形方式，将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示，这种表示方法是很有用的。
3.用户类和用户特性
用户类
描述
顾客（优先考虑）
顾客是俄勒冈州Clackamas的ProcessImpact公司的雇员，他们希望从公司的自助食堂订餐并能送货上门。
大约有600名潜在顾客，其中估计有400人预计平均每星期每人使用“自助食堂订餐系统”4次（来源：
根据当前自助食堂的使用数据）。
顾客有时会由于团体事件或有来宾而订好多份餐。
估计90%的订单是通过公司的内联网而提交的，10%的订单是从家里提交的。
所有的顾客都可以从他们的办公室访问公司内联网。
有些顾客希望建立固定的订餐，每天送同样的饭菜，或者是自动送当日特色菜。
顾客必须能推翻对某一具体日期的订餐
自助食堂工作人员
ProcessImpact公司自助食堂目前雇佣了大约20名“自助食堂工作人员”，他们从“自助食堂订餐系统”接受订单，准备饭菜，对要送货上门的饭菜进行打包，打印送餐说明，并请求送餐。
自助食堂工作人员需要接受培训.学会如何使用计算机、Web浏览器和“自助食堂订餐系统”
菜单经理
菜单管理人是自助食堂的雇员，也许就是食堂经理，他负责建立并维护自助食堂有效的食物条目日常菜单，和某一天每一个食物条目的有效时间。
有些饭菜不适宜于送货上门。
菜单管理人也要定义食堂的每日特色菜。
菜单经理还需要定期编辑菜单，以反映计划内的无效的或价格发生了变更的食物
送餐人员
当自助食堂工作人员准备订单所要求送的饭菜时，他们打印送餐说明并向送餐人员发出送餐请求，送餐人员是食堂的其他雇员或者是承包人。
送餐人员为每餐都要挑选食物和准备送餐说明，并将它送到顾客手里。
送餐人员与系统的主要交互将是偶尔重新打印送餐说明并确认餐已送到（或没有送到）顾客手中
4.运行环境（OperationEnvironment，OE）
OE-1：
“自助食堂订餐系统”的操作将通过如下的Web浏览器来完成：
MicrosoftInternetExplorer版本5.0和6.0，Netsc
升级会员 