《软件需求（第2版）》，清华大学出版社，2004-11-1
【原书名】Software Requirements,SEcond Edition [原书信息]
【原出版社】Microsoft Press
【作者】（美）Karl E.Wiegers
【译者】刘伟琴刘洪涛
【开本】185×260 【页码】357
D需求文档范例 (2)
D.1前景和范围文档 (2)
D.1.1业务需求 (2)
D.1.2解决方案的前景 (4)
D.1.3范围和局限性 (5)
D.1.4业务上下文 (6)
D.2用例 (8)
D.3软件需求规格说明 (15)
D.3.1介绍 (15)
D.3.2总体描述 (16)
D.3.3系统特性 (18)
D.3.4外部接口需求 (22)
D.3.5其他非功能性需求 (23)
D.3.6附录A 数据字典和数据模型 (24)
D.3.7附录B分析模型 (28)
D.4业务规则 (29)
1
D需求文档范例
该附录通过“自助食堂订餐系统（Cafeteria Ordering System，COS）”这样一个假想的小型项目，阐述了本书所描述的某些需求文档和图。这里包括如下这些内容：
?前景和范围文档。
?用例列表和若干用例描述。
?部分软件需求规格说明。
?某些分析模型。
?部分数据字典。
?若干业务规则。
因为这仅仅是一个范例，所以我们并不打算完善这些需求元素。我们的目标只是提供一种思想，各种类型的需求信息之间彼此是如何关联的，并演示我们可能如何编写文档每一部分的内容。在一个小型项目中，将不同的需求信息综合到单一的文档中，常常是有意义的，因此我们可能没有单独的前景和范围文档、用例文档和软件需求规格说明。这些文档中的信息能够以多种其他合理的方式来组织。基本的目标是确保需求文档清晰明了、完整和易使用。
这些文档总的来说都遵循照前面章节所描述的模板，但是，因为这只是一个小型项目，所以对这些模板稍微作了一些简化。有时，会将几个部分合并起来，这是为了避免信息重复。每一个项目都应该考虑如何适应组织的标准模板，以尽量适合于项目的规模和本质。
D.1前景和范围文档
D.1.1业务需求
1.背景、业务机会和客户需要
2
目前，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）
3
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）
4
AS-1：自助食堂内有可以访问公司内联网的计算机和打印机，这样自助食堂的雇员就可以处理期望的订单量，不会遗漏任何送货时间。
AS-2：最多比请求的送货时间晚15分钟，自助食堂有送货人员和送货车辆，这样就能满足所有订单的送货要求。
DE-1：如果某饭店有自己的联机订餐系统，那么“自助食堂订餐系统”必须能与这一系统进行双向通信。
D.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公司总部内的自助食堂。
5
D.1.4业务上下文
1.涉众概览
涉众主要价值态度主要兴趣约束条件
公司管理层提高员工生产率；节约
自助食堂的费用强烈承诺完成版本 2.如果有
条件尽早完成版本3
使用该系统所节约的费用必须
超过开发此系统的费用和使用
此系统的费用
无
自助食堂工作人员更高效地利用了工作人
员的整个工作时间：提
高了客户的满意度
担心与联合会的关系，担心食
堂有可能会裁员；否则很愿意
接受新系统
保住工作培训工作人员，掌握使
用Internet所必需的技
能；必须有送货人员和
车辆
顾客可以更好地选择食物；
节约了时间：更加方便积极支持新系统，但使用系统
的次数可能没有期望的次数
多，这主要是因为顾客考虑到
在自助食堂和饭店就餐具有
社会价值
使用要简单；送货可靠；食物
选择的有效性
需要访问公司内联网
薪资管理部门得不到什么益处：需要
建立从工资中扣除餐费
的注册方案
不愿意采用该软件系统，但认
识到对公司和员工的整体利
益，所以能以大局为重
尽量减少对当前薪资核算软件
所做的变更
还没有得到资源来实现
薪资软件的变更
饭店经理增加了销售额；扩大了
销售范园，增加了新客
户虽然接受，但比较谨慎尽量少用新技术：关注送餐所
需的资源和费用
可能没有足够的人手和
能力来处理订单；可能
需要得到Internet访问
权
6
2.项目优先级
因素具体干活者约束条件自由度
进度计划3/l/03前完成第一版，到5/l/03前
完成第二版；在不包括责任人评审的情况
下，最多可超过期限3个星期
特性安排1.0版本实现的特性
必须完全可操作
质量必须通过95%的用户验
收测试；必须通过全部的
安全性测试；所有的安全
事务都必须遵守公司的
安全标准
工作人员项目团队规模包括一名半日工作的项目经理，两名开发人员，和一名半日工作的测试人员；如果有必要，还可以另外再增加半日开发人员和半日测试人员
费用在不包括责任人评审的情况下，财政预算
最多可超支15%
7
D.2用例
各种用户类确认的“自助食堂订餐系统”的用例和主要参与者如下所示：
主要参与者用例
顾客1.订餐
2.变更订单
3.取消订单
4.查看菜单
5.注册从工资中扣除餐费的付费方式
6.取消注册的从工资中扣除餐费的付费方式
7.订购标准餐
8.修改所订的标准餐
9推翻所订的标准餐
菜单经理10.创建菜单
11.修改菜单
12.定义特色菜
自助食堂工作人员13.准备餐
14.生成付费请求
15.请求送货
16.生成系统使用报告
送餐人员17.送餐
18.记录送餐情况
19.打印送餐说明
8
主要参与者用例用例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.系统确认接收订单
9
主要参与者用例
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步）
10
主要参与者用例
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）
描述使用“自助食堂订餐系统”并要求送餐的自助食堂顾客，必须注册从工资中扣除餐费的付费方
式。“自助食堂订餐系统”不支持现金购买，自助食堂会向“薪资核算系统”发出付费请求，这
将从下次雇员工资中扣除餐费或是在发薪日直接交款
11
主要参与者用例前置条件 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）
12
主要参与者用例
优先级高
使用频率平均每个雇员一次
业务规则BR-86和BR-88决定雇员是否有资格从工资中扣除餐费
特别需求 1.按照公司制定的中等安全应用程序的标准来执行用户认证
假设无
注意和问题系统发布之后的最初两星期，预计会相当频繁地执行这一用例用例ID号UC-11
用例名称修改菜单
创建者Karl Wiegers
最后更新者
创建日期2002年10月21日
最后更新日期
参与者菜单经理（Menu Manager）
描述自助食堂菜单经理可修改菜单的有效食物和特定日的价格，以反映有效食物或价格的变更，或者也可以定义当日特色菜
前置条件 1.菜单已存在于系统中
后置条件 1.修改的菜单已经保存起来
主干过程11.0 编辑已存在的菜单
1.菜单经理请求查看某一特定日期的菜单
2 系统显示菜单
3.菜单经理修改菜单以添加新的食物项、删除或变更食物项、创建或变更特色菜、或者变更
价格
4.菜单经理请求保存修改过的菜单
5.系统保存修改过的菜单
13
主要参与者用例分支过程无
异常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公司的每一个工作日都创建一个菜单，包括按照计划雇员要在公司加班的
周末和节假日
14
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[# https://www.doczj.com/doc/c92303373.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.doczj.com/doc/c92303373.html,/corporate/standards/PI intranet=dev=std.doc
(3) Christine Zambito BT#Pi Process Impact BuSIness Rules CataIog, EWil#
https://www.doczj.com/doc/c92303373.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.doczj.com/doc/c92303373.html,/corporate/standards/ PI=internet=ui=std.doc
15
16
D.3.2
总体描述
1.产品远景规划
“自助食堂订餐系统”是一个新系统，它取代了当前在Process Impact 公司自助食堂内以手工方式和电话方式预定和选择午餐的过程。图D.1是一幅关联图，它演示了1.0版本的外部实体和系统接口。期望系统演化若干个版本，最终与本地若干饭店的Internet 订餐服务相连接，并提供信用卡和借记卡授权服务。
图D.1 “自助食堂订膂系统”版本1.0的关联图
2.用户类和用户特性
用户类描述
顾客（优先考虑）顾客是俄勒冈州Clackamas的Process Impact公司的雇员，他们希望从公司的自助食堂订餐并能送货上门。大约有600名潜在顾客，其中估计有400人预计平均每星期每人使用“自助食堂订餐系统”4次（来源：根据当前自助食堂的使用数据）。顾客有时会由于团体事件或有来宾而订好多份餐。估计90%的订单是通过公司的内联网而提交的，10%的订单是从家里提交的。所有的顾客都可以从他们的办公室访问公司内联网。
有些顾客希望建立固定的订餐，每天送同样的饭菜，或者是自动送当日特色菜。顾客必须能推翻对某一具体日期的订餐
自助食堂工作人员Process Impact公司自助食堂目前雇佣了大约20名“自助食堂工作人员”，他们从“自助食堂订餐系统”接受订单，准备饭菜，对要送货上门的饭菜进行打包，打印送餐说明，并请求送餐。自助食堂工作人员需要接受培训.学会如何使用计算机、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 Linux版本和Apache HTTP Server。
OE-3：“自助食堂订餐系统”将允许用户通过公司内联网来访问，如果用户被授权在公司的外部穿过防火墙来访问，那么用户也可以在家里通过Internet来访问该系统。
17
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）刺激/响应序列
刺激：顾客请求订餐，可以是一份或多份。
响应：系统向顾客询问订餐细节、付费方式和送餐说明。
18
刺激：顾客请求改变订单。
响应：如果订单状态是“已接受”，则系统允许用户编辑以前的订单。
刺激：顾客请求取消订单。
响应：如果订单状态是“已接受”，则系统取消订单。
（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 当前日期的菜单只显示至少在自助食堂存货的一个供应间中有货的那些
食物
19
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 如果付费请求被拒绝，系统将显示一条消息来说明拒绝的理由。顾客可
以取消订单，也可以改为现金支付方式，或者是去食堂就餐
20
《需求分析报告》书写范例 1.引言 为使得高中语文《劝学》一课多媒体课件开发有序、有效，帮助开发人员与用户之间的交流与理解特制作此文档。本文档开发人员与用户各执一份。 2.项目背景描述 2.1 项目的委托单位：XXX 2.2 该软件系统与其他系统的关系，本项目为高中段语文教学用课件，单独使用于本课程的教学。 2.3 项目名称：高中语文《劝学》一课来讲解演示课件。 2.4 名词定义：无 3. 调研情况介绍 《劝学》是高中语文文言文教学中的一篇。作者：荀子。 通过对课件使用教学能达到以下教学要求： 1、领悟评价作者的思想感情。 2、认识文章艺术特色。 3、了解文言文实词，虚词的用法。 4. 用户特点 4.1 用户业务描述：用户一般为高中语文教师及高中段学生，通过教学学习课文。 4.2 用户情况：教师通过对课件展示课文内容： 1.教师按照：新课引入、全文分析、归纳总结几个方面对课文加以讲解，达到教学要 求。 2.用户最好能直观地展示课文所在求内容； 3.用户一般为高中段语言教师，计算机操作技能一般，因此应尽可能操作直观、方便。 4.3 用户原有系统的情况：原有PPT为顺序执行结构，只能从头放到尾，没有向回返的机制，使用时也只能展示一次。学生有问题时无法及时转移到相应的位置上。
5.任务概述 5.1目标 5.1.1开发目标 演示型课件一般是为了解决教学的重点难点问题而设计制作的，主要作用是辅助教师课堂演示，不要求知识内容的系统讲解，一定要突出重点、难点。通过计算机的多媒体性将不容易用其他媒体解决的问题，以简洁明了的方法和形式呈现给学生。对于语文、历史、地理等需要有大量文字、图形图片、语音等表达知识的重点、难点的课程一般采用演示型课件。高中语文《劝学》一课来讲解演示课件的规划与开发。本软件根据此需求进行开发的。 5.1.2应用目标 使用多媒体教学更容易使学生接受教学的重点与难点。 6. 运行环境 6.1硬件环境 6.2软件环境 6.3条件与限制 7. 功能要求
第一章 1.需求分析与系统设计之间的界限是什么? 何时从分析阶段进入设计阶段? 需求分析关注系统”做什么”, 系统设计关注”如何做”。 当分析阶段完成后才能进入到设计阶段 2.需求处理要注意哪些非技术因素? 为什么? 要注意的非技术因素: 组织机构文化、社会背景、商业目标、利益协商等。因为利用建模与分析技术构建的解决方案一定要和具体的应用环境相关, 不存在不依赖具体应用环境的解决方案, 因此, 在利用建模分析技术进行要求处理是不能忽视具体应用环 境的相关因素 3.需求分析与需求工程之间的关系 那就是需求工程含义更广, 包括需求获取、需求分析、需求定义 第二章 1.解释名词:问题域, 解系统和共享现象, 并结合她们的含义 说明软件系统如何与现实世界形成互动的 问题域: 现实的状况与人们期望的状况产生差异就产生问题。 解系统:软件系统经过影响问题域, 能够帮助人们解决问题称 为解系统经过共存现象仅仅是问题域和姐系统的一个部分。而不是她们的全部。
软件系统仅仅是现实世界的一种抽象。因此问题除了共享现象 之外。还有很多在进行模型抽象时忽略的其它现实因素。 2.解释下列名词, 需求, 规格说明, 问题域特性和约束, 并结 合她们的含义说明需求工程的主要任务是什么? 需求是用户对问题域中的实体状态或事件的期望描述 规格说明:规格说明是解系统为满足用户需求而提供的解决方案, 规定了解系统的行为特征。 问题域的特性: 在和解系统相互影响的同时, 问题域是自治的, 它有自己的运行规律, 而且这些规律不会因解系统的引入而发生 改变, 这种自治的规律性称为问题域特性, 当这些特性非常明确 时称之为约束。 需求工程的主要任务: 1.需求工程必须说明软件系统将应用的环境及目标, 说明用来达成这些目标的软件功能, 还要说明在设计和实现这些功能时上下文环境对软件完成任务所用的方式、方法所施加的限制和约束。2需求工程必须将目标、功能和约束反映到软件系统中, 映射为可行的软件行为, 并对软件行为进行准确的规格说明。3需求工程还要妥善处理目标、功能和约束随着时间的演化情况。 4.需求有哪些常见的类别? 功能需求和非功能需求有什么差异? 严格意义上的软件需求的分类: 功能需求( Functional Requirement) : 和系统主要工作相关的需求, 即在不考虑物理约束的情况下, 用户希望系统所能够执行的
案例one：教学管理系统（用例驱动的交互式需求获取） 以一个教学管理系统JXGL的分析与设计作为示例，说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富，工作繁多。作为一个示例，规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况，选择自己要学习的课程，并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况，以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理，包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理，负责新学期的课程选课注册工作; (2)成绩管理，负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供师生参 考选择。若某课程的实际选课学生少于10人，则停开该课程，把该课程从课程目 录表中删除;若某课程的选课学生多于30人，则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后，教学管理员打印学生选课注册名单和开课通知书，送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表，获得课程信息。查询的关键词以是:课 程名，授课教师名，学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名， 授课教师名，学分。学生只允许查询自己的选课信息，不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名，性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程，按学生，按班级)，印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:
以下是需求分析说明书、详细设计说明书、概要设计说明书样例 需要详细资料的去 https://www.doczj.com/doc/c92303373.html,/BBS/view.asp?ID={CA9329C0-93C5-4417-9170-452FF61E8C DB}&page=1下载 XX系统概要设计说明书 目录 1. 文档介绍1 1.1 文档目的1 1.2 文档范围1 1.3 读者对象1 1.4 参考文献1 1.5 术语与缩写解释1 2. 系统概述2 3. 设计约束2 3.1需求约束2 3.2隐含约束2 4. 设计策略3 4.1扩展策略3
4.2复用策略3 4.3折衷策略3 5．系统总体结构3 5.1、系统总体结构3 5.2、子系统功能及接口4 6. 子系统的结构与功能5 6.1、TERMSERV 5 7. 功能需求追溯5 8. 环境的配置5 9．其它6 附录 6 A、与主机接口6 B、与终端接口6 1. 文档介绍 1.1 文档目的 编写该文档的目的在于从总体设计的角度明确xxxx系统的功能和处理模式，明确与银联的接口，使系
统开发人员和产品管理人员明确产品功能，可以有针对性的进行系统开发、测试、验收等各方面的工作。 1.2 文档范围 1.3 读者对象 该文档的读者为用户代表、软件分析人员、开发管理人员和测试人员。 1.4 参考文献 《xxxx系统需求说明书》 1.5 术语与缩写解释 无 2. 系统概述 XX系统是以触摸屏为主要交互工具，帮助用户以自助方式做业务查询。本系统的主要功能包括：话费 查询、新业务介绍、网点分布查询、自助终端分布查询、电信新闻、交易监控、设备维护和监控等。本系 统的设计目标是保证系统可以7*24小时安全、高效无故障运行；业务人员可以轻松完成设备和交易的监控 、管理工作；报表种类齐全，可以满足业务人员各种帐务需求。 3. 设计约束
软件开发文档 项目名： “通讯录” 版本： α测试版 作者： ccba 编写时间：2001-8-20 文档内容： 1 需求规格说明书 2 概要设计说明书 3 详细设计说明书 文档号IM00101 需求规格说明书 1、引言： 1.1 编写目的 本文档的编写是为了确定待开发软件的功能、性能、数据、界面的需求。 1.2 项目背景 “通讯录”软件是为了提供一种功能完备，易于操作、界面美观的优秀软件。该软件由蔡文亮单独开发完成。 1.3 定义 需求规格说明书采用参考资料②标准 1.4 参考资料 ①薛华成《管理信息系统（第三版）》清华大学出版社1999.5 ②郑人杰、殷人昆、陶永雷《实用软件工程（第二版）》清华大学出版社1997.4 ③周之英《现代软件工程（基本方法篇）》科学出版社 2000.1 2、功能需求 该软件由四个主功能模块和一个扩展功能模块构成，各功能模块中规定的均为软件的基本功能，在开发过程中，开发人员可根据实际情况在满足基本功能需求的前提下增加新功能，但必须详细编写相关文档。 2.1录入、修改功能模块 该功能块主要用于数据库的数据录入和修改，考虑到通讯录的实际需要，可以放松对数据库完整性结束的控制，但从减少数据库的角度来考
虑，不容许有完全相同的纪录出现（考虑的合并，相同的纪录项）。 2.2查询功能块 本功能模块是最重要的功能块，对通讯录的操作最主要部分就是查询操作。 本功能块要求有如下功能： 1）按数据库各个属性查询 2）按数据库各个属性之间的逻辑组合查询 如：查询名称为“鸭子”且年龄为20岁的详细情况 （SQL语句表示）SELECT * FROM MESSAGER WHERE NICKNAME=“鸭子” AND AGE=20 3）按某一属性的数值范围查询及其逻辑组 如：查询年龄在20至35岁间的详细情况 （SQL语句表示）SELECT * FROM MESSAGER WHERE AGE BETWEEN 20 AND 35 4）模糊查询 同时我们要求查询结果可以按用户要求的格式来显示，如：用户能调整显示属性的个数和组合。 2.3系统安全块 通讯录的信息是个人隐私，故在软件中加入必要的安全措施。主要有以下三点： 1）登录帐号和密码的管理 2）帐户权限的控制 3）对部分登录帐号隐藏部分内容 2.4系统设置块 本部分内容主要是对软件使用时一些设置使其更利于软件的使用：主要包括以下四个方面： 1）系统界面背景和色彩设置（模仿WINNAP） 2）闹铃功能开关，即实现朋友生日提醒功能 3）记录内容项（即数据库修改通讯录上的内容项） 4）历史记录，用户可以选择是否记录下何人何时使用过该软件 2.5扩展功能块 1）网络功能：通过OLE/COM接口的调用，实现E-mail软件调用。2）帮助文档的制作（On-line help）
需求分析说明书 1. 引言 (3) 1.1 编写目的 (3) 1.2 项目风险 (3) 1.3 预期读者和阅读建议 (5) 1.4 产品范围 (5) 1.5 参考文献 (5) 2. 系统总体概述 (6) 2.1 目标 (6) 2.2 用户类和特性 (7) 2.3 运行环境 (7) 2.3.1 硬件环境 (7) 2.3.2 软件环境 (7) 2.4 设计和实现上的限制 (7) 2.5 假设和约束(依赖) (8) 2.5.1 产品的SEO排名 (8) 2.5.3系统的安全 (8) 3. 外部接口需求 (8) 3.1 用户界面 (8) 3.2 硬件接口 (8) 3.3 软件接口 (8) 3.4 通讯接口 (9) 4. 系统特性 (9) 4.1 说明和优先级 (9) 4.2 激励／响应序列 (9) 4.3 功能需求 (9) 4.4 功能详述 (12) 4.4.1以使用软件的汽车用户为例： (12) 5. 其它非功能需求 (13) 5.1 性能需求 (13) 5.2 安全措施需求 (13) 5.3 安全性需求 (14) 5.4 操作需求 (14) 5.5 软件质量属性 (14) 5.6 业务规则 (14) 5.7 用户文档 (14) 6. 词汇表 (14) 6.1 SSH (14)
6.2 JAVA (14) 6.3 MYSQL (15) 7. 待定问题列表 (15)
1. 引言 1.1 编写目的 本需求分析说明书对本项目第一阶段的内容进行分析，对需求细节和实现方式进行了较为详细的阐述。本需求说明书供业务和科技部门人员、软件需求提供人员、软件的概要设计人员、软件的开发人员、软件的测试人员使用，并作为产品验收确认的依据。 需求分析是在可行性研究的基础上，将用户对系统的描述，通过开发人员的分析概括，抽象为完整的需求定义，再形成一系列文档的过程。可行性研究旨在评估目标系统是否值得去开发，问题是否能够解决，而需求分析旨在回答"系统做什么"的问题，确保将来开发出来的软件产品能够真正满足用户的需要。 构建一个软件系统最困难的工作是确定构建什么。其他任何工作都不会像这部分工作那样，在出错之后会如此严重地影响随后实现的系统，并且在以后修补竟会如此的困难。 需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。一般情况下，用户并不熟悉计算机的相关知识，而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。所以，开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要。 有效的需求分析通常都具有一定的难度，一方面是因为交流存在障碍，另一方面是因为用户通常对需求的陈述不完备、不准确和不全面，并且还可能不断地变化。开发人员不仅需要在用户的帮助下抽象现有的需求，还需要挖掘隐藏的需求。此外，把各项需求抽象为目标系统的高层逻辑模型对日后的开发工作也至关重要。合理的高层逻辑模型是系统设计的前提。 在进行需求分析的过程中，首先要明确需求分析应该是一个迭代的过程。由于市场环境的易变性以及用户本身对于需求描述的模糊性，需求往往很难做到一步到位。需求分析不仅仅是属于软件开发生命周期早期的一项工作，而且还应该贯穿于整个生命周期中，它应该随着项目的深入而不断地变化。 此外，为了方便后续的评审和测试等工作，需求的描述应该尽量做到：具体、详细、可以测量和可以实现，并且基于时间。 1.2 项目风险 政策风险分析： 随着社会的进步与人们生活水平的提高大幅度增加，尤其在我国汽车进入家庭的条件下，需要更多的适合现代汽车技术要求和社会经济承受能力的汽车维修检测设备，为了让四轮定位仪市场变得规范、有序，中国汽车保修设备行业协会与全国汽车维修标准化技术委员会于2004年，制定了四轮定位仪的行业标准（标准号JT/T505-2004），国家交通部2004年国标GB/T16739.1-.2-2004《汽车维修业开业条件》规定：一、二类汽车维修企业必须配备
校园小卖部 1 引言 1.1 编写目的 编写校园小卖部需求分析报告的目的是为了需求提供者和开发方明确对所建信息管理系统索道到的功能和目标。通过双方不断的讨论和交互，最终形成具有建设目标的书面条款。经双方确认后，将作为开发设计的基本依据和需求方面的软件验收标准，同时，通过该需求分析的报告，开发方可以更加进一步了解客户的需求，从而严格按照流程及时、准确地完成网站的开发，以满足客户的需求。 同时，该文档也作为概要设计及后续设计的基础。 1.2 背景 随着时代的发展，科技的进步，自然界出现了一种新的物种——窝居动物。现在的大学校园中，越来越多的学生喜欢宅在宿舍里，连吃饭都懒的下楼，再有，宿舍楼门晚上都是关的，他们夜里饿了渴了只能忍着。面对这种情况，本网站应运而生，系统包含了商品展示、在线订单、售后保障等功能。 2系统概述 2.1 项目目标 从总体上考虑，系统因该实现下列功能： 用户管理 2.1.1用户管理 2.1.1.1 用户注册 主执行者：系统管理员，学生、店主 功能描述：添加学生以及信息填充 基本功能： 1.学生注册账号，填写个人信息（学生编号、姓名、宿舍号、联系电话等）
2．管理员点击添加学生按钮，输入学生编号、姓名、宿舍号、联系电话等。 扩展：1.及时检查学生各项信息是否为空，是否符合格式 2.即时显示学生名是否存在 2.1.1.2用户登录 主执行者：系统管理员，学生 功能描述：管理员和学生进行登录 基本功能：1.管理员，学生输入账号密码，点击登录，验证通过，进入系统。系统进入对应的角色页面。 扩展：1.验证学生名，密码不正确时，提示学生哪部分出错 2.学生输入完账号，按Tab键可以跳到密码输入框 2.1.1.3用户删除 主执行者：系统管理员，学生 功能描述：删除学生 基本功能： 1.学生点击注销账号 2.管理员选中要删除的账号，点击删除按钮进行删除，提示学生是否删除，点击确认，删除成功 2.1.1.4用户修改 主执行者：系统管理员，学生 功能描述：修改学生资料，重置密码 基本功能：1.学生进入个人信息显示页面修改个人信息 2.管理员选中要修改的账号，点击修改，进入页面修改学生资料，或者重置学生密码 2.1.1.5购买记录 主执行者：系统管理员，学生 功能描述：记录历史购买记录 基本功能：1.学生可以在个人信息页面中看见自己的购买记录 2.管理员管理购买记录 2.1.1.6留言 主要执行者：顾客 功能描述：顾客对商家进行留言
网上选课系统分析文档 第1章引言 1.1 编写目的 网上选课管理系统作为管理管理员与用户的选课关系的主要管理系统平台，其对应的读者是企业用户，因此，不仅要处理管理员与用户之间的信息，还要处理用户个人信息。导致网上选课管理系统中的数据不论是结构、类型还是彼此间的关联都是复杂多变的：对这种数据进行的处理也是多种多样的。因此，要实现对网上选课管理系统数据的及时、准确的处理和有效利用。 1.2 术语(该系统所在行业和领域上的术语) https://www.doczj.com/doc/c92303373.html,是建立在微软新一代.NET平台架构上的，提供开发者一种灵活的方式进行的Web开发以及创建Web服务。 1.3 参考文献（参考的文档） ASP+SQL Server2005项目开发从入门到精通 ASP动态网站设计经典案例 https://www.doczj.com/doc/c92303373.html,网站开发 https://www.doczj.com/doc/c92303373.html,网页设计与网站开发 第2章系统概述 2.1 系统说明 本系统可以方便教师开设课程和学生选课，方便教师与学生之间的交流。 利用网站实现教师开课的网络化，学生选课的网络化，教师评定学生成绩的网络化等，提高教师和学生的效率，降低管理的成本。 2.2 系统任务 2.2.1 系统目标 课程信息的管理：包括课程的录入，修改和删除等 教师信息的管理：包括教师信息的录入，修改和删除等 学生信息的管理：包括学生信息的录入，修改和删除等 学生网上选课的管理：包括学生通过浏览器进行选课，取消选课，查询选课及修改登陆密码等 2.2.2 运行环境 SQL Server—Application Server DB Server Browser .NET Framework IIS 2.2.3 与其它系统关系 无 2.3 需求规定 2.3.1 功能需求 公用模块： ①登陆：实现身份验证，根据不同身份跳转入不同的页面 ②密码修改：实现个人的密码修改功能 ③退出系统：实现用户注销并退出系统 管理员模块： ①查看学生信息，新增、修改或删除学生信息 ②查看学生信息，新增、修改或删除教师信息 ③查看学生信息，新增、修改或删除课程信息 ④查看学生信息，新增、修改或删除院系信息 ⑤查看学生信息，新增、修改或删除专业信息 ⑥设定课程的上课老师及地点 学生模块： ①查看修改个人信息 ②查看所有选课的信息并选课 ③修改所选课程 ④查看个人选课的成绩和学分（查看选课信息[成绩及学分] 选课退选[弹出窗口是否确定]） ⑤退选 教师模块： ①查看修改个人信息 ②查看所教课程 ③为学生录入分数及修改 ④查看所教课程的学生 2.3.2 性能需求 系统响应时间2-5秒 并发用户2000人
需求分析说明书实例 1.引言 1.1编写目的 在完成了针对《档案管理系统》软件市场的前期调查，同时与多位软件使用者进行了全面深入地探讨和分析的基础上，提出了这份软件需求规格说明书。 此需求规格说明书对《档案管理系统》软件做了全面细致的用户需求分析，明确所要开发的软件应具有的功能、性能与界面，使系统分析人员及软件开发人员能清楚地了解用户的需求，并在此基础上进一步提出概要设计说明书和完成后续设计与开发工作。本说明书的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。 1.2项目背景 由于文件多，种类多，文件创建者多，创建时间为不定期，要保护好一些公司重要的文件极为不便，同时由于人员的流动，对原有的文件的再现，显得力不从心，有时查找与重新整理文件要浪费许多的人力、物力。而且近年来，由于竞争的激烈程度不断的加深，档案的管理不当会严重到导致公司的面临着亏损甚至破产的局面。于是人们不断地在探索希望能找到解决的方法。 为了解决以上的问题，让企事业单位能够有效的掌握，有效的共享文件资源，保护好文件，及促进档案管理的信息化、规范化和集成化，本人多方听取意见、追加和完善大量实用功能，进而了解文件管理的流程，同时结合各部门、各行业与企业文件管理的方法，开发出一套适合于档案多而复杂的管理系统。 1.3定义、缩写词和符号 需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其它正式规定文档所需具有的条件或权能。 1.4参考资料 鲁荣江、王立丰：《Visual Basic 项目案例导航》，科学出版社，2002年6月版 陈明：《软件工程》，中央广播电视大学出版社，2002年6月版 段兴：《Visual Basic 6.0 控件实用程序设计100例》，人民邮电出版社，2002年12月 杜春雷、孙会莲：《如何使用Visual basic 6.0中文版》，机械出版社，2000年1月 张曜、张青、李丁：《Visual Basic 函数实用手册》，治金工业出版社，2002年12月 范国平、陈晓鹏：《Access 2000 数据库系统开发实例导航》，人民邮电出版社，2002年12月版 闪四清：《SQL Server 实用简明教程》，清华大学出版社，2003年1月版 2.任务概述 2.1目标 2.1.1开发目标 在当今世界电脑普及的时刻，人们已经习惯用电脑办公，结果自然会产生大量的电子文件，这些文件有宝贵的历史价值，但我们如果将更多的时间花费在寻找这些文件上，即费时又费力。本软件根据此需求进行开发的。
需求分析说明书、概要设计说明书、详细设计说明书部分样例 作者：rjgczj 出处：csai论坛 以下是需求分析说明书、详细设计说明书、概要设计说明书样例，需要的朋友来信联系。rjgczj@https://www.doczj.com/doc/c92303373.html, XX系统概要设计说明书 目录 1. 文档介绍1 1.1 文档目的1 1.2 文档范围1 1.3 读者对象1 1.4 参考文献1 1.5 术语与缩写解释1 2. 系统概述2 3. 设计约束2 3.1需求约束2 3.2隐含约束2 4. 设计策略3 4.1扩展策略3 4.2复用策略3 4.3折衷策略3 5．系统总体结构 3 5.1、系统总体结构 3 5.2、子系统功能及接口 4
6. 子系统的结构与功能5 6.1、TERMSERV 5 7. 功能需求追溯5 8. 环境的配置5 9．其它 6 附录 6 A、与主机接口 6 B、与终端接口 6 1. 文档介绍 1.1 文档目的 编写该文档的目的在于从总体设计的角度明确xxxx系统的功能和处理模式，明确与银联的接口，使系统开发人员和产品管理人员明确产品功能，可以有针对性的进行系统开发、测试、验收等各方面的工作。 1.2 文档范围 1.3 读者对象 该文档的读者为用户代表、软件分析人员、开发管理人员和测试人员。 1.4 参考文献 《xxxx系统需求说明书》 1.5 术语与缩写解释 无 2. 系统概述 XX系统是以触摸屏为主要交互工具，帮助用户以自助方式做业务查询。本系统的主要功能包括：话费查询、新业务介绍、网点分布查询、自助终端分布查询、电信新闻、交易监控、设备维护和监控等。本系统的设计目标是保证系统可以7*24小时安全、高效无故障运行；业务人员可以轻松完成设备和交易的监控、管理工作；报表种类齐全，可以满足业务人员各种帐务需求。 3. 设计约束
需求规格说明书 目的：定义软件需求，为后期的设计打下基础 背景、备注： 定义： 参考：
1概述 客户是公司最宝贵的资源，为了更好的发掘老客户的价值，并开发更多新客户，XX公司决定实施客户关系管理系统。希望通过这个系统完成对客户基本信息、联系人信息、交往信息、客户服务信息的充分共享和规范化管理；希望通过对销售机会、客户开发过程的追踪和记录，提高新客户的开发能力；希望在客户将要流失时系统及时预警，以便销售人员及时采取措施，降低损失。并希望系统提供相关报表，以便公司高层随时了解公司客户情况。 客户服务是一个涉及多个部门，存在一定流程的工作。客户服务水平的高低决定着公司的核心竞争力。该客户关系管理系统应提供一个客户服务在线平台，使客户服务处理过程中相关人员可以在线完成服务的处理和记录工作。 1.1目的 本文档是武汉信息技术有限公司在与XX公司的客户关系管理系统实施合同基础上编制的。本文档的编写为下阶段的设计、开发提供依据，为项目组成员对需求的详尽理解，以及在开发开发过程中的协同工作提供强有力的保证。同时本文档也作为项目评审验收的依据之一。 1.2范围 主要是XX公司的销售主管、客户经理及其管理员用来管理语客户相关的信息与活动。 1.3背景 客户关系管理系统用于管理与客户相关的信息与活动，但不包括产品信息、库存数据与销售活动。这三类数据将由XX公司X销售系统进行管理。 1.4用户与角色 系统管理员： 管理系统用户、角色与权限，保证系统正常运行。 销售主管：
对客户服务进行分配。 创建销售机会。 对销售机会进行指派。 对特定销售机会制定客户开发计划。 分析客户贡献、客户构成、客户服务构成和客户流失数据，定期提交客户管理报告。 客户经理： 维护负责的客户信息。 接受客户服务请求，在系统中创建客户服务。 处理分派给自己的客户服务。 对处理的服务进行反馈。 创建销售机会。 对特定销售机会制定客户开发计划。 执行客户开发计划。 对负责的流失客户采取“暂缓流失”或“确定流失”的措施。 高管： 审查客户贡献数据、客户构成数据、客户服务构成数据和客户流失数据。 1.5产品理念 1.6文档约定 1.7需求优先级说明 [A1]: 优先级1，优先，必须做； [A2]: 优先级2，中等，争取做； [A3]: 优先级3，下等，可不做； 备注：需求项没有特别说明优先级的，表示为[A1]。 1.8预期的读者和阅读建议 使用文档结构图 1.9参考文献 无
需求分析文档例 WTD standardization office【WTD 5AB- WTDK 08- WTD 2C】
主要内容提示： 1 引言（作为设计文档，前面一般有一段引言，每个文档中的内容类似。） “ 简介（背景） 本项目名称为：大发航空公司航空电子订票系统，为大发航空公司订制，解决该公司网上订票问题。 编写目的 此需求规格说明书对航空订票系统做全面细致的用户需求分析，明确所要开发的软件应具有的功能、性能与界面，使系统分析人员及后续的软件设计人员能清楚地了解用户的需求，可以在此基础上进一步工作。本说明书的预期读者为系统设计人员、测试人员、用户文档编写者、项目管理人员、用户代表。 定义 （1）系统：若未特别指出，系统指本航空订票系统。 （2）SQL：结构化查询语言 参考资料 （1）系统的项目开发计划 （2）系统的可行性研究报告 （3）吕云翔等，《软件工程—理论与实践》，人民邮电出版社，2012年8月版
（5）张海藩，《软件工程》，第5版，清华大学出版社 ” 2 任务概述 目标 “ 本系统主要解决师生交换作业信息问题，教师可以将新作业传到该系统上，也可以在系统上下载学生上传的作业，并将成绩上传供学生查看。学生上传作业供任课老师批阅，查看自己的作业成绩。 系统的基本功能： 1．不同用户登录进入不同的界面 2．学生查看作业 3．学生查看作业成绩 4．学生上交作业 5．教师布置作业 6．教师删除已布置作业 7．教师公布作业成绩 9．教师修改作业成绩 10．教师下载学生的作业 11．管理员添加教师用户 12．管理员添加学生用户 13．用户资料的查看与修改 ”
软件开发文档 项目名：“通讯录” 版本：α测试版 作者：ccba 编写时间：2001-8-20 文档内容： 1 需求规格说明书 2 概要设计说明书 3 详细设计说明书 文档号IM00101 需求规格说明书 1、引言： 1.1 编写目的 本文档的编写是为了确定待开发软件的功能、性能、数据、界面的需求。 1.2 项目背景 “通讯录”软件是为了提供一种功能完备，易于操作、界面美观的优秀软件。该软件由蔡文亮单独开发完成。 1.3 定义 需求规格说明书采用参考资料②标准 1.4 参考资料 ①薛华成《管理信息系统（第三版）》清华大学出版社1999.5 ②郑人杰、殷人昆、陶永雷《实用软件工程（第二版）》清华大学出版社1997.4 ③周之英《现代软件工程（基本方法篇）》科学出版社2000.1 2、功能需求 该软件由四个主功能模块和一个扩展功能模块构成，各功能模块中规定的均为软件的基本功能，在开发过程中，开发人员可根据实际情况在满足基本功能需求的前提下增加新功能，但必须详细编写相关文档。2.1录入、修改功能模块 该功能块主要用于数据库的数据录入和修改，考虑到通讯录的实际需要，可以放松对数据库完整性结束的控制，但从减少数据库的角度来考虑，不容许有完全相同的纪录出现（考虑的合并，相同的纪录项）。 2.2查询功能块 本功能模块是最重要的功能块，对通讯录的操作最主要部分就是查询操作。 本功能块要求有如下功能： 1）按数据库各个属性查询 2）按数据库各个属性之间的逻辑组合查询 如：查询名称为“鸭子”且年龄为20岁的详细情况 （SQL语句表示）SELECT * FROM MESSAGER WHERE NICKNAME=“鸭子” AND AGE=20 3）按某一属性的数值范围查询及其逻辑组 如：查询年龄在20至35岁间的详细情况 （SQL语句表示）SELECT *
一、概述 会议室管理系统用于实现会议室资源的使用管理，系统由用户管理和会议室管理两大模块构成（见图1：会议室管理系统模块图），其中用户管理用于实现系统用户的增删改及系统登录注销功能，会议室管理用于实现对会议室资源的增删改及会议室预定、使用情况统计等功能。 图1：会议室管理系统系统模块图 二、具体功能描述 1、用户管理 用户管理模块用于维护系统部门、用户等信息，登陆、注销系统和用户信息的修改（用于普通用户），系统数据流图（使用结构化需求分析的用这个图，此句最后删除，下同）如下（图2：用户管理模块数据流图）：
图2：用户管理模块数据流图 用例图（使用面向对象需求分析的用这个图，此句最后删除，下同）如下（图2：用户管理模块用例图）：
图2：用户管理模块用例图 1.1 部门信息维护 对部门信息进行增删改处理，包括新增部门、修改部门、删除部门三类操作。 ●约束条件： ?部门编码及部门名称不能重复； ?如部门下已经有用户存在，不能删除； ?仅实现一级部门管理。 ●数据辞典（用于结构化需求分析，如果下面的模块中使用相同的辞典，不 需要重复） ?名称:部门信息表
?描述:系统使用用户部门信息 ?定义: ●类图（用于面向对象需求分析，如果下面的模块中使用相同的类图，不需 要重复） ?名称:部门 ?描述: 系统使用用户部门信息 ?定义: ●具体功能 ?新增部门 ◆输入：部门编号，部门名称 ◆处理： ●判定输入的部门编号、部门名称是否为空 ●判定输入的部门编号、部门名称是否重复 ●数据库新增一条部门信息 ◆输出： ●输入的部门编号、部门名称为空，返回出错提示 ●输入的部门编号、部门名称重复，返回出错提示 ●返回成功添加提示
第2章需求分析 2.1 系统可行性分析实验 信息系统开发项目在开始前一般都需要进行可行性分析。系统开发的可行性分析工作随开发需求、社会环境、工作流程、技术条件和人力资源条件的不同而不同，但总体来说，可行性分析围绕着总体需求、社会环境、发展趋势、管理环境、基础设施环境、技术条件、人力资源和资金条件等项内容来论证信息系统的必要性和可行性。下面结合《连锁店配送管理系统》，给出可行性分析报告的主要内容，使读者了解并掌握可行性报告的撰写方法。 2.1.1 系统开发必要性分析 连锁零售业的发展状况在过去的几十年中，以连锁化、信息化和规模化为特征的零售业发展很快，已成为当今社会经济的支柱产业。目前，就销售额而言，零售企业已超过制造、金融服务、信息等类型企业而成为世界第一，这在过去是不可想象。而其中连锁这个先进的企业组织形式的应用是今天商品零售企业能发展到如此大的规模的一个核心因素。我国发展连锁商业的时间不长，但已逐步成为商业零售业的一支主力军，最近几年，连锁企业的销售增长均在50％以上，连锁百强企业销售额占社会消费品零售总额将在8.0％以上。连锁企业逐步扩大的销售规模使连锁商业企业在供应链上的作用日益增大，并且对中国的流通现代化产生巨大的推动。连锁企业的实质是五个统一、即统一采购，统一配送、统一核算、统一标识、统一管理。而统一配送是连锁企业核心竞争力的一个重要部分。 连锁商业物流的主要方式大型零售企业建立自己的物流配送中心在国际上，有代表性的以大零售商为主导建立物流配送中心的企业是沃尔玛。目前沃尔玛公司独立投资建立的配送中心有200多家，专为本公司连锁店按时按需提供商品，确保各店稳定经营。家乐福、麦德龙、西尔斯等国际大零售商，都建立有本企业体系的现代化物流配送中心。 我国部分大型连锁企业有自己的物流配送中心，其中主要原因是我国目前有相当数量的连锁企业都是从传统的副食品公司、蔬菜公司、粮店以及其它配套网点的基础上建立起来的。这些传统企业，都有很丰富的场地、设施设备、人员等建立配送中心的基础，这种配送形式有较大的比例。在这些物流配送中心中，大多数信息化和机械化程度较低，主要依赖于手工操作，配送效率和对店铺的反应速度较低。供应商自理物流由供应商直接进行商品配送，这种配送方式主要适用于店铺规模大，采购规模大的超市。如国内的一些大卖场和综合超市公司，他们由总部确定统一的供应商，店铺向供应商要货。由供应商直接将商品配送到店铺。这种由供应商直接配送优点在于：大大降低连锁企业成本和运作的复杂性，因此一般来说，中小型连锁企业主要依赖供应商提供商品配送，但这样的配送运作成本高，且配送对店铺的响应速度受到供应商物流水平的限制，同时也依赖于店铺和供应商信息交流的效率高低。 某中型连锁超市拥有十几家连锁分店和一个配送中心。由于配送中心为每个连锁店送货不及时，效率不高导致各个连锁店的商品货物积压或者缺货严重，也浪费了大量的人力物力
机票预定系统需求分析 机票预定系统的功能要求 机票预定系统的总目标是：在计算机网络，数据库和先进的开发平台上，利用现有的软件，配置一定的硬件，开发一个具有开放体系结构的、易扩充的、易维护的、具有良好人机交互界面的机票预定系统，实现航空公司的机票销售的自动化的计算机系统，为企业的决策层提供准确、精细、迅速的机票销售信息。 根据可行性研究的结果和客户的要求，分析现有情况及问题，采用Client/Server 结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。 旅客订票流程图：
旅客取票图： 下面分析各个子系统的功能需求： 1．客户端子系统： 在客户端系统的功能实现上，可以分为以下几个部分： [1]旅客信息的输入和统计 旅行社把旅客要求订票的信息由专人负责输入。这部分功能是客户端子系统 的基本部分，这个功能是以后各个部分的基础。系统要求做到即能够从其它子系 统中共享一部分信息，又有方便的操作界面工手工输入旅客信息。这部分要求对输入的数据进行简单的统计，供航空公司进行查询和宏观调控。 [2]旅客信息的存储： 将旅客的信息存储到旅行社的客户端系统中，以备以后的取票确认以及查 询。 [3]机票信息的传递及接收： 将旅客所须的机票信息由旅行社客户端由网络传到航空公司的服务器上，并且接受航空公司返回的航班信息，然后存储起来。 [4]取票通知及帐单的生成和打印： 把已存储的从航空公司返回的航班机票信息打印出来，并且生成帐单打印出来一起交给旅客。 印出机票给已经订票的旅客：根据旅客的取票通知及帐单，经过确认无误后，接受旅客的付款后把机票印出来交给旅客。 [5]机票销售情况的核算 这一功能是在上一功能的基础上，对机票销售额进行单项核算，得到该旅行社的销
软件需求分析复习题 判断题 1、使用实例方法可以使用户更清楚地认识到新系统允许他做什么，那么我们就应该 试图把每一个需求与一个使用实例相联系，尽可能多的使用实例。（F） 2、在状态图中定义的状态主要有：初态（即初始状态），终态（即最终状态）和中 间状态，在一张状态图中只能有一个初态，而终态则可以有0至多个。（T ） 3、结构化分析方法适合于数据处理类型软件的需求分析。（T） 4、数据流图中每个加工至少有一个输入数据渝，但可以没有输出数据流。（F） 5、DFD与数据流程图的区别是程序流程图用于表示程序的过程设计，DFD用作描述 软件的逻辑功能，不能表示程序的控制结构。（T） 6、屈性是指实体某一方面的特征，一个实体通常有多个属性。联系也可以有屈性。 （T） 7、软件需求描述的是“如何做”，而不是“做什么”。（F） 8、软件成功的标准是用户在用，并且可以很容易做完要做的事。（T） 9、业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规 划本身就是软件需求。（F） 10、软件需求的层次包括业务需求、用户盂求、功能需求。（T） 二、选择题 1. 需求分析最终结果是产生（C ） A. 项目开发计划 B.可行性分析报告 C.需求规格说明书 D.设 计说明书 2. 需求分析中，开发人员要从用户那里解决的最重要的问题是（A ） A. 让软件做什么 B.要给软件提供哪些信息
C.需求软件工作效率怎样 D.让软件具有何种结构 3. 需求规格说明书的内容不应包描对（D ）的描述。 A.主要功能 B.算法的详细过程 C.用户界面的运行环境 D.软件性能
4. 需求规格说明书的作用不应包括（D ） A ?软件设计的依据 B.用户与开发人员对软件要做什么的共同理解 C ?软件验收的依据 D.软件可行性研究的依据 5?下面关于面向对象方法中消息的叙述，不正确的是（B ） A. 键盘，鼠标，通信端口、网络等设备一一有变化，就会产生消息 B. 操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息 D. 发送与接收消息的通信机制与传统的子程用调用机制不同 6.而向对象技术中，对象是类的实例。对象有三种成分（A ）、屈性和方法（或 操 作）。 A.标识 B.规则 C.封装 D.消息 &软件需求规格说明书的内容不应包括对（B ）的描述。 A.主要功能 B.算法的详细过程 C ?用户界面及运行环境 D.软 件的性能 9.软件需求分析阶段的工作，可以分成4个方面：需求获取，需求分析，编写 需求规格说明书以及（B ） A.用户 B.需求评审 C ?总结 D.都不正确 10?在原型法中，开发人员根据（A ）的需求不断修改原型，直到满足客户要求 为止。 A.用户 B.开发人员 C.系统分析员 D.程序员 11?需求验证应该从下述儿个方面进行验证：（C ） A. 可靠性、可用性、易用性、重用性 B. 可维护性、可移植性、可重用性、可测试性 C. 一致性、现实性、完整性、有效性 D. 功能性、非功能性 12?风险管理的要素包括?哪项（D ） A.风险评价 B.风险避免 C.风险控制 D.以上都是 13?下列描述中错误的是（D ） A. 每一个集成的需求变更必须能跟踪到一个经核准的变更请求 B. 变更过程应该做成文档，尽可能简单，当然首要的是有效性 C ?所有需求变更必须遵循过程，按照此过程，如杲一个变更需求未被采纳，则 其后过程不再予以考虑 7.软件需求分析阶段的工作, 综合、制定规格说明以及（C 可以分成以下四个方面：对问题的识别、分析与 ） A.总结 B.实践性报告 C.需求分析评审 D.以上答案都不正确
鑫方圆纺织有限公司进销存管理系统 《需求说明书》 第一部分、引言 1.1编写目的 该文档为我项目组与鑫方圆纺织有限公司人员交流、洽谈，共同制定。确定鑫方圆纺织有限公司进销存软件系统功能，文档化需求，方便我项目组后期开发按需求完成功能。达到鑫方圆纺织有限公司预期的效果。同时，该文档也是我项目组是否按要求完成项目计划的依据。 日期：2011年**月**日1.2背景 说明： A、软件名称：鑫方圆纺织有限公司进销存管理系统 B、提出者：鑫方圆纺织有限公司 开发者：华腾软件学院 实现完成的系统将在鑫方圆纺织有限公司的采购、销售、仓储等部门使用，所应用的网络是鑫方圆纺织有限公司内部服务器网。该公司的相关操作人员可以通过内部网络来操作本系统。 C、本系统将是独立的系统，目前不予鑫方圆纺织有限公司的其他软件系统提供接口，与第三方软件无交互，所产生的输出都是独立的。 第二部分、任务概述 2.1目标 鑫方圆纺织有限公司为了实现纺织管理信息化，以及各部门管理的规范化，流程化，以及仓库管理的严格化，而委托我项目组开发一套采购、销售、库存等各部门管理一体化的系统。达到仓库管理清晰化，透明化，解决手工记录造成的混乱不清，以及销售订单、采购计划、仓库管理，一体化管理。解决信息流通不够及时，处理问题不够迅速的目标。我项目组根据需求设计了如下解决方案：（具体功能说明后面有介绍） 基本信息管理 采购管理 销售管理 仓库管理 系统管理 统计分析 第1页共10页
该软件为内部服务器运行系统，并不与其他软件有任何交互。是一款可独立运行的完整系统。 2.2用户特点 系统管理员：具有丰富的服务器技术、和软件系统，负责软件超级管理员管理。 经 理：简单培训即可迅速掌握软件使用方法。软件主要使用人员 销售人员：简单培训即可迅速掌握软件使用方法。软件主要使用人员 采购人员：简单培训即可迅速掌握软件使用方法。软件主要使用人员 仓库主管：简单培训即可迅速掌握软件使用方法。软件主要使用人员 仓库管理员：简单培训即可迅速掌握软件使用方法。软件主要使用人员 2.3假定和约束 根据鑫方圆纺织公司，协商决定开发期限为：2011年**月**日-2011年**月**日 开发经费：待定，另增需求酌情提高经费。 第三部分、需求规定 3.1对功能的规定 3.1.1 功能说明 系统分为基本信息管理、采购管理、销售管理、仓库管理、统计分析、系统管理和帮助，７个模块，系统使用人员包括 厂部、销售部、采购部、仓库、以及系统管理员，厂部即为经理，以及系统管理员相同权限，具有完全权限，可操作全部内容，销售部经理操作销售管理以及所需基础信息，而销售部人员不能操作订单的审核管理，采购部经理操作采购管理以及所需基础信息，而采人员购部不能操作采购单的审核管理。仓库管理员操作所需基础信息，以及仓库所有内容，但不包括审核操作。 所有人员具有查看系统帮助模块，以及系统模块，但除管理员、厂部人员外，其他人不可操作权限管理。 3.1.2 一级功能模块介绍 根据以上对进销存管理内容和进销存管理系统的分析，一个标准的进销存管理系统应该包括如图1.1所示的几大功能。 图1.1 第2页 共10页 鑫方园纺织有限公司进销存管理系统 系统管理 采购管理 销售管理 仓库管理 基本信息 统计分析