软件需求文档范例模板
组长成员XXX系统
软件需求文档年月日
修改记录
版本号变更控制报告编号更改条款及内容更改人审批人更改日期
1.0 初稿
1.1 添加数据流图
1.2 添加业务规则
目录
1前景和范围文档 (4)
1.1业务需求 (4)
1.2解决方案的前景 (5)
1.3范围和局限性 (6)
1.4业务上下文 (6)
2用例描述文档 (9)
3需求规格说明书 (13)
3.1引言 (13)
3.2综合描述 (13)
3.3外部接口需求 (15)
3.4系统特性 (16)
3.5其他非功能性需求 (19)
3.6其他需求 (20)
附录A 词汇表 (20)
附录B 分析模型 (22)
附录C 待确定问题的列表 (23)
该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容：
?前景和范围文档。
?用例列表和若干用例描述。
?部分软件需求规格说明。
?某些分析模型。
?部分数据字典。
?若干业务规则。
因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。
这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。
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 版本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的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 Use r’ 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 Use r’s 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[# https://www.wendangku.net/doc/026547135.html,/projects/COS/COS=viSIon-and_scope.doc
(2) Karl Wiegers BT#P9 Process Impact Intranet Development standard HR.# 1.3, E WlitE https://www.wendangku.net/doc/026547135.html,/corporate/standards/PI intranet=dev=std.doc
(3) Christine Zambito BT#Pi Process Impact BuSIness Rules CataIog, EWil#
https://www.wendangku.net/doc/026547135.html,/corporate/po1icies/PI-buSIness=ru1es.doc
(4) Christine Zambito BT#P9 Process Impact Internet Application USEr Interface Standard HR # 2.0 , E Wl tt # https://www.wendangku.net/doc/026547135.html,/corporate/standards/ PI=internet=ui=std.doc
3.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-12
Order.Conf1rm.Prompt 系统提示顾客确认订餐的订单
Order.Conf1rm.Not 如果顾客不确认订单，那么顾客既可以编辑订单，也可以取消订单Order.Conf1rm.More 顾客可以通过系统再另外订餐，可以是同一天的，也可以不是同一天的。
BR-3和BR-4与在单一订单中订多份餐有关系
Ordcr.Pay.Method 当顾客表明他已经完成订餐时，系统会要求用户逸择一种付费方式。Order.Pay.Deliver 请参见BR-ll
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 为该订单分配下一个有效的订单号并存储这一订单，其订单的初始状态
设置为“已接受”
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个月所订过的任一餐，只要新订率中的所有食
物条目在用餐日的菜单中有效即可。【优先级为中】
（本范例不提供改变和取消订餐订单的功能性需求）
2.创建、浏览、修改和删除订餐
（该范例不提供细节）
3.注册订餐的付费方式
（该范例不提供细节）
4.请求送餐
（该范例不提供细节）
5.创建、浏览、修改和删除自助食堂菜单
（该范例不提供细节）
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：如果在订单得到确认或取消之前，用户和系统的连接中断，那么用户应该能通过“自助食堂订餐系统”恢复不完整的订单。
5 业务规则
下面是单独业务规则（Business Rule，BR）类别的一个范例：
ID 规则定义规则类型静态或
动态
来源
BR-1 送餐的时间窗口是15分钟，以每一刻钟开始事实静态自助食堂经理BR-2 送餐必须在当地时间上午10点和下午2点之间完成约束动态自助食堂经理BR-3 一张订单上的所有饭菜必须送到同一个地点约束静态自助食堂经理BR-4 一张订单上的所有饭菜必须采用同一种付费方式来支付费用约束静态自助食堂经理BR-8 订餐必须在用餐日前14天内预约束动态自助食堂经理
BR-11 如果是送餐上门的订单，则顾客必须通过从工资中扣除餐费的方式来支付餐费约束动态
自助食堂经理
BR-12 计算订单价格的方法是每一种食物条目的单价乘以所订的这种食物条
目的数量，加上应该交纳的销售税，如果订单是要求送货上门，而送餐地点在免费送餐区域范围之外，则还要再加上送餐费计算动态
自助食堂策略：
州税收规则
(state tax code)
ID 规则定义规则类型静态或
动态
来源
BR-24 只有由自助食堂经理指定为菜单经理的那些自助食堂雇员，才有权创建、修改或删除自助食堂菜单约束静态
自助食堂策略
BR-33 在网络上传输的信息，如果涉及财务信息或个人身份信息，则要求采用128位的加密约束静态
公司安全策略
BR-35 （这里不列出有关受限的计算机系统访问策略的细节）约束静态公司安全策略BR-86 只有正式员工才能注册从工资中扣除餐费的支付方式来为公司购餐约束静态公司会计部经理BR-88 如果由于其他原因从员工薪资总额中扣除费用，则只有在当前己扣除
的费用不超过工资总额40%的情况下，那么他才能注册从工资中扣除在自助食堂订餐的费用约束动态
公司会计部经理
3.6其他需求
附录A 词汇表
包括数据字典和数据模型等。
送餐说明＝顾客名字
+顾客电话号码
+用餐日期
+送餐地点
+送餐时间窗口
送餐地点＝*将所订的餐送到哪个大楼和房间*
送餐时间窗口＝*送餐的时间间隔是15分钟；以每一刻钟开始和结束*
雇员ID号＝*订餐雇员在公司中的ID号：是由6个字符数字组成的字符串*
食物条目描述＝*菜单中食物条目的文本描述，最多100个字符*
食物条目价格＝*一份菜单食物条目的税前费用，以美元和美分来计算*
用餐日期＝*送餐或就餐日期；格式为MM/DD/YYYY；如果订单截止日期在当前日期之后，则用餐日期的默认值为当前日期，否则为第二天；用餐日期不可能在当前日期之前*
订单＝订单号
+订单日期
+用餐日期
+1:m（所订的食物条目｝
+送货说明
+订单状态
订单号＝*系统为接受的每一个订单分配一个惟一的、顺序的整数；初始值是1*
订单状态＝[未完成｜已接受｜己准备｜送餐期间｜已送餐丨已取消]* 请参看图D.3的状态转换图*
软件开发案例分析需求模板汇总
E-Storage Management System Software Requirements Specification 电子化仓储管理系统软件需求规格说明书 版权所有不得复制 Copyright ? BroadenGate Technologies, Co., Ltd. All Rights Reserved
Revision Record 修订记录
Catalog 目录
错误!未找到引用源。 Keywords 关键词：仓储管理 Abstract 摘要：本文主要描述电子化仓储管理系统的设计需求，包括功能需求和性能需求，以及其他设计约束等。 List of abbreviations 缩略语清单：
1Introduction 简介 1.1Purpose 目的 1.2Scope 范围 本文档包含电子化仓储管理系统V1.0的对外接口和功能描述，以及和外部的约束关系。2General description 总体概述 2.1Software perspective 软件概述 2.1.1About the Project 项目介绍 2.1.2Environment of Pruduct 产品环境介绍 2.2User characteristics 用户特征 2.3Software function 软件功能 2.4Assumptions & Dependencies 假设和依赖关系 3Specific Requirements 具体需求
3.1Functional Requirements 功能需求 我们采用面向对象分析的方法来作为主要的系统建模方法，使用UML(Unified Modeling Language)作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。 Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成时，该模型将来可 派生出动态对象模型。 设计Use-case时，我们遵循下列步骤： 第一步： 识别出系统的管理员。管理员可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者是谁。尽可能地确保所有管理员都被完全识别出来。 第二步： 描述主要的Use Case。可以采取不断地问自己“这个管理员究竟想通过系统做什么？”来准确地描述Use Case。 第三步： 重新审视每个Use Case，为它们下了详尽的定义。 电子化仓库管理系统是通过对入库业务、出库业务、仓库调拨、库存调整业务信息的管理，提高仓库管理信息的实时性和准确性，达到即时库存管理的功能，并有效控制并跟踪业务的物流和成本管理全过程，实现完善的企业仓储信息管理。系统中设计了装箱算法，为客户提供合理有效的装箱方案，保证了货物集装箱的利用。本系统可以提供有关库存情况的准确信息，增强了作业的准确性和快捷性、减少了整个物流中由于商品误置、送错、偷窃、损害和库存、出货错误等造成的损耗，并最大限度减少存储成本。 总体功能时序图：（如图3-1所示）
软件需求文档范例模板
组长成员XXX系统 软件需求文档年月日
修改记录 版本号变更控制报告编号更改条款及内容更改人审批人更改日期 1.0 初稿 1.1 添加数据流图 1.2 添加业务规则
目录 1前景和范围文档 (4) 1.1业务需求 (4) 1.2解决方案的前景 (5) 1.3范围和局限性 (6) 1.4业务上下文 (6) 2用例描述文档 (9) 3需求规格说明书 (13) 3.1引言 (13) 3.2综合描述 (13) 3.3外部接口需求 (15) 3.4系统特性 (16) 3.5其他非功能性需求 (19) 3.6其他需求 (20) 附录A 词汇表 (20) 附录B 分析模型 (22) 附录C 待确定问题的列表 (23)
该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容： ?前景和范围文档。 ?用例列表和若干用例描述。 ?部分软件需求规格说明。 ?某些分析模型。 ?部分数据字典。 ?若干业务规则。 因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。 这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。 1前景和范围文档 1.1业务需求 1.背景、业务机会和客户需要 目前，Process Impact公司的大多数员工平均每天要花费60分钟去自助食堂选择、购买并用午餐，其中大约有20分钟要花在公司和自助食堂之间的往返路程、选择自己喜欢的午餐、以及以现金方式或以信用卡方式结算餐费上。当员工出去用午餐时，他们平均有90分钟时间不在岗。有些员工提前给自助食堂打电话预订午餐，请自助食堂准备好他们所选择的午餐。但是，员工并不是总能如愿以偿，因为自助食堂有些食物己卖完，而与此同时，自助食堂又不可避免地会浪费大量的食物，因为有些食物没有卖出去而只好倒掉。早餐和晚餐同样面临着这样的问题，只是到自助食堂用餐的员工人数比午餐要少得多。 许多员工都通过允许自助食堂用户在线订餐的一个系统而提出订餐请求，要求在指定的日期和时间内将所订的午餐送到公司的指定地点。通过这样一个系统，使用这一服务的员工可以节约相当可观的时间，而且订到自己所喜欢的食物的机会也增大了。这既提高了他们的工作生活质量，也提高了他们的生产率。自助食堂提前了解到客户需要哪些食物，就可以减少浪费，并提高自助食堂员工的工作效率。要求送货上门的订餐员工将来还可以从本地的饭店来订餐，这就大大扩大了员工对食物的选择范围，并通过与饭店的大量购餐协议而有可能节约费用。Process Impact公司也可以只在自助食堂订午餐，而在饭店订早餐、晚餐、特定事件的用餐以及周末会餐。 2.业务目标（Business Objective，BO）和成功标准（Success Criteria，SC）
软件开发文档模板
软件开发文档模板 1 可行性研究报告 可行性研究报告的编写目的是：说明该软件开发项目的实现在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能先择的各种方案；说明论证所选定的方案。可行性研究报告的编写内容要求如下： 1.1 引言 1.1.1 编写目的 1.1.2 背景 1.1.3 定义 1.1.4 参考资料 1.2 可行性研究的前提 1.2.1 要求 1.2.2 目标 1.2.3 条件、假定和限制 1.2.4 进行可行性研究的方法 1.2.5 评价尺度 1.3 对现有系统的分析 1.3.1 数据流程和处理流程 1.3.2 工作负荷 1.3.3 费用开支 1.3.4 人员 1.3.5 设备 1.3.6 局限性 1.4 所建议的系统 1.4.1 对所建议系统的说明 1.4.2 数据流程各处理流程 1.4.3 改进之处 1.4.4 影响 1.4.4.1 对象设备的影响 1.4.4.2 对软件的影响 1.4.4.3 对用户单位机构的影响 1.4.4.4 对系统动行的影响 1.4.4.5 对开发的影响 1.4.4.6 对地点和设施的影响 1.4.4.7 对经费开支的影响 1.4.5 局限性 1.4.6 技术条件方面的可行性 1.5 可选择其他系统方案 1.5.1 可选择的系统方案 1 1.5.2 可选择的系统方案 2 …… 1.6 投资及收益分析 1.6.1 支出 1.6.1.1 基本建设投资
1.6.1.2 其他一次性支出 1.6.1.3 非一次性支出 1.6.2 收益 1.6. 2.1 一次性收益 1.6. 2.2 非一次性收益 1.6. 2.3 不可定量的收益 1.6.3 收益/投资比 1.6.4 投资回收周期 1.6.5 敏感性分析 1.7 社会条件方面的可行性 1.7.1 法律方面的可行性 1.7.2 使用方面的可行性 1.8 结论 2 项目开发计划 编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度所需经费预算、所需软、硬件条件等问题作出安排记载下来，以便根据本计划开展和检查本项目的开发工作。编制内容要求如下： 2.1 引言 2.1.1 编写目的 2.1.2 背景 2.1.3 定义 2.1.4 参考资料 2.2 项目概述 2.2.1 工作内容 2.2.2 主要参加人员 2.2.3 产品及成果 2.2. 3.1 程序 2.2. 3.2 文件 2.2. 3.3 服务 2.2. 3.4 非移交产品 2.2.4 验收标准 2.2.5 完成项目的最迟期限 2.2.6 本计划的审查者与批准者 2.3 实施总计划 2.3.1 工作任务的分解 2.3.2 接口人员 2.3.3 进度 2.3.4 预算 2.3.5 关键问题 2.4 支持条件 2.4.1 计算机系统支持 2.4.2 需要用户承担的工作 2.4.3 需由外单位提供的条件 2.5 专题计划要点
(完整word版)软件需求规格说明书(范例)(word文档良心出品).docx
项目管理协作支撑系统 软件需求规格说明书 目录 1.引言 (2) 1.1目的 (2) 1.2适用范围 (2) 1.3参考资料 (2) 1.4术语和缩略语 (2) 2.系统概述 (2) 2.1产品描述 (2) 2.2产品功能 (4) 2.3一般约束 (5) 3.功能性需求分类 (5) 3.1功能描述 1 .................................................................................................................错误！未定义书签。 3.2功能描述 2 (5) 4.产品的非功能性需求 (11) 4.1外部接口说明 (11) 4.1.1用户接口 (11) 4.1.2软件接口 (11) 4.2性能需求 (11) 4.2.1硬件的限制 (11) 4.3属性 (11) 4.3.1友好性 (11) 4.3.2安全性 (11) 4.3.3可维护性 (11) 4.3.4可转移 / 换性 (12) 4.4系统的运行环境 (12) 4.5其他需求 (12) 4.5.1用户操作需求 (12) 附录 A：需求确认 (14)
1.引言 1.1目的 编写此文档的目的是进一步定制软件开发的细节问题, 希望能使本软件开发工作更具体。 是为使用户、软件开发者及分析人员对该软件的初始规定有一个共同的理解，它说明了本产品的 各项功能需求、性能需求和数据要求，明确标识各功能的实现过程，阐述实用背景及范围，提供 客户解决问题或达到目标所需的条件或权能，提供一个度量和遵循的基准。 1.2适用范围 在各个行业中，当我们接受到用户的商业项目后，在项目运行的全过程中充满了不确定因素，只有有效的运用项目管理的科学和艺术，才有可能使项目取得成功。对以上方面要想达到有效的管理水平，必须有一套科学的管理方法，但是即使有了科学的管理方法，由于项目干系人之间的沟通、协作不到位，往往达不到预期的结果。鉴于这种情况我们开发一套项目管理协作支撑系统，旨在为项目干系人提供一个交流、协作以及项目的进度跟踪监控、项目的质量控制、项目相关资源的管理的软件平台，从而提高项目管理水平，实现了工作的协同化、提高了工作效率。 1.3参考资料 资料名称 [ 标识符 ]出版单位作者日期 1.4术语和缩略语 术语、缩略语解释 2.系统概述 2.1产品描述 本项目的目标是： <1>决策支持 :根据项目的需求及时提供所需信息, 并在一定阶段对各模块的进度进行追踪及提 示 , 实现工作的协同化、提高了工作效率。 <2>提高效率 : 利用软件进行管理, 避免人工管理的失误以及延迟性, 从而实现高效率的管理。
软件工程需求分析报告模版
目录 1 引言 1.1编写目的 (1) 1.2 项目背景 (1) 1.3术语说明 (1) 1.4 参考资料 (1) 2 项目概述 2.1编写目的 (1) 2.2 项目背景 (2) 2.3 术语说明 (2) 2.4 参考资料 (2) 2.5 条件和限制 (3) 3 功能需求 3.1功能划分 (3) 3.2功能描述 (3) 4 外部接口需求 4.1功能划分 (3) 4.2功能描述 (4) 5 性能需求 5.1 数据精确性 (4) 5.2 时间特性 (4) 5.3 适应性 (4) 6 软件属性需求 6.1 正确性 (4) 6.2 可靠性 (4)
6.3 效率 (5) 6.4 完整性 (5) 6.5 易使用性 (5) 6.6 可维护性 (5) 6.7 可测试性 (5) 6.8 可复用性 (5) 6.9 安全性 (5) 6.10 可理解性 (5) 6.11 可移植性 (5) 6.12 互联性 (5) 7 其他需求 (5) 8 数据描述 (5) 8.1静态数据 (6) 8.2动态数据 (6) 8.3数据库描述 (6) 8.4数据字典 (6) 8.5数据采集 (6) 9 附录 (6)
1引言 1.1编写目的 学生管理系统是面向学生的，目的是提高学校对学生的管理。本系统主要包括六个模块：学生的基本信息、课程的基本信息、登录、成绩录入、成绩查询和汇总功能，这六个模块基本实现设计本系统的目的，从而可以进一步满足学校对管理系统的要求。 现在的学生管理系统功能不够，所以我们要明确用户对学生管理系统的功能和性能的需求,并将这些需求用语言编写出来。并使系统开发者和学生对此成绩管理系统有共同的理解和认识。这是开发学生管理信息系统的基础,为了更好的开发，对系统的设计要详细。开发的系统要简单实用。 1.2 项目背景 项目名称为：学生成绩管理信息系统。开发目标为有效管理学生信息，实现学生信息的数据录入、浏览、修改等，从而实现对学生信息的规化、系统化、自动化管理。 1.3术语说明 MIS: 管理信息系统 Transaction Processing : 事务处理 Data Acquisition :数据采集 Data Processing Circle : 数据处理流程 Data Processing：数据处理 1.4 参考资料 《软件工程案例教程》…毕硕本卢桂香编著大学 《Vista Basic语言程序设计》…韬编著人民邮电 2 项目概述 2.1待开发软件的一般概述 此软件的目的是提高学校对学生的科学化管理，为学校的学生成绩管理系统
软件系统开发需求分析-模板
软件系统开发需求分析模板 1. 引言 编写目的 本系统的开发目的在于更好的管理和经营酒店餐饮行业。本文档的预期读者是酒店管理系统软件开发有关的开发人员。 项目背景 本项目的名称：酒店管理系统。 随着国民经济的发展，酒店餐饮行业的队伍在全国范围（尤其是在经济发达地区）不断壮大，从事酒店餐饮行业的单位之间竞争愈加激烈。为了提升自身的竞争能力， 各酒店餐饮单位都在尽量定制或购买各项业务的应用软件，运用高科技手段进行经营 和管理。为了让酒店更好的经营，我们组织开发了本软件。 本项目的任务提出者及开发者是酒店管理系统软件开发小组，主要是面向酒店餐饮服务行业。 定义 酒店管理系统是帮助酒店自身管理和服务酒店客户的软件。 % 参考资料 ①《现代软件工程》北京希望电子出版社孙涌等编著 ②《Delphi住宿餐饮管理系统开发实例导航》人民邮电出版社 刘敬严东明马刚编著 ③《软件需求说明书（GB856T——88）.doc》 ④《iso标准之需求分析说明书.doc》 2.任务概述 目标 开发本软件是为了服务酒店，使得酒店更好的经营。适用于一些大中型酒店，主
要用于就餐管理和住宿管理。本软件产品是一项独立的软件，不过功能还可以增加，完成后可以升级以增加功能和完善系统。 用户的特点 } 使用本软件要求用户熟悉Windows 操作，并且有一定的软件操作基础。预计本软件将会在一些大中型酒店中得到广泛使用。 假定和约束 本软件由我们小组六个人共同开发，几乎不要经费，开发期限一个月左右。3.需求规定 对功能的规定 ①系统帐号管理 第一次用一个管理员账号（系统给定）登陆，登陆成功后，可以设置其他用户，包括密码、权限等。 ②就餐管理 为就餐客户查询并分配餐桌，纪录客户用餐情况并结帐。 ③住宿管理 、 为住宿客户查询并分配房间，纪录客户住宿情况并结帐。 对性能的规定 精度 本软件主要用于管理，不是科学计算，要求计算的精度不是很苛刻。所以输入,输出数据精度的要求不是很高，用于计算的数用浮点数就可以了。 时间特性要求 本软件运行的响应时间要求不超过1～2秒，基本能实现。 灵活性
软件需求规格说明书(范例).doc
项目管理协作支撑系统（The English Name） 软件需求规格说明书 XXX项目小组
修订表
审批记录
目录 1.引言 (5) 1.1目的 (5) 1.2适用范围 (5) 1.3参考资料 (5) 1.4术语和缩略语 (5) 2.系统概述 (5) 2.1产品描述 (5) 2.2产品功能 (7) 2.3一般约束 (8) 3.功能性需求分类 (8) 3.1功能描述1.................................................................................................................... 错误!未定义书签。 3.2功能描述2 (8) 4.产品的非功能性需求 (14) 4.1外部接口说明 (14) 4.1.1用户接口 (14) 4.1.2软件接口 (14) 4.2性能需求 (14) 4.2.1硬件的限制 (14) 4.3属性 (14) 4.3.1友好性 (14) 4.3.2安全性 (14) 4.3.3可维护性 (14) 4.3.4可转移/换性 (15) 4.4系统的运行环境 (15) 4.5其他需求 (15) 4.5.1用户操作需求 (15) 附录A：需求确认 (17)
1.引言 1.1目的 编写此文档的目的是进一步定制软件开发的细节问题,希望能使本软件开发工作更具体。 是为使用户、软件开发者及分析人员对该软件的初始规定有一个共同的理解，它说明了本产品的各项功能需求、性能需求和数据要求，明确标识各功能的实现过程，阐述实用背景及范围，提供客户解决问题或达到目标所需的条件或权能，提供一个度量和遵循的基准。 1.2适用范围 在各个行业中，当我们接受到用户的商业项目后，在项目运行的全过程中充满了不确定因素，只有有效的运用项目管理的科学和艺术，才有可能使项目取得成功。对以上方面要想达到有效的管理水平，必须有一套科学的管理方法，但是即使有了科学的管理方法，由于项目干系人之间的沟通、协作不到位，往往达不到预期的结果。鉴于这种情况我们开发一套项目管理协作支撑系统，旨在为项目干系人提供一个交流、协作以及项目的进度跟踪监控、项目的质量控制、项目相关资源的管理的软件平台，从而提高项目管理水平，实现了工作的协同化、提高了工作效率。 1.3参考资料 1.4术语和缩略语 2.系统概述 2.1产品描述 本项目的目标是： <1>决策支持: 根据项目的需求及时提供所需信息,并在一定阶段对各模块的进度进行追踪及提 示,实现工作的协同化、提高了工作效率。 <2>提高效率:利用软件进行管理,避免人工管理的失误以及延迟性,从而实现高效率的管理。
软件需求分析报告文档模板.doc
软件需求分析报告文档模板 目录 1. 引言 (1) 1.1编写目的 (2) 1.2项目风险 (2) 1.3文档约定 (2) 1.4预期读者和阅读建议 (2) 1.5产品范围 (2) 1.6参考文献 (3) 2. 综合描述 (3) 2.1产品的状况 (3) 2.2产品的功能 (4) 2.3用户类和特性 (4) 2.4运行环境 (4) 2.5设计和实现上的限制 (4) 2.6假设和约束(依赖) (5) 3. 外部接口需求 (5) 3.1用户界面 (5) 3.2硬件接口 (6) 3.3软件接口 (6) 3.4通讯接口 (6) 4. 系统功能需求 (6) 4.1说明和优先级 (7) 4.2激励／响应序列 (7) 4.3输入／输出数据 (7) 5. 其它非功能需求 (7) 5.1性能需求 (8) 5.2安全措施需求 (8) 5.3安全性需求 (8) 5.4软件质量属性 (8) 5.5业务规则 (8) 5.6用户文档 (8) 6. 词汇表 (9) 7. 数据定义 (9) 8. 分析模型 (9) 9. 待定问题列表 (19)
引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者 ●软件开发者 ●产品使用者 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括 ●正文风格： ●提示方式： ●重要符号： 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括 ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议 1.5 产品范围 说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发与企业目标，
软件项目开发需求报告
软件需求分析格式_如何写需求分析报告 软件需求说明书 1 引言 1.1 编写目的：阐明编写需求说明书的目的，指明读者对象。 1.2 项目背景：应包括 ● 项目的委托单位、开心单位和主管部门； ● 该软件系统与其他系统的关系。 1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。 1.4 参考资料：可包括 ● 项目经核准的计划任务书、合同或上级机关的批文 ● 文档所引用的资料、规范等 ● 列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源 2 任务概述 2.1 目标 2.2 运行环境
2.3 条件与限制 3 数据描述 3.1 表态数据 3.2 动态数据：包括输入数据和输出数据。 3.3 数据库描述：给出使用数据库的名称和类型。 3.4 数据词典 3.5 数据采集 4 功能需求 4.1功能划分 4.2功能描述 5 性能需求 5.1 数据精确度 5.2 时间特性：如响应时间、更新处理时间、数据转换与传输时间、运行时间等。 5.3 适应性：在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。 6 运行需求
6.1 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。 6.2 硬件接口 6.3 软件接口 6.4 故障处理 7 其他需求 如可使用性、安全保密、可维护性、可移植性等。 需求分析的格式 需求分析要对目标系统提出完整的、准确的、清晰的和具体的要求。 1．综合需求：项目 说明 备注 1）功能要求 描述软件用来做什么
能够进行度量衡的相互转换，如：长度公制之间的转换，公制和英制的转换等。能够添加或创建新的度量衡。能够按照用户自己的需要进行排序。能够作为其他软件的插件或辅助工具使用。能够知道度量衡所应用的范围，如：国家，行业等。 2）性能要求 软件能达到什么性能 数据的最大存储量，数据的转换要有连续性，软件对每项操作的响应时间，更新处理时间，数据转换和传送时间，软件的输入输出数据精度，软件失败和成功的定义。 3）运行要求 软件能正常运行在微软中文版WINDOWS系列的可以独立运行的安装包或可执行文件 开发软件的开发工具清单。是否需要外部存储器和数据通信接口。
腾讯需求文档(模板)
XXX 修订记录 目录 修订记录 (1) 目录 (1) 1前言 (2) 1.1名词解释 (2) 1.2参考文档 (2) 1.3整体流程/逻辑关系 (2) 2特性 (2) 2.1特性F01XXXX (2) 2.1.1特性所包含的功能 (2) 2.1.2功能性需求(Functional Requirements，FR) (2) 2.1.2.1F01.FR01 XXXXX (2) 2.1.2.2F01.FR02 XXXXX (3) 2.2特性F02XXXX (3) 3性能需求 (3) 4国际化需求 (4) 5附录 (4)
1前言 1.1 名词解释 说明：列出本文档中所用到的专门术语的定义和缩略语的全称和解释。 1.2 参考文档 说明：列出本文档的所有参考文档。 1.3 整体流程/逻辑关系 说明：说明项目本份需求文档描述的产品或组件的总体流程图或逻辑关系图。 2特性 2.1 特性F01 XXXX 说明：陈述该特性的简要说明。F指特性，m为1~n的自然数，Fmm为该特性的编号。如：1.1特性F03 截图功能优化。 2.1.1特性所包含的功能 2.1.2功能性需求(Functional Requirements，FR) 2.1.2.1F01.FR01 XXXXX 说明：将复杂特性细分为系统需求，陈述该功能的详细说明。 如：1.1.2.1 F01.FR01屏幕截图灰屏机制优化。
2.1.2.2F01.FR02 XXXXX 2.2 特性F02 XXXX 内容构架同1.1，同样描述特性2的功能性需求 3性能需求 对照此表进行检查，在“相关特性”中简单标注符合条件的特性
软件开发需求 模板
目录
(9) 5
1. 范围 本指南用于指导软件开发者为****的过程，通过规范软件项目承担单位的开发过程达到提高软件质量，降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。在本指南的附录A至E中提供了文档的编写模板供开发者参考，在进行具体软件开发时，开发者可根据实际情况采编写，但必须提供双方约定的文档，文档中约定的内容必须描述清楚。 2. 总体要求 2.1 总体功能要求 网络应用环境以Internet/Intranet技术为核心。 开发者应在充分分析需求的基础上，选择采用B/S结构或者C/S结构。 软件系统的数据库应依照《******规范》进行设计和建设。 本指南中没有规定开发者采用何种具体的软件工程开发方法，开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法，但建议开发商使用面向对象软件工程的方法，如：采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。 2.2 软件开发平台要求 开发者开发的软件必须能够在******规定的软件平台上正常运行。目前软件平台为：数据库管理系统： Oracle 9i以上版本 中间件(应用服务器)系统： IBM WebSphere OA系统： Lotus Domino/Notes 网络架构： 完全支持TCP/IP协议 开发工具或技术体系： 为保证软件的上下兼容性，开发者应选择比较通用的开发工具的较新版本进行开发，如Microsoft Visual ，Borland Delphi，C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。
软件需求分析文档模板
项目编号： （项目名称） 需求分析报告 同方智能卡产品公司研发中心
目录 1. 任务概述 (3) 1.1. 目标 (3) 1.2. 系统（或用户）的特点 (3) 2. 假定和约束 (3) 3. 需求规定 (3) 3.1. 软件功能说明 (3) 3.2. 对功能的一般性规定 (3) 3.3. 对性能的一般性规定 (4) 3.4. 其他专门要求 (4) 3.5. 对安全性的要求 (4) 4. 运行环境规定 (4) 4.1. 设备及分布 (4) 4.2. 支撑软件 (4) 4.3. 接口 (4) 4.4. 程序运行方式 (5) 5. 尚需解决的问题 (5)
任务概述 1.1. 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 1.2.系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 2.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3.需求规定 3.1. 软件功能说明 列出本系统中所有软件功能子系统和功能。如果子系统比较大，每个子系统分别编写《软件功能规格说明书》，在本处列出编号和名称。 功能说明应包含以下几部分内容 3.1.1 软件功能列表 3.1.2 主要业务流程分析 3.1.3 软件部署结构分析 3.2. 对功能的一般性规定
软件开发需求分析报告
需求分析报告 1.引言 1.1目的 需求，指的是系统提供的能力必须遵从的条件，一个系统能否达到预期目标，系统需求做的好坏起着决定性作用，因此，他无疑是该平台开发过程中的重要一环。按照传统的软件工程理论，需求分析的目标就是确定要干什么，而不是怎么干，按照统一软件过程的理论（RUP理论），该平台的需求分析就是要致力于高效的正确的开发系统。必须足够详细的描述出系统需求，同时也要详细的描述系统必须达到的条件或实现的功能，使得用户就系统产生的问题一致。 本章将要对”基于教学POI的校园公共服务平台设计与开发”的需求进行分析,再此基础上将会对系统的各个功能进行建模,并且给出模型模型描述的图例序列图等模型。建立系统目标和需要解决的问题。 1.2背景 本设计将对基于教学POI的校园公共服务平台设计与开发进行详细的需求分析；基于教学POI的校园公共服务平台设计在兴趣点软件或APP中属于较为新颖贴近学生生活与教学内容的软件在这方面有大量的资源可循但是并没有与之相关的软件。作为本次软件工程设计的需求总体分析我们需要在POI、教学以及手机软件开发进行基本的融会贯通。 1.3术语 列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 POI信息平台系统的建立,最直接的提供了非常好的查询管理平台,极大的方便了学生的查询教学点\课程等方案的选择,为学生教师等提供了海量的便利教学信息;学生再也不用考虑担心自己找不到有疑问而大费精力. 通过对用户需求分析以及POI流程研究我们应该解决以下问题 在APP中搜索到正确的\合理的POI信息; POI信息的充分展现,包括地图展示并标记POI点的特殊标记;
软件开发需求文档模板
软件开发需求文档模板
目录
1. 范围 本指南用于指导软件开发者为南京市交通局开发软件项目的过程，通过规范软件项目承担单位的开发过程达到提高软件质量，降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。在本指南的附录A至E中提供了文档的编写模板供开发者参考，在进行具体软件开发时，开发者可根据实际情况采编写，但必须提供双方约定的文档，文档中约定的内容必须描述清楚。 2. 总体要求 2.1 总体功能要求 网络应用环境以Internet/Intranet技术为核心。 开发者应在充分分析需求的基础上，选择采用B/S结构或者C/S结构。 软件系统的数据库应依照《南京市交通局信
息化数据库建设规范》进行设计和建设。 本指南中没有规定开发者采用何种具体的软件工程开发方法，开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法，但建议开发商使用面向对象软件工程的方法，如：采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。 2.2 软件开发平台要求 开发者开发的软件必须能够在南京市交通局规定的软件平台上正常运行。目前软件平台为： 数据库管理系统： Oracle 9i以上版本 中间件(应用服务器)系统： IBM WebSphere OA系统： Lotus Domino/Notes 网络架构： 完全支持TCP/IP协议 开发工具或技术体系：
为保证软件的上下兼容性，开发者应选择比较通用的开发工具的较新版本进行开发，如Microsoft Visual https://www.wendangku.net/doc/026547135.html,，Borland Delphi，C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。 2.3 软件项目的开发实施过程管理要求 2.3.1 软件项目实施过程总体要求 （一）开发者提交软件开发工作大纲，交通局组织专家组对工作大纲进行评审，并提出整改意见。 （二）通过评审后，开发者根据整改意见完善工作大纲，经过交通局认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，开发者需分阶段提交相关文档。 （三）在软件开发工作完成后，开发者应向交通局提交完整的软件文档，交通局组织验收组对软件进行验收审查。 2.3.2 软件项目实施变更要求 在开发过程中，需求或设计不可避免地需要
软件工程文档模板范例
目录 三、需求规格说明书 (2) 四、概要设计说明书 (12) 五、详细设计说明书 (15)
3软件需求说明书软件需求说明书的编制是为了使用户的软件开发者双方对该软件的起初规定有一个共同的理解，使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 3.1引言 3.1.1 编写的目的 3.1.2 背景 3.1.3 定义 3.1.1 参考资料 3.2任务概述 3.2.1目标 3.2.2用户的点 3.2.3假定与约束 3.3需求规定 3.3.1对功能的规定 3.3.2对性能的规定
3.3.2.1 精度 3.3.2 .2 时间特性要求 3.3.2 .3 灵活性 3.3.3 输入输出要求 3.3.4 数据管理能力的要求 3.3.5 故障处理要求 3.3.6 其它的专门的要求 3.4 运行环境规定 3.4.1 设备 3.4.2 支持软件 3.4.3 接口 3.4.4 控制 4数据需求说明书数据要求说明书的编制目的是为了向整个开发时期提供关于处理数据的描述和数据采集要求的技术信息。编制数据要求说明书的内容要求如下： 4.1引言
4.1. 1 编写目的 4.1. 2 背景 4.1. 3 定义 4.1. 4 参考资料 4.2 数据的逻辑描述 4.2. 1 静态数据 4.2. 2 动态输入数据 4.2. 3 动态输出数据 4.2. 4 内部生成数据 4.2. 5 数据约定 4.3 数据的采集 4.3. 1 要求和范围 4.3. 2 输入的承担者 4.3. 3 处理 4.3. 4 影响 5概要设计说明书概要设计说明书可称作系统设计说明书，这里说的系统是指程序系统，编制的目的是说明对程序的系统的设计考虑，包括
软件需求分析模板
....信息管理系统需求说明书 ........
目录 1前言 (1) 1．1目的 (1) 1．2范围 (1) 1．3定义、缩写词、略语 (1) 1．4参考资料 (1) 2项目概述 (2) 2．1产品描述 (2) 2．2产品功能 (2) 2．3用户特点 (2) 2．4一般约束 (2) 2．5假设和依据 (3) 3具体需求 (3) 3．1功能需求 (3) 3．1．1功能需求1 (3) 3．1．2功能需求2 (4) 3．2外部接口需求 (4) 3．2．1用户接口 (4) 3．2．2硬件接口 (4) 3．2．3软件接口 (4) 3．2．4通信接口 (4) 3．3性能需求 (4) 3．4设计约束 (5) 3．4．1其他标准的约束 (5) 3．4．2硬件的限制 (5) 3．5属性 (5) 3．5．1可用性 (5) 3．5．2安全性 (5) 3．5．3可维护性 (5) 3．5．4可转移/转换性 (5) 3．5．5警告 (6) 3．6其他需求 (6) 3．6．1数据库 (6) 3．6．2操作 (6) 3．6．3场合适应性 (6)
....信息管理系统需求说明书 1前言 本章提供整个SRS综述。 1．1 目的 在这一条包括下列内容： a.描述实际SRS的目的； b.说明SRS所预期的读者。 1．2 范围 a.用一个名字标识被生产的软件产品。比如：×××数据库系统，报表生成程序等等； b.说明软件产品将干什么，如果需要的话，还要说明软件产品不干什么； c.描述所说明的软件的应用。应当： (1)尽可能精确地描述所有相关的利闪、目的、以及最终目标。 (2)如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相 一致（例如，系统的需求规格说明）。 1．3 定义、缩写词、略语 本条中必须提供全部需求的术语、缩写词及略语的定义，以便对SRS进行适当的解释。这些信息可以由SRS的附录提供。也可以参考其他的文件。 1．4 参考资料 本条应包括： a.在SRS中各处参照的文件的全部清单，如经核准的计划任务书，上级机关批文、合 同等； b.列出其他参考资料，如属本项目的其他已发表的文件和主要文献等。每一个文件、 文献要有标题，索引号或文件号，发布或发表日期以及出版单位； c.详细说明可以得到该参考文件的来源。这个信息可以通过引用附录或其他文件提 供。
软件项目需求分析通用模板
1. 引言 1.1 目的 说明编写这份报告的目的，指出预期的读者。 1.2 背景 指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。 1.4 术语 列出本报告中用到的专门术语的定义。
2.任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。3.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4.需求规定 4.1软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2对功能的一般性规定
软件需求规格说明书标准模板
软件需求规格说明书 文件编号：QMS—PROC－RD02 版本：1.0 受控签章
修改历史
目录 1引言 (4) 1.1目的 (4) 1.2背景 (4) 1.3术语 (4) 1.4预期读者与阅读建议 (4) 1.5参考资料 (4) 1.6需求描述约定 (5) 2.项目概述 (6) 2.1系统功能 (6) 2.2业务描述 (6) 2.3数据流程描述(可选) (6) 2.4用户的特点 (6) 2.5运行环境要求 (6) 2.6设计和实现上的限制 (6) 3.功能需求的描述 (6) 4.非功能需求 (7) 4.1系统性能要求 (7) 4.2系统安全及保密要求 (7) 4.3系统备份与恢复要求 (7) 4.4系统日志 (7) 5.外部接口说明 (7) 6.其他需求 (8) 7 需求变更识别 (8) 8.功能列表 (8) 9.附件 (8)
1引言 1.1 目的 说明编写这份软件需求规格说明书的目的，如：通过本文档定义ＸＸＸ产品的需求，以求在项目组员与相关成员之间达成一致的需求描述。 1.2 背景 描述系统产生的背景，包括： a．需开发的软件系统的名称，和英文缩写（可选），项目编号（可选）； b．列出此项目的任务提出者、开发者 c．软件系统应用范围、用户。 d．产生该系统需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性 1.3 术语 列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。 1.4 预期读者与阅读建议 描述本文档的主要读者，以及这些读者在阅读时的阅读重点与建议。可用列表的方式列 1.5 参考资料 列出有关的参考资料，如： a．本项目经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 d．行业标准和规范。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
软件需求文档(模板)
说明：本文中蓝色斜体字体为说明性文字，写文档时请删除或替换。 XXX 修订记录 目录 修订记录 (1) 目录 (1) 1前言 (2) 1.1名词解释 (2) 1.2参考文档 (2) 1.3整体流程/逻辑关系 (2) 2特性 (2) 2.1特性F01XXXX (2) 2.1.1特性所包含的功能 (2) 2.1.2功能性需求(Functional Requirements，FR) (2) 2.1.2.1F01.FR01 XXXXX (2) 2.1.2.2F01.FR02 XXXXX (3) 2.2特性F02XXXX (3) 3性能需求 (3) 4国际化需求 (4) 5附录 (4)
1前言 1.1名词解释 说明：列出本文档中所用到的专门术语的定义和缩略语的全称和解释。 1.2参考文档 说明：列出本文档的所有参考文档。 1.3整体流程/逻辑关系 说明：说明项目本份需求文档描述的产品或组件的总体流程图或逻辑关系图。 2特性 2.1特性 F01 XXXX 说明：陈述该特性的简要说明。F指特性，m为1~n的自然数，Fmm为该特性的编号。如：1.1特性F03 截图功能优化。 2.1.1特性所包含的功能 2.1.2功能性需求(Functional Requirements，FR) 2.1.2.1F01.FR01 XXXXX 说明：将复杂特性细分为系统需求，陈述该功能的详细说明。 如：1.1.2.1 F01.FR01屏幕截图灰屏机制优化。
2.1.2.2F01.FR02 XXXXX 2.2特性 F02 XXXX 内容构架同1.1，同样描述特性2的功能性需求3性能需求 4国际化需求