文章有点长，字字是干货，建议收藏，需要文档可评论“需求开发标准化文档”，觉得还不错的可以用发财的小手点个免费的关注，小编更加有动力整理分享。

目录

1 目的

定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。

2 适用范围

2.1 机构

研发中心技术部门及PMO、技术拓展部。

2.2 业务

提供需求工程的过程标准。

3 名词术语

3.1 RDM（Request Development and Management）：需求开发与管理。

3.2 SRS(Software Requirement Specification)：软件需求规格说明书。

3.3 客户(Customer)：开发产品订单的付费方

3.4 最终用户(End User)：最终真正操作软件的用户

3.5 用户需求：指直接来自于客户或者用户的原始需求

3.6 产品需求：指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求

3.7 CCB(Change Control Board)：变更控制委员会。CCB的组长一般为适用机构的领导，成员一般为PMO及适用机构领导制定的某些特定人员，对于子部门级别的项目，CCB可直接由子部门的经理担任组长，由PMO担任组员。

4 概述

项目在工程活动的开始，首先要进行需求开发。后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最高的，而由于需求的抽象性，需求开发人员（系统分析员）既需要有过硬的专业知识，还要具备较强的交流、沟通能力，所以需求开发也是最难的。任何项目，需求在整个工程开发过程中必定会发生变化，因此对需求变更的控制，即需求管理必不可少。

5 过程定义

5.1 需求开发与管理

需求开发与管理流程图

5.1.1 角色与职责

5.1.2 入口准则

◆ 项目已经启动；

◆ 对于合同项目，合同已经签订。

5.1.3 输入

◆ 项目计划

5.1.4 过程活动

1)、需求调查

获取用户（客户和最终用户）的需求信息。调查需求的方式包括：

◆ 与用户交谈，向用户提问题

◆ 参观用户的工作流程，观察用户的操作

◆ 向用户群体发调查问卷

◆ 与同行。专家交谈，听取他们的意见

◆ 分析已经存在的同类软件产品，提取需求

◆ 从行业标准、规则中提取需求

◆ 从internet上搜查相关资料

在需求调查完成之后，需要生成需求搜集的文档，文档形式可以自定义，但搜集的需求形成的文档需要由项目经理组织进行非正式的评审，要尽最大努力使搜集到的需求正确无误的反映用户的真实意愿。

《用户需求说明书》需要得到用户的确认和承诺。

2）、需求分析及需求定义

需求分析员对搜集到的用户需求进行分析细化，以便产生详细的产品需求。需求分析的主要方法有：

问答分析法。常见的问题包括：

◆ 需求是否存在二义性

◆ 需求文档上下文是否有矛盾

◆ 需求是否完备

◆ 需求是必要的吗

◆ 需求可实现吗

◆ 需求可验证吗

◆ 需求的优先级确定了吗

建模分析法。这种分析法需要需求分析员有较高的水平，因为建模分析的技术难度比较高。针对目前情况，不推荐使用。

同时撰写产品需求规格说明书。其内容主要包括：

◆ 产品介绍

◆ 描述用户群体的特征

◆ 定义产品的范围

◆ 阐述产品应当遵循的标准和规范

◆ 定义产品中的角色

◆ 定义产品的功能性需求

◆ 定义产品的非功能性需求，如用户需求、软硬件环境、质量等需求

3）、评审及确认需求

项目经理组织对《产品需求规格说明书》进行正式评审，同时要取得开发方和客户方的书面承诺。

4）、需求跟踪

将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发。

5）、需求变更申请

项目经理撰写需求变更申请单。需求变更说明书包括：变更原因；变更的内容；此变更对项目造成的影响。

6）、审批需求变更申请

高层经理和客户共同进行需求变更申请的审批。

7）、变更需求文档

需求分析员根据变更申请对用户需求说明书和产品需求规格说明书进行变更处理，模板参见“变更控制与管理”过程域的变更单模板。

