总体需求规格说明书范例.doc

(完整word)总体需求规格说明书范例
【项目名称】
需求股
(文档版本号:V1＊.＊)

XXXX有限公司
XXXX年XX月
修订历史
版本号
更新日期
修订作者
主要修订摘要
0。1
2009-4—25
刘波
初始文档生成.

目 录
1。 综述 4
1.1 文档说明 4
1.2 编写目的 4
1。3 适用范围 4
1。4 名词、术语、缩略语定义 5
1。5 参考资料 5
2。 项目概述 5
2。1 项目背景 5
2.2 项目目标 5
3. 需求调研的目标 6
4. 需求调研的思路 6
4。1 调研的核心问题 6
4。2 围绕的关键点 7
4。3 业务调研访谈思路 7
4。4 现有系统调研思路 7
5. 需求调研的方式 7
6. 需求调研的内容 8
6.1 功能分类调研内容 8
6。1.1 功能性需求调研 8
6.1.2 非功能性需求调研 8
6.2 业务分类调研内容 8
6。2。1 对信息部门的调研内容 8
6.2。2 对业务部门的调研内容 9
7. 需求调研使用表格 9
8。 调研访谈时间安排 12
9. 需求调研成果提交 13

概述
目的
说明编写这份报告的目的，指出预期的读者。
背景
指出待开发的软件系统的名称;行业情况；本项目的提出背景、任务提出者、开发者、用户;该软件系统同其他系统的相互关系。
参考资料
列出编写本报告时参考的文件（如经批准的计划或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。
编号
资料名称
简介
作者
日期
出版单位

列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。
网点
简介

