产品需求规格说明书模板.doc.docVIP

XXXXXXXXXXXXX项目 用户需求分析说明书 V1.0 签字确认信息 建设方：**** 承建方：**** 代表人： 代表人： 日期： 日期： 文档修订记录 版本 编号 变化 状态 简要说明 (变更内容及范围) 日期 变更人 批准日期 批准人 V1.0 C 创建 *变化状态：A——增加，M——修改，C――创建，D——删除 目 录 1 概述 4 1.1 编写目的 4 1.2 文档范围 4 1.3 术语定义 4 1.4 参考资料 5 2 系统说明 6 2.1 产品的背景 6 2.2 产品的功能 6 2.3 用户类和特征 6 2.4 运行环境 6 2.5 设计和实现上的限制 6 2.6 假设和依赖 7 2.7 其他条件与限制 7 3 业务流程 8 4 功能描述 8 5 数据描述 9 5.1 数据来源和数据流图 9 5.2 数据库描述 9 6 性能描述 10 6.1 数据精确度 10 6.2 时间特性 10 6.3 适应性 10 7 安全性 11 7.1 安全性需求 11 8 运行接口需求 12 8.1 用户界面 12 8.2 硬件接口 12 8.3 软件接口 12 9 其他需求 13 10 附件 14 1 概述 1.1 编写目的 [阐明编写需求说明书的目的，指明读者对象。可以用如下的列举方式进行描述。] 例如： 本文档是[项目名称] [系统属性]系统需求分析说明书供设计人员使用，作为系统设计的依据。 作为项目验收标准之一。 软件维护的参考资料。 …… 文档范围 本文档是项目的软件需求规格说明书，是技术文档。 本文档使用对象为： 项目需求人员 项目经理 高层经理 软件工程组 软件相关组成员 用户 未经项目负责人书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。 1.3 术语定义 列出文档中所用到的专门术语的定义和缩写词的原文。可以用列举方式进行描述 [术语名称或缩略语] [术语解释] [术语名称或缩略语] [术语解释] 1.4 参考资料 应包括：a.项目任务书、合同；b.项目开发计划；c.文档所引用的资料、标准和规范。列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源。 2 系统说明 2.1 产品的背景 描述软件需求规格说明中所定义的产品的背景和起源。说明该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一产品、是否是现有应用程序的替代品，或者是否是一个新型的、自含型产品。如果软件需求规格说明定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关的，并且要定义出两者之间的接口。 2.2 产品的功能 概述了产品所具有的主要功能。其详细内容将在下面几章中描述，所以在此只需要概略地总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图，都是有用的。 2.3 用户类和特征 确定可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。 2.4 运行环境 描述软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。 可以分别对服务器端和客户端的运行环境进行描述，如下所示： 服务器端 客户端 2.5 设计和实现上的限制 确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。可能的限制包括如下内容： 必须使用或者避免的特定技术、工具、编程语言和数据库。 所需求的开发规范和标准（例如，如果由客户的公司负责软件维护，就必须定义转包者所使用的设计符号表示和编码标准）。 企业策略、政府法规或工业标准。 硬件限制，例如定时需求或存储器限制。 数据转换格式标准。 2.6 假设和依赖 列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立），可能包括打算使用的商业组件或有关开发或运行环境的问题。如果这些假设不正确、不一致或被更改，就会使项目受到影响。 确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖哪个项目按时提供正确的操作组件，如果这些依赖已经记录到其它文档（例如项目计划）中了，那么在此就可以参考其它文档。 2.7 其他条件与限制 尽量列出开展本项目的假定和约束，例如：经费限制，开发期限，设备条件，用户现场环境准备、安全保密等 3 业务流程 可以运用流程图、文字说明等方式来描述具体的业务流程 4 功能描述 可以运用功能清单、格式表单、界面说明、图形、文字说明等方式来描述业务流程 5 数据描述 5.1 数据来源和数据流图 描述输入数据和输出数据，业