附录产品需求规格说明书样本.doc

机构图标

{ 项目名称 }

产品需求规格说明书

文件状态：
[√] 初稿
[ ] 正式公布
[ ] 正在修改
文件标识：
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
Function A.2
…
Feature B
Function B.1
Function B.2
…
…

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）对需求承诺之前，该《产品需求规格说明书》必需先经过需求评审。

需求评审汇报摘要
需求文档
输入名称，标识符，版本，作者，完成日期，…
需求评审汇报
输入名称，标识符，评审日期，…

评审结论
[ ] 工作结果合格，“无需修改”或“需要轻微修改但无须再审核”。
[√] 工作结果基础合格，需要作少许修改，以后经过审核即可。
[ ] 工作结果不合格，需要作比较大修改，以后必需重新对其评审。

评审意见

评审小组组员

输入评审小组组员

需求承诺
需求文档
输入名称，标识符，版本，作者，完成日期

用户承诺
承诺…

签字，日期

项目经理承诺
承诺…

签字，日期