术语和缩略语
列出本报告中用到的专门术语、缩略语的定义，对于重要的或是有特殊意义的名词进行解释。
任务概述
目标
叙述该项软件开发的意图、应用目标、作用范围.解释被开发软件与其他有关软件之间的系.
项目产品体系结构图
说明本项目产品与其它产品的关系,可以用图表的形式。比如，本项目产品是否是一个大的产品的组成部分，是否要替换已有的产品，或者是一个独立的产品。如果与其它产品有关系，它们之间的关系要在此描述。
项目产品功能描述
说明项目产品必须具备的主要功能（仅作简单介绍）.如果使用了建模技术，用高层的数据流图或用例图（Use Case Diagram）来描述会更加有效。
系统特点
如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处,与市场上同类软件（如果有的话）的比较。
如果是针对合同开发，则应列出本软件的最终特点。
约束条件
用户情况
介绍本项目的用户（或潜在用户）的情况，包括：
1． 用户的技术水平；
2． 最终使用部门、技术支持部门、参与测试验收的部门；
运行环境
说明项目产品将在什么样的环境下操作,包括硬件平台、操作系统及版本、必须安装的软件部件和应用软件等.
硬件环境
列出满足系统需求所必须的最低硬件配置、推荐硬件配置(如主机、显示器、存储设备、外部设备等)以及其它特殊设备。
或列出用户期望或现有的设备环境。
以及与其他系统的硬件接口。
软件环境
列出满足系统需求或用户期望或现有的操作系统、网络软件、数据库系统、中间件以及其它特殊软件要求.
以及与其他系统的软件接口。
限制条件
描述项目产品可能存在的限制条件以及与其它受影响的组和个人的约定，包括硬件条件、软件限制、交付产品、人力资源、交付日期、里程碑等。举例:项目产品必须在IBM PC或100％兼容的计算机上运行，计算机最低内存64M、最小硬盘空闲空间10G。操作系统是WIN2000及更高版本.软件源代码必须用C/C++编写。
假设和依赖
列出所有会影响项目需求实现的假设因素（相对于已知的事实而言）。例如，本项目产品计划要使用某些第三方软件产品或商业软件产品,虽然目前还未得到这些软件,但我们可以假设这些软件一定能够得到。如果这些假设不正确、或发生改变，会影响项目的开发，因此，这些假设往往又是一种风险。
如果项目的开发或项目产品的使用要依靠其它外部因素,比如与其它产品共用的软件包、准备重用的软件构件等，也要在此说明.
用户原系统情况
如果用户存在原有系统，介绍用户原来使用系统的主要情况,包括主要的不足。如果用户不存在或不关心原有系统，本章节可省略。
运行环境
用户存在原有系统的运行环境。
体系结构
用户存在原有系统的体系结构。
业务处理方式
用户存在原有系统的业务处理方式。
系统特点
用户存在原有系统的特点.
业务流程
描述系统实现的业务流程，包括角色、业务处理过程。
功能需求
功能需求1（以实际的需求名代替）
简要描述
简明描述该需求点的作用和目的。
事件流程
描述参与者的操作和系统的响应，重点指明需要做什么事情，而不是如何完成这些事情。
基本流程
描述正常情况下的处理流程。
异常流程
描述异常情况下的处理流程
特殊需求
描述用户要求的不符合流程的要求.
前置条件
描述触发该事务的必要条件.
后置条件
描述该事务完成时,必需满足的条件。。
功能需求2（以实际的需求名代替)
按照需求1的格式依次描述，直到所有的需求。
数据描述
描述系统输入、输出涉及的数据情况说明，如外部数据接口、界面展示或打印的数据、表项等。
非功能需求
适用性需求
描述系统被预想的不同级别用户（如文盲用户、初学者、普通用户、高级用户等）的学习和可操作能力。建议从以下方面（不限于）进行描述：
指明为了使用户能够完成简单任务以及完成普通日常工作所需要的培训时间;
指明典型终端用户可能的典型任务的可度量时间;
比较新系统与目前用户团体熟悉的或正在使用的系统的适用性；
指明是否制作在线帮助系统、向导、工具说明、用户手册以及其它形式的文档和帮助，以及所需特征；
人机界面开发的要求或规范。
可靠性需求
描述用户能够接受的或期望系统运转程度,建议从以下几个方面(不限于）阐述：
Ø 可用性:如5×8,7×24;
Ø 平均修复时间；
Ø 准确性；
Ø 最大错误或缺陷率（如:错误数/千行代码）；
Ø 错误分类原则;
Ø 故障处理原则。
安全性需求
描述客户要求的或者应该满足的安全性.
性能需求
性能需求通常包括以下几类（不限于）:
Ø 事务的响应时间或效率：平均值、最大值；
Ø 吞吐量：每秒事务数；
Ø 容量：系统可容纳的客户总数或事务总数；
Ø 数据精度;
Ø 容错能力;
Ø 可恢复能力；
Ø 退化模式：当系统被降级时，可接受的运转模式。
可支持性需求
可支持性是指为了升级或修复，软件的被修改能力。
即对系统设计的灵活性和拓展性的要求。
辅助部分
未确定问题
说明目前尚未确定的问题及处理的计划。
需求的优先级
将所有的功能需求或用例（如果需求分析结果是使用用例),按高、中、低的优先级分类。列出章节号即可，例如6。2需求2(以实际的需求名代替）
功能需求/使用用例
优先级

高/中/低

对高、中、低的解释如下：
优先级
解释
高
关键的功能，必须在本次项目开发中实现。
中
增强性功能，可以在下一个项目版本中实现.
低
功能或性能的提高，属于美化性质的功能，如果有时间，可以实现.
开发成本估算
以列表的方式估算出各功能需求所需的开发人时和费用。
功能需求/用例
工时
费用

风险分析
根据需求，分析风险。包括,需求可实现性、需求变动、时间压力、技术复杂度、人力资源不足等。
功能需求/用例
风险
风险级别

高/中/低

遵循的法律法规
变更记录
序号
修改单号
页号
条款号
修改人/日期
批准人/日期
实施日期

注:对该文件内容增加、删除或修改均需填写此变更记录,详细记载变更信息，以实现追溯。