文档编号：xxxxxxxxxxxx
<项目名称>
需求规格说明书
<公司名称>
2012年4月
| 主 题 | |||||
| 说 明 | |||||
| 适用对象 | |||||
| 修 订 历 史 | |||||
| 版 本 | 章 节 | 类 型 | 日 期 | 作 者 | 说 明 |
说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；
| 评 审 记 录 | |||
| 角 色 | 签 名 | 日 期 | 说 明 |
目 录
1. 文档介绍
1.1 文档目的
1.2 文档范围
1.3 相关联系人
| 岗位 | 姓名 | 性别 | 联系电话 | 职责 | |
| 甲方 | 直管领导 | ||||
| 项目负责人 | |||||
| 项目联系人 | |||||
| 乙方 | 高级经理 | ||||
| 项目经理 | |||||
| 项目联系人 | |||||
1.4 参考文档
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符] 作者，文献名称，出版单位（或归属单位），日期
例如：
[SPP-PROC-PP] SEPG，需求开发规范，机构名称，日期
1.5缩略语和术语
| 缩写、术语 | 解 释 |
| … |
2. 产品介绍
提示：
（1）说明产品是什么，有哪些功能，什么用途，做什么事情。
（2）介绍产品的开发背景。
3. 面向用户
提示：
- 描述本产品面向的用户（客户、最终用户）的特征，
4. 应用效益评估
（1）说明本产品将给他们带来什么好处？带来多大的应用效益
5. 产品应当遵循的标准或规范
提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。
6 产品范围
提示：阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。
7. 产品中的角色
提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。
| 角色名称 | 职责描述 |
8. 产品的功能性需求
8.1 功能性需求分类
提示：将功能性需求先粗分再细分，下表中的模块 A,功能 A.1等符号应当被替换成有含义的名称。
| 模块类别 | 子模块类别 | 描述 |
| 模块 A | 子模块 A.1 | |
| … | ||
| 模块 B | 子模块 B.1 | |
| … | ||
| 模块 C | 子模块 C.1 | |
| … |
8.2 模块 M
8.2.1总体描述
提示：描述模块的总体功能及作用，
8.2.2信息及流程描述
提示：（1）该模块相关信息的描述（定义）
（2）描述该模块具体的流程
8.2.3数据项描述
| 编号 | 数据项名称 | 数据项类型 | 精度要求 | 验证要求 | 描述 | 数据来源 |
8.2.4数据展示
8.2.5功能结构分解
提示：将功能性需求先粗分再细分，下表中的模块 A,功能 A.1等符号应当被替换成有含义的名称。
| 模块类别 | 功能名称、标识符 | 描述 |
| 子模块 A.1 | 功能点 A.1.1 | |
| … | ||
| 子模块 A.2 | 功能点 A.2.1 | |
| … | ||
| 子模块 A.3 | 功能点 A.3.1 | |
| … |
8.2.6功能描述
8.2.6.1功能
| 名称、标识符 | |
| 功能描述 | |
| 参与角色 | |
| 优先级 | |
| 输入 | |
| 处理过程 | |
| 操作序列 | |
| 输出 | |
| 控制条件 | |
| 补充说明 |
9. 产品的非功能性需求
9.1 用户界面需求
| 需求名称 | 详细要求 |
| … |
9.2 软硬件环境需求
| 需求名称 | CPU | 内存 | 硬盘 | 分辨率 | 浏览器 | …… |
| 系统服务器要求： | ||||||
| 数据库服务器要求： | ||||||
| 客户端配置要求： |
9.3 产品质量需求
| 主要质量属性 | 详细要求 |
| 正确性 | |
| 健壮性 | |
| 可靠性 | |
| 性能，效率 | |
| 易用性 | |
| 清晰性 | |
| 安全性 | |
| 可扩展性 | |
| 兼容性 | |
| 可移植性 | |
| … |
9.4 其它需求
附录：需求确认
提示：需求确认规程请参见SPP-PROC-RM，主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”，规程请参见SPP-PROC-TR。在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。
| 需求评审报告摘要 | |
| 需求文档 | 输入名称，标识符，版本，作者，完成日期，… |
| 需求评审报告 | 输入名称，标识符，评审日期，… |
| 评审结论 | [ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 |
| 评审意见 | |
| 评审小组成员 | 输入评审小组成员 |
| 需求承诺 | |
| 需求文档 | 输入名称，标识符，版本，作者，完成日期 |
| 客户承诺 | 承诺… 签字，日期 |
| 项目经理承诺 | 承诺… 签字，日期 |
514
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
