00产品需求规格说明书模板.docx
《00产品需求规格说明书模板.docx》由会员分享,可在线阅读,更多相关《00产品需求规格说明书模板.docx(8页珍藏版)》请在冰点文库上搜索。
00产品需求规格说明书模板
机构图标
{项目名称}
产品需求规格说明书
文件状态:
[√]草稿
[]正式发布
[]正在修改
文件标识:
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
B.1需求标题19
B.n需求标题N9
附录C:
需求确认10
0.文档介绍
0.1文档目的
说明编写这份软件需求说明书的目的,指出预期的读者范围。
0.2文档范围
说明:
a.待开发的软件系统的名称;
b.说明软件将干什么,如果需要的话,还要说明软件产品不干什么;
c.描述所说明的软件的应用。
应当:
1)尽可能精确地描述所有相关的利益、目的、以及最终目标。
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:
需求建模与分析报告
建议用RationalRose对产品需求进行建模与分析。
A.1需求模型1
A.n需求模型N
附录B:
用户需求调查报告
建议用RationalRose对产品需求进行建模与分析。
B.1需求标题1
B.n需求标题N
附录C:
需求确认
提示:
需求确认规程请参见SPP-PROC-RM,主要分两步:
(1)需求评审,
(2)需求承诺。
对需求的评审应当采用“正式技术评审方式”,将产生一份“需求评审报告”,规程请参见SPP-PROC-TR。
在获取责任人(Stakeholders)对需求的承诺之前,该《产品需求规格说明书》必须先通过需求评审。
需求评审报告摘要
需求文档
输入名称,标识符,版本,作者,完成日期,…
需求评审报告
输入名称,标识符,评审日期,…
评审结论
[]工作成果合格,“无需修改”或者“需要轻微修改但不必再审核”。
[√]工作成果基本合格,需要作少量的修改,之后通过审核即可。
[]工作成果不合格,需要作比较大的修改,之后必须重新对其评审。
评审意见
评审小组成员
输入评审小组成员
需求承诺
需求文档
输入名称,标识符,版本,作者,完成日期
客户承诺
承诺…
签字,日期
项目经理承诺
承诺…
签字,日期