通用产品需求规格说明书模板

密级：产品需求规格说明书模板

XX股份有限公司

二ОО*年**月**日

文件修订记录

目录

1 引言 (1)

1.1 编写目的 (1)

1.2 背景 (1)

1.3 定义 (1)

1.4 参考资料 (1)

2 系统概述 (2)

2.1 目标 (2)

2.2 用户 (2)

2.4 设计与实现的限制 (2)

2.5 假设和依赖 (2)

3 功能需求 (2)

3.1包图 (2)

3.2包1 (2)

3.2.1用例图 (2)

3.2.2用例1 (3)

3.2.3用例2 (4)

4 性能需求 (4)

4.1时间特性要求 (4)

4.2精度要求 (4)

4.3业务量估算 (4)

4.4灵活性 (4)

4.5可用性 (5)

4.6安全性 (5)

5 接口需求 (5)

9.1硬件接口 (5)

9.2软件接口 (5)

9.3通讯接口 (5)

9.4用户接口 (5)

6 其他需求 (6)

7 运行环境 (6)

7.1 操作系统 (6)

7.2 应用服务器 (6)

7.3 数据库系统 (6)

8 系统约束 (6)

9 验收标准 (7)

9.1功能验收标准（示例）： (7)

9.2性能验收标准(示例)： (7)

附录A ××× (8)

A.1××× (8)

A.2××× (8)

附录B ××× (8)

附录C ××× (8)

[产品需求规格说明书编写要求：关于封面、目录、正文等排版要求请参阅项目文件排版指导；正文的内容参照以下要求组织，本模板只提供参考，根据项目的不同特点，对有关章节可做必要的剪裁与调整。]

1 引言

1.1 编写目的

为了使用户与开发人员之间相互了解，对用户需求进行明确定义，使之成为整个开发工作的基础，并提供一个软件系统度量和遵循的基准。该文件可作为公司软件设计人员、测试人员、市场销售人员的指导性文件，也作为用户了解软件系统的功能，进行软件系统确认与验收测试时的依据。

1.2 背景

说明：

a.需求分析所采用的方法

b.开发的软件系统的名称

列出本软件系统的中文全称、英文全称及英文表示简称。

c.开发的软件系统的最终用户或适用的领域；

d.开发的软件系统同其他已开发系统的关系。

1.3 定义

列出本文件中用到的专门术语定义和外文首字母组词的原词组。

1.4 参考资料

列出用得着的参考资料，如：

a.经核准的计划任务书或合同；

b.参考的其他文件、资料、国家或行业标准;

c.与产品有关的法律法规;

d.其他同类软件产品等.

列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够用得到这些文件资料的来源。

2 系统概述

2.1 目标

项目开发目标和应用目标。

2.2 用户

说明可能使用本系统的用户并描述他们相关的特征。

2.4 设计与实现的限制

可能的限制包括如下内容：

a.必须使用或避免的特定技术、工具、编程语言和数据库；

b.用户明示的或隐含的需求、规定的用途或已知的预期用途所必需的限制；

c.所要求的开发规范或标准（如，由客户的公司负责软件维护，就必须定义转

包者所使用的设计符号表示和编码标准）；

d.公司确定的附加要求、政府法规或工业标准；

e.硬件限制，如定时需求或存储器限制；

f.数据转换格式标准。

2.5 假设和依赖

列举影响需求陈述的假设因素（与已知因素相对立），确定项目对外部因素存在的依赖（如，需把其他项目开发的组件集成到系统中，就要依赖那个项目按时提供正确的操作组件）。

3 功能需求

3.1包图

描述包的划分和包之间的关系。（如果没有包的划分，此节不用描述）。

3.2包1

写出包的名字，不要用“包1”作为标题。

3.2.1用例图

描述用例图，包括涉及到的所有Actor、用例及其关系。

3.2.2用例1

用需求编号加上简短词汇做为用例名，不要用“用例1”作为用例名，例如：R.INTF.CALC.001 计算表达式。

3.2.2.1描述

简要介绍该用例的目的、作用和背景。

3.2.2.2参与者

参与者的描述。

3.2.2.3前置条件

用例实例化时系统的状态。

3.2.2.4基本事件流描述

参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作方式，所以通常称其为适当路径 (happy path) 或主路径 (main path)。

从最简单的或最典型的场景开始，并在其中追溯事件的顺序。

一个用例可以拥有一个或多个基本事件流，取决于用例可以被实例化的途径的数量。

3.2.2.5备选事件流

用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。

在基本事件流的基础上，在不同的用例事件流中逐一描述不同的变化和处理方法，称之为备选事件流。

这些描述相互独立，可以避免让基本事件流卷入到用例所需处理的各种变化中。

3.2.2.6后置条件

用例实例结束时系统的状态。

3.2.2.7特殊需求

特殊需求是该用例所专有，但无法在用例的事件流文本中较容易或较自然地进行说明。