（产品管理）附录G-产品需求规格说明书.docx

(产品管理)附录G-产品需求规格说明书

{项目名称}

产品需求规格说明书

文件状态：

[√]草稿

[]正式发布

[]正于修改

文件标识：

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.MFEATUREM6

6.m.nFunctionM.N6

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

7.1用户界面需求7

7.2软硬件环境需求7

7.3产品质量需求7

7.N其他需求7

附录A：需求建模和分析方案8

A.1需求模型18

A.N需求模型N8

附录B：需求确认9

0.文档介绍

0.1文档目的

0.2文档范围

0.3读者对象

0.4参考文档

提示：列出本文档的所有参考文献(能够是非正式出版物)，格式如下：[标识符]作者，文献名称，出版单位(或归属单位)，日期

例如：

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

0.5术语和缩写解释

缩写、术语

解释

…

1.产品介绍

提示：

(1)说明产品是什么，什么用途。

(2)介绍产品的开发背景。

2.产品面向的用户群体

提示：

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

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

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

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

4.产品范围

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

5.产品中的角色

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

角色名称

职责描述

6.产品的功能性需求

6.0功能性需求分类

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

功能类别

子功能

FeatureA

FunctionA.1

FunctionA.2

…

FeatureB

FunctionB.1

FunctionB.2

…

…

6.mFeatureM

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

6.m.nFunctionM.N

名称、标识符

功能描述

优先级

输入

操作序列

输出

补充说明

……

7.产品的非功能性需求

7.1用户界面需求

需求名称

详细要求

…

7.2软硬件环境需求

需求名称

详细要求

…

7.3产品质量需求

主要质量属性

详细要求

正确性

健壮性

可靠性

性能，效率

易用性

清晰性

安全性

可扩展性

兼容性

可移植性

…

7.n其他需求

附录A：需求建模和分析方案

建议用Rationa1Rose对产品需求进行建模和分析。

A.1需求模型1

A.n需求模型N

附录B：需求确认

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

需求评审方案摘要

需求文档

输入名称，标识符，版本，作者，完成日期，…

需求评审方案

输入名称，标识符，评审日期，…

评审结论

[]工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。[√]工作成果基本合格，需要作少量的修改，之后通过审核即可。[]工作成果不合格，需要作比较大的修改，之后必须重新对其评审。

评审意见

评审小组成员

输入评审小组成员

需求承诺

需求文档

输入名称，标识符，版本，作者，完成日期

客户承诺

承诺…

签字，日期

项目经理承诺

承诺…

签字，日期