市场需求文档(MRD)文档的写作方法.doc

市场需求文档(MRD)文档的写作方法 MRD定义与分类 MRD指Market Requirements Document，简称市场需求文档。 市场需求文档的主要功能是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功。 产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。 产品市场经理（PMM，Product Marketing Manager）负责分析市场变化，通过对市场的分析，MRD指出什么样的新产品、方案和服务可以更好的开拓市场。 通常情况下，产品经理或者技术产品经理会将在MRD的基础上完成PRD（Product Requiremnets Document），技术团队应用PRD开发产品。 在百度的ECOM PM部门，MRD要分为给RD/QA看和给业务部门看的两种。 给工程、测试、设计看的MRD是他们的输入信息和测试对象。给业务部门看的MRD，最主要是因为MRD里面的功能实现后，会对客户产生影响，所以必须确认业务部门知晓。 MRD基本写法 一般来说，MRD包含“项目背景”“名词解释”“可行性分析”“综合描述”“功能详述”等部分。这里结合不同版本的MRD谈谈MRD的基本写法。 目前看到的几个MRD比较重视功能需求这块。功能需求主要包括功能点类型和优先级/流程图/页面布局/功能点描述等要素。其中优先级和功能描述比较重要，流程图常可省略。 要素1：项目背景要让RD理解。 “具体开发的背景是什么，解决什么问题得写清楚，否则开发人员在不清楚背景的情况下去做，很容易出问题，而且也缺乏参与感。” 事实证明，谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的对工程师很有价值，许多工程师想知道为什么一个产品或特性要开发，谁将使用他们，什么是他们可以另外选择办法。这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。要尽可能的（在MRD中）包含这些信息。不一定要很详细，只要包含几个段落就足够了。 要素2：名词解释要确保RD看得明白。 在名词解释这块，“描述的准确性很重要，没有二意性，否则，等RD开发好了以后，才会发现和自己想要的不一样，追溯mrd才发现有歧义。” 要素3：要考虑系统的兼容性等不确定因素，把控风险。 我们应该提前把控风险，不确定性降到最低，并具有良好的沟通和通报意识。例如，当MRD要求的是原来系统的更新，而不是一个全新的，与其他系统没有关联的产品时，应考虑到更新的内容与原来的系统其他部件的接口，以及其他外部系统的兼容。eg：2006年8月3日MRD） 要素4：对于要实现的系统功能要详细分解。 每一步出现什么界面，进行什么操作，下一步又怎么进入什么界面，进行什么操作，都要介绍清楚，这样比较容易让RD明白，也易于实现。（eg：2006年9月4日MRD ） 要素5：在涉及数量关系时，要利用好公式。 要用公式明白地表明变量的关系。对公式里面变量的定义必须清晰无疑义。在列举公式时，需要穷尽所有可能的情况，此外，还需要列举注意事项，澄清可能存在的误区。在增加QA时，要把提问的问题写清楚。（eg：2006年8月3日写MRD）MRD里面的数据来源最好有附表，这样比较清楚明白。（eg：2006年9月4日MRD） 要素6：要区分功能需求的优先级。 通常来说，工程师团队不一定能全部实现MRD里包括的所有特性的没有删减的项目。当出现需要决定取舍的时候，应该提供一个办帮助让他们决定那些特性要实现那些可以推迟。最好的决定一个已经明确的需求的优先级方法这个需求实现后的好处-包括客户和公司。在实际实践中，最好是和其他多种因素一起综合决定。在学习材料里面的几个MRD里面一个突出的问题是优先级写的都是很高，没有根据第一等级，第二等级这样的区分。（eg：2006年9月4日MRD） 要素7：要积极参加评审鼓励修正。 要让产品经理伙伴和工程师团队评审MRD然后提出反馈意见。保持一个敞开的思想然后在评审反馈的基础上更新MRD。（eg：2006年9月4日MRD） 要素8: 要覆盖非功能性需求 要用功能性需求描述产品的功能，然后用非功能性需求描述系统特性，当写非功能性需求的时候，尽可能的是使他们可度量（可测试）。否则，QA不能测试它们，PM将没有办法知道完成的产品是否已经实现了这些非功能性需求。 要素9：要包含一个术语表 如果MRD使用了新术语或在非通用的地方是使用了常用术语-确保在MRD后面包含一 个术语表。术语表将确保所有读者（有些可能不是技术人员）理解PM的意思是什么 。 要素10：深入分析目标用户群需求，市场发展趋势，竞品，结合自身优势找出制胜点 在学习的历史MRD中，没有包含市场分析和定位，而针对市场做好分析其实是很重 要的一