本文主要是介绍CMMI5-09-G-2，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
CMMI5-09-G-2 产品需求规格说明书.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）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。
| 需求评审报告摘要 | |
| 需求文档 | 输入名称，标识符，版本，作者，完成日期，… |
| 需求评审报告 | 输入名称，标识符，评审日期，… |
|
评审结论 | [ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 |
|
评审意见 |
|
|
评审小组成员 |
输入评审小组成员
|
| 需求承诺 | |
| 需求文档 | 输入名称，标识符，版本，作者，完成日期
|
|
客户承诺 | 承诺…
签字，日期 |
|
项目经理承诺 | 承诺…
签字，日期 |
这篇关于CMMI5-09-G-2的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
