给出一些重要的依据数据 （譬如通过
某项调研发现存在很大的空间可以提高问题解决率，那么调研的结果应该在此进行表述）
】
3.2 项目预期目标
【明确项目的预期目标，最好有量化的目标值（譬如用来提高问题解决率的 给出预期的解决率的范围或者具体值） 】 4 综合描述 4.1 功能概述
MRD，应该
【对功能做整体性的概要描述， 包括所包含的功能模块及各功能模块的概要描述， 以指出本次的开发重点。如果 MRD需求功能点较少，此项可以裁剪】 4.2 对其它产品的影响
X
X
X
项
目
/
产
品
M
R
D
MRD审核人
重要性 紧迫性 MRD拟制人 MRD提交日期
需求变更控制时间点
【MRD审核人一般是指 MRD拟制人的直接主 管，要求对提交项目成员的 MRD都要进行审 核、签字】 【分高、中、低三级】 【分高、中、低三级】 【MRD的作者，如果是多人共同拟制，也都要 写出来】 【提交 MRD初稿给项目组其他成员的日期】 【在 MRD评审会议上进行讨论给出，可用时间 点，也可用阶段来描述，例如设计阶段之 后，编码阶段之前】
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相关的各种附件，例如模板页面等。如果没有，此项可以裁剪】
XX 有限公司
( 版权所有 , 翻版必究 )
MRD更新时间
MRD修改记录
变更内容
【 MRD进行修 改后提交的日 期】
【MRD变更内容的简要描述，每次 变更 MRD后，将改动地方以颜色标 记出来】
变更提出部门 【需求变更是哪个 部门提出的，例 如： PM、 RD、 Test 、TS、市场部 门等】
变更理由
【提出需 求变更的 理由】
注： MRD提交评审之前的修改也可以记录下来
目录
1 项目背景
【在此简单介绍项目 / 产品产生的背景】 2 名词解释
【对文档中出现的新的名词、 概念或简略语给出定义和解释。 如果没有此项， 可以裁剪】 3 可行性分析 3.1 前期调研信息和数据
【提供前期调研信息和数据作为项目立项的支持，
也可
【包括和该需求相关的假设和依赖， 即本产品和外部系统的接口关系， 或复杂，建议以图形方式进行表示。如果本产品没有外部接口，此项可以裁剪】 5 功能详述
如果接口比较多
5.1 功能需求 5.1.1 功能点 1 5.1.1.1 功能点类型和优先级
【功能点类型有新增、旧有功能升级、 Bugfix 三种类型；优先级分为高、中、低】