5.1.5输出

◆ 用户需求调查报告

◆ 用户需求说明书；

◆ 产品需求规格说明书；

◆ 需求跟踪矩阵；

◆ 需求变更申请单；

5.1.6 出口准则

◆ 产品需求规格说明书通过审批；

◆ 需求管理贯穿整个项目生命周期，直到项目结项；

5.1.7 过程度量

1）度量人员对以下数据进行度量

工作量。

◆ 进度。

◆ 需求变更的次数。

◆ 产品需求规格说明书的规模。

◆ 评审需求发现的缺陷。

5.1.8 确认与验证

◆ QA对需求开发与管理过程及其产生的产品的规范性进行检查；

◆ 项目经理对需求开发与管理过程进行监督，对产生的产品进行审查；

◆ 用户确认用户需求说明书及其变更。

◆ 高层经理及客户对产品需求规格说明书进行确认；

◆ 高层经理及客户对需求变更申请单进行审批；

6 规程

无

7 标准与规范

7.1 《需求开发与管理检查单》

8 裁剪指南

1）、用户以规范形式提供了需求的情况下可裁剪《用户需求调查报告》；

9 模板与表格

9.1 《用户需求调查报告模板》

9.2 《用户需求说明书模板》

9.3 《产品需求规格说明书模板》

9.4 《软件需求跟踪矩阵表单模板》

10 实施指导

“需求开发与管理”是CMMI中的工程类过程。以下是对“需求开发与管理”过程实施时的进一步指导说明：

1）、管理配置项

对“需求开发与管理”过程产生的所有有价值的文档应纳入配置管理的适当层次。主要文档示例如下：

◆ 用户需求说明书

◆ 产品需求规格说明书

◆ 需求跟踪矩阵

◆ 需求变更申请单

2）、培训人员

组织应该对所有或部分参与“需求开发与管理”过程的相关人员进行培训。主要培训专题示例如下：

◆ 需求分析方法

3）、使项目干系人适时介入

◆对于需求调查的用户需求要得到所有项目干系人的共同理解和承诺。

4）、QA根据计划和控制“需求开发与管理”过程，并且采取适当的纠正措施。

5）、项目经理在执行“需求开发与管理”过程中，应注意收集对过程的改进建议，并提交给组织EPG。

6)、评审及确认需求时，如客户及最终用户纳入存在困难，可以在征求高层经理的同意下，由高层经理代表客户需求，其他指定人员代表最终用户需求进行评审。

附录一：需求开发与管理检查单

需求开发与管理检查单

附录二：需求跟踪矩阵表单模板

需求跟踪矩阵表单模板

附录三：需求调查报告模板

【项目(产品)名称】

常见需求调查方式有：

1. 与用户交谈，向用户提问题。

2.参观用户的工作流程，观察用户的操作。

3. 向用户群体发调查问卷。

4.与同行、专家交谈，听取他们的意见。

5.分析已经存在的同类软件产品，提取需求。

6.从行业标准、规则中提取需求。

7.从Internet上搜查相关资料。

1 需求标题1

2 需求标题N

附录四：用户需求说明书

目录二

1引言

1.1 编写目的

1.2 范围

1.3 术语与缩写解释

1.4 参考资料

2 产品介绍

【提示：

（1）说明产品是什么，什么用途。

（2）介绍产品的开发背景。】

3 产品面向的用户群体

提示：

（1）描述本产品面向的用户（客户、最终用户）的特征，

（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？

4 产品应当遵循的标准或规范

提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。

5 产品的功能性需求

5.1 功能性需求分类

提示：将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。

按照上面划分的功能下面具体填加标题描述

5.2 Feature A

提示：此处写一些承上启下的文字。

5.2.1 Function A.1

功能描述：

6 产品的非功能性需求

6.1 用户界面需求

6.2 软硬件环境需求

6.3 产品质量需求

6.4 其它需求