百度产品需求管理文档模板.docxVIP

___项目/产品MRD MRD审核人 【MRD审核人一般是指MRD拟制人的直接主管，要求对提交项目成员的MRD都要进行审核、签字】 重要性 【分高、中、低三级】 紧迫性 【分高、中、低三级】 MRD拟制人 【MRD的作者，如果是多人共同拟制，也都要写出来】 MRD提交日期 【提交MRD初稿给项目组其他成员的日期】 需求变更控制时间点 【在MRD评审会议上进行讨论给出，可用时间点，也可用阶段来描述，例如设计阶段之后，编码阶段之前】 xx技术（xx）公司 (版权所有,翻版必究) MRD修改记录 MRD更新时间 变更内容 变更提出部门 变更理由 【MRD进行修改后提交的日期】 【MRD变更内容的简要描述，每次变更MRD后，将改动地方以颜色标记出来】 【需求变更是哪个部门提出的，例如：PM、RD、Test、TS、市场部门等】 【提出需求变更的理由】 注：MRD提交评审之前的修改也可以记录下来 目 录 TOC \o 13 \h \z 1 项目背景 PAREF _Toc130095345 \h 1 2 名词解释 PAREF _Toc130095346 \h 1 3 可行性分析 PAREF _Toc130095347 \h 1 3.1 前期调研信息和数据 PAREF _Toc130095348 \h 1 3.2 项目预期目标 PAREF _Toc130095349 \h 1 4 综合描述 PAREF _Toc130095350 \h 1 4.1 功能概述 PAREF _Toc130095351 \h 1 4.2 对其它产品的影响 PAREF _Toc130095352 \h 1 5 功能详述 PAREF _Toc130095353 \h 1 5.1 功能需求 PAREF _Toc130095354 \h 1 功能点1 PAREF _Toc130095355 \h 1 功能点2 PAREF _Toc130095356 \h 2 5.2 非功能需求 PAREF _Toc130095357 \h 2 6 其它问题描述 PAREF _Toc130095358 \h 2 7 附件 PAREF _Toc130095359 \h 2 项目背景 【在此简单介绍项目/产品产生的背景】 名词解释 【对文档中出现的新的名词、概念或简略语给出定义和解释。如果没有此项，可以裁剪】 可行性分析 前期调研信息和数据 【提供前期调研信息和数据作为项目立项的支持，给出一些重要的依据数据（譬如通过某项调研发现存在很大的空间可以提高问题解决率，那么调研的结果应该在此进行表述）】 项目预期目标 【明确项目的预期目标，最好有量化的目标值（譬如用来提高问题解决率的MRD，应该给出预期的解决率的范围或者具体值）】 综合描述 功能概述 【对功能做整体性的概要描述，包括所包含的功能模块及各功能模块的概要描述，也可以指出本次的开发重点。如果MRD需求功能点较少，此项可以裁剪】 对其它产品的影响 【包括和该需求相关的假设和依赖，即本产品和外部系统的接口关系，如果接口比较多或复杂，建议以图形方式进行表示。如果本产品没有外部接口，此项可以裁剪】 功能详述 功能需求 功能点1 功能点类型和优先级 【功能点类型有新增、旧有功能升级、Bugfi_三种类型；优先级分为高、中、低】 流程图 【如果功能点流程较复杂，可以结合流程图来进行说明。如果流程简单，可以裁剪】 页面布局 【由TS或UE或其它部门提供的模板页面，如果没有，此项可以裁剪】 功能点1描述 【针对该功能点做详细的描述，确保描述的一致性、无二义性，并尽可能量化功能要求】 功能点2 功能点类型和优先级 流程图 页面布局 功能点2描述 …… 非功能需求 【包括性能需求、可维护性需求、可靠性需求、安全性需求等，对各项质量属性的解释说明如下： 性能需求：包括时间特性要求、系统容量要求等； 可维护性：包括易分析性、易变更性等要求； 可靠性：产品在规定条件下使用时保持规定性能水平的能力； 安全性：产品在规定的使用环境中实现可接受风险的能力； 安装性：产品在规定环境中安装卸载的能力； 非功能需求也可以和功能需求合并在一起进行描述。如果没有此项，可以裁剪】 其它问题描述 【1、此处应该标明此版本上线后可能带来的风险以及应对措施；2、对其它部门是否有影响，是否涉及广告、ue等非pm和rd部门的工作。如果没有这两项，可以裁剪】 附件 【和MRD相关的各种附件，例如模板页面等。如果没有，此项可以裁剪】