产品需求规格说明书模板.docxVIP

机构图标 机构图标 { 项目名称 } 产品需求规格说明书 文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改 文件标识： Company-Project-RD-PRS 当前版本： X.Y 作 者： 完成日期： Year-Month-Day 机构公开信息 机构公开信息 项目名称 项目名称，《产品需求规格说明书》 Page Page PAGE 2 of 9 机构名称，2002 版 本 历 史 版本 版本/状态 作者 参与者 起止日期 备注 目 录 0. 文档介绍 4 0.1 文档目的 4 0.2 文档范围 4 0.3 读者对象 4 0.4 参考文档 4 0.5 术语与缩写解释 4 TOC \o 1-3 \h \z \u 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. 产品的非功能性需求 6 7.1 用户界面需求 6 7.2 软硬件环境需求 7 7.3 产品质量需求 7 7.N 其它需求 7 附录 A：需求建模与分析报告 8 A.1 需求模型 1 8 A.N 需求模型 N 8 附录 B：需求确认 9 文档介绍 文档目的 文档范围 读者对象 参考文档 提示： 列出本文档的所有参考文献（可以是非正式出版物） ，格式如下： [标识符] 作者，文献名称，出版单位（或归属单位） ，日期例如： [SPP-PROC-PP] SEPG ，需求开发规范，机构名称，日期 术语与缩写解释 缩写、术语 缩写、术语 解 释 产品介绍 提示： 说明产品是什么，什么用途。 介绍产品的开发背景。 产品面向的用户群体 提示： 描述本产品面向的用户（客户、最终用户）的特征， 说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？ 产品应当遵循的标准或规范 提示： 阐述本产品应当遵循什么标准、规范或业务规则（ Business Rules ），违反标准、规范或业务规则的产品通常不太可能被接受。 产品范围 提示： 阐述本产品“适用的领域”和“不适用的领域” ，本产品“应当包含的内容”和 “不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情； （ 3）有助于控制需求的变更。 产品中的角色 提示： 阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。 角色名称 角色名称 职责描述 产品的功能性需求 6.0 功能性需求分类 功能类别功能名称、标识符描述Feature AFeature BFeature CFunction A.1 功能类别 功能名称、标识符 描述 Feature A Feature B Feature C Function A.1 … Function B.1 … Function C.1 … 6.m Feature M 提示：此处写一些承上启下的文字。 6.m.n Function M.N 名称、标识符功能描述优先级 名称、标识符功能描述优先级 输入操作序列 输出 补充说明 …… 产品的非功能性需求 用户界面需求 需求名称 需求名称 详细要求 … … 软硬件环境需求 需求名称 需求名称 详细要求 … 产品质量需求 主要质量属性 主要质量属性 详细要求 正确性 健壮性可靠性 性能，效率易 用 性 清 晰 性 安 全 性 可扩展性兼 容 性 可移植性 … 7.n 其它需求 附录 A：需求建模与分析报告 建议用 Rational Rose 对产品需求进行建模与分析。 A.1 需求模型 1 A.n 需求模型 N 附录 B：需求确认 提示： 需求确认规程请参见 SPP-PROC-RM ，主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式” ，将产生一份“需求评审报告” ，规程请参见 SPP-PROC-TR 。在获取责任人（ Stakeholders ）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。 需求文档需求评审报告 评审结论 需求评审报告摘要 输入名称，标识符，版本，作者，完成日期， … 输入名称，标识符，评审日期， … [ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核” 。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 评审意见 评审小组成员 输入评审小组成