产品需求规格说明书

项目名称，《产品需求规格说明书》

{ 项目名称 }

产品需求规格说明书

文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改	文件标识：	Company-Project-RD-PRS
	当前版本：	X.Y
	作 者：
	完成日期：	Year-Month-Day

版 本 历 史

版本/状态	作者	参与者	起止日期	备注

目 录

0. 文档介绍 4

0.1 文档目的 4

0.2 文档范围 4

0.3 读者对象 4

0.4 参考文档 4

0.5 术语与缩写解释 4

1. 产品介绍 5

2. 产品面向的用户群体 5

3. 产品应当遵循的标准或规范 5

4. 产品范围 5

5. 产品中的角色 5

6. 产品的功能性需求 6

6.0 功能性需求分类 6

6.m Feature M 6

6.m.n Function M.N 6

7. 产品的非功能性需求 7

7.1 用户界面需求 7

7.2 软硬件环境需求 7

7.3 产品质量需求 7

7.n 其它需求 7

附录A：需求建模与分析报告 8

A.1 需求模型1 8

A.n 需求模型N 8

附录B：需求确认 9

0. 文档介绍

0.1 文档目的

0.2 文档范围

0.3 读者对象

0.4 参考文档

提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：

[标识符] 作者，文献名称，出版单位（或归属单位），日期

例如：

[SPP-PROC-PP] SEPG，需求开发规范，机构名称，日期

0.5 术语与缩写解释

缩写、术语	解 释
…

1. 产品介绍

提示：

（1）说明产品是什么，什么用途。

（2）介绍产品的开发背景。

2. 产品面向的用户群体

提示：

（1）描述本产品面向的用户（客户、最终用户）的特征，

（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？

3. 产品应当遵循的标准或规范

***提示：*阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。

4. 产品范围

***提示：*阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。

5. 产品中的角色

***提示：*阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。

角色名称	职责描述

6. 产品的功能性需求

6.0 功能性需求分类

***提示：*将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。

功能类别	功能名称、标识符	描述
Feature A	Function A.1
	…
Feature B	Function B.1
	…
Feature C	Function C.1
	…

6.m Feature M

提示：此处写一些承上启下的文字。

6.m.n Function M.N

名称、标识符
功能描述
优先级
输入
操作序列
输出
补充说明

……

7. 产品的非功能性需求

7.1 用户界面需求

需求名称	详细要求
…

7.2 软硬件环境需求

需求名称	详细要求
…

7.3 产品质量需求

主要质量属性	详细要求
正确性
健壮性
可靠性
性能，效率
易用性
清晰性
安全性
可扩展性
兼容性
可移植性
…

7.n 其它需求

附录A：需求建模与分析报告

建议用Rational Rose对产品需求进行建模与分析。

A.1 需求模型1

A.n 需求模型N

附录B：需求确认

***提示：*需求确认规程请参见SPP-PROC-RM，主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”，规程请参见SPP-PROC-TR。在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。

需求评审报告摘要
需求文档
需求评审报告
评审结论
评审意见
评审小组成员

需求承诺
需求文档
客户承诺
项目经理承诺

Ó 机构名称，2002	Page 9 of 9

*
需求文档
客户承诺
项目经理承诺

Ó 机构名称，2002	Page 9 of 9