软件开发文档：百度产品需求管理文档（MRD）模板.docx

XXX项目/产品MRD

MRD审核人
【MRD审核人一般是指MRD拟制人的直接主管，要求对提交项目成员的MRD都要进行审核、签字】
重要性
【分高、中、低三级】
紧迫性
【分高、中、低三级】
MRD拟制人
【MRD的作者，如果是多人共同拟制，也都要写出来】
MRD提交日期
【提交MRD初稿给项目组其他成员的日期】
需求变更控制时间点
【在MRD评审会议上进行讨论给出，可用时间点，也可用阶段来描述，例如设计阶段之后，编码阶段之前】

百度在线网络技术（北京）有限公司
(版权所有,翻版必究)

MRD修改记录

MRD更新时间
变更内容
变更提出部门
变更理由
【MRD进行修改后提交的日期】
【MRD变更内容的简要描述，每次变更MRD后，将改动地方以颜色标记出来】
【需求变更是哪个部门提出的，例如：PM、RD、Test、TS、市场部门等】
【提出需求变更的理由】

注：MRD提交评审之前的修改也可以记录下来

目 录
1 项目背景 1
2 名词解释 1
3 可行性分析 1
3.1 前期调研信息和数据 1
3.2 项目预期目标 1
4 综合描述 1
4.1 功能概述 1
4.2 对其它产品的影响 1
5 功能详述 1
5.1 功能需求 1
5.1.1 功能点1 1
5.1.2 功能点2 2
5.2 非功能需求 2
6 其它问题描述 2
7 附件 2

1 项目背景
【在此简单介绍项目/产品产生的背景】

2 名词解释
【对文档中出现的新的名词、概念或简略语给出定义和解释。如果没有此项，可以裁剪】

3 可行性分析
3.1 前期调研信息和数据
【提供前期调研信息和数据作为项目立项的支持，给出一些重要的依据数据（譬如通过某项调研发现存在很大的空间可以提高问题解决率，那么调研的结果应该在此进行表述）】

3.2 项目预期目标
【明确项目的预期目标，最好有量化的目标值（譬如用来提高问题解决率的MRD，应该给出预期的解决率的范围或者具体值）】

4 综合描述
4.1 功能概述
【对功能做整体性的概要描述，包括所包含的功能模块及各功能模块的概要描述，也可以指出本次的开发重点。如果MRD需求功能点较少，此项可以裁剪】

4.2 对其它产品的影响
【包括和该需求相关的假设和依赖，即本产品和外部系统的接口关系，如果接口比较多或复杂，建议以图形方式进行表示。如果本产品没有外部接口，此项可以裁剪】

5 功能详述
5.1 功能需求
5.1.1 功能点1
5.1.1.1 功能点类型和优先级
【功能点类型有新增、旧有功能升级、Bugfix三种类型；优先级分为高、中、低】

5.1.1.2 流程图
【如果功能点流程较复杂，可以结合流程图来进行说明。如果流程简单，可以裁剪】

5.1.1.3 页面布局
【由TS或UE或其它部门提供的模板页面，如果没有，此项可以裁剪】

5.1.1.4 功能点1描述
【针对该功能点做详细的描述，确保描述的一致性、无二义性，并尽可能量化功能要求】

5.1.2 功能点2
5.1.2.1 功能点类型和优先级

5.1.2.2 流程图

5.1.2.3 页面布局

5.1.2.4 功能点2描述
……
5.2 非功能需求
【包括性能需求、可维护性需求、可靠性需求、安全性需求等，对各项质量属性的解释说明如下：
性能需求：包括时间特性要求、系统容量要求等；
可维护性：包括易分析性、易变更性等要求；
可靠性：产品在规定条件下使用时保持规定性能水平的能力；
安全性：产品在规定的使用环境中实现可接受风险的能力；
安装性：产品在规定环境中安装卸载的能力；
非功能需求也可以和功能需求合并在一起进行描述。如果没有此项，可以裁剪】

6 其它问题描述
【1、此处应该标明此版本上线后可能带来的风险以及应对措施；2、对其它部门是否有影响，是否涉及广告、ue等非pm和rd部门的工作。如果没有这两项，可以裁剪】

7 附件
【和MRD相关的各种附件，例如模板页面等。如果没有，此项可以裁剪】