“文章本天成，妙手偶得之。”写需求文档不需要“妙手”，但需要思路清晰、叙述清楚。写的人要能把需求写透，看的人才能看懂，一篇好的需求文档能答疑解惑，一篇坏的需求文档会让人误入歧途。
有一天，一个朋友打电话给我。
朋友：“上回听说你们公司是做产权的，我这有诉讼相关的项目，你们能做吗？”
老吴：“公司现在不打算接项目了，以做产品为主。”
朋友：“你在公司负责什么啊？”
老吴：“我是产品经理，负责公司的产品。”
朋友：“哦，做需求的啊，知道了。
老吴：“……”
每个公司对产品经理的定位都不同，有的产品经理负责产品的需求，有的产品经理负责产品的设计，有的产品经理负责整个产品线。不论给产品经理的定位是什么，需求对产品经理来说都是必做的功课，那么，写需求文档就成了我们的家常便饭。对于不同的大厨来说同样做一道家常菜，有的做的色、香、味俱全，吃起来入口绵长、滑嫩可口；有的做的熟悉亲切、感人落泪如妈妈的味道；有的做的外焦里嫩、清香扑鼻；但也有的做的惨不忍睹、不忍直视。做产品也是一样，不同的人对产品有着不同的理解，就算理解一样，写出来的产品文档也会不同。
商业需求文档BRD、市场需求文档MRD、产品需求文档PRD、技术需求文档（需求规格说明书）。
商业需求文档BRD。它是一种商业的需求描述，里面要体现产品的市场分析、规划、投入、盈利预测等信息，是为了让决策层便于分析、决策是否开发此产品的依据，商业需求文档更像是商业计划书，它是需求阶段最早需求提供的文档，文档一般不长，也可以是PPT的方式展示。
市场需求文档MRD。市场需求文档是站在市场、用户的角度，多描述用户、购买者、客户的需求，它是承上启下的文档，对技术需求文档的编写起到一定的指导作用。文档中多会加入原型的形式将产品具体化，便于文档的解释说明。
产品需求文档PRD。产品需求文档多是站在业务的角度，让所有的项目干系人都能够了解、理解产品而编写的，此文档的阅读者为产品的管理层、需求人员、设计人员、技术人员、测试人员、市场人员、运营人员。
需求规格说明书，此文档是站在技术角度而编写，文档中不仅要描述产品的业务需求，还要描述产品的技术指标和技术参数，是架构设计、技术开发的指导性文档。为了便于说明需求，文档中会加入流程图、序列图、原型图等设计模型，更好的让技术人员理解、指导技术人员开发。
根据公司情况不同，PRD、MRD、BRD文档不一定都需要编写，这要看各公司的具体情况。我认为让非技术人员理解产品一定要有产品需求文档，指导技术开发一定要有需求规格说明书。产品经理要写这么多文档，需要贯彻产品的整个需求阶段，那么产品经理一定要是一名好的方案编写高手。
我们了解了各类文档，也知道了他们的价值和作用，那么，文档的编写需要注意哪些方面呢？
正确性
我们经过调研、分析得到需求后，整理成文档，以便于信息的保存与传播。需求在脑子里的时可能是清晰的，但写出来后就不一定清晰了。原因是，你脑子里想的可能是Ａ，写出来后可能是Ａ１，但你还以为写的是Ａ。错误的原因有很多可能是你的文笔不好、也可能是疏忽、还可能是你没有把需求写透，还有一种可能就是你当初就没有正确的理解需求。
全面性
我们在获取需求时尽量全面的了解问题，得到真实、准确、完整的需求，只有获取的信息全面写出来的需求才可能全面。另外，就算获取需求全面了，有时写需求时也难免有所疏漏。所有，在编写需求时要考虑全面，建议从大到小、从粗到细进行梳理，从平台、子系统、模块、功能点一条一条线进行梳理，当所有的流程都遍历完成后需求文档也就整理完成了。
可验证性
需求文档中所描述的需求应该是可验证的，如商业文档的商业数据的出处。对于技术文档来说，功能要有输入项、输出项、事前描述、约束条件，当一切条件都满足后，输入什么样的数据应该输出什么样的结果。对于市场需求文档，要体现用户的逻辑思维，为什么用户会用这样的功能，依据是什么？是经过推理、还是心理暗示？文档中的信息应该是可推敲、可验证的，只有保证数据及信息来源的正确性，才能更好的把握产品。另外，只有需求文档各接口、属性、参数具备可验证性，测试人员才好根据需求文档编写测试用例。
无二义性
中文有多音、多义字，英文也有一个单词代表多种含义的情况，因为文档主要是文字描述，在文档中难免有二义性的情况。在文档的描述中一定要保证含义清晰，表达准确。还有一种情况，就是有时产品经理自己对产品需求理解模糊，思考不深刻，在写文档时就不可能保证文档的准确性。
必要性
不同的需求文档是站在不同的角度上思考问题的，当我们从多重角度分析问题时，会对产品有更深刻的理解，哪些需求是必要的，哪些需求是次要的，哪些需求是可要可不要的。当一个产品中充斥着非必要性需求，就是喧宾夺主，有时要该“砍”则“砍”，壮士断臂。
优先级
在产品中加入优先级，有助于让相关人理解产品中各功能的重要度，在必要时（如开发时间紧张时）也可以考虑优先完成哪些功能。另外，在产品文档中加入优先级，也便于产品的版本升级。但优先级，我认为不用分得太细，只需要加上“高”、“中”、“低”就好了。
以上问题都是在做产品文档时需要注意的问题，做为产品经理，我们在获取、分析需求时，一定要对需求准确把握，不可以有理解模糊、分析不透彻的情况。否则，在编写文档时就会出现更多的问题，当你再折回去重新分析需求时会浪费更多的时间和精力。需求文档的编写是一个很吃功力的事情，难的不是写，而是想，只有想透了写其它是件很容易的事。就跟写文章一样，在写前在大脑中会想好题纲，写时思路就会非常清晰。建议产品经理，在写文档前一定要把需求想清楚，也可以借助一些模型工具，如VISIO、AXURE等，通过模型会有利于帮助我们整理思路、梳理需求。
需求文档的编写是一件很费时、费力的事情，大多数公司都会认真编写需求文档吗？需求文档的下场一般会是什么样的呢？
一、在很多公司，产品的前期和开发阶段，文档都会非常重视，当产品一旦进入开发后期或完成后，文档就会束之高阁，经过多轮的产品迭代后，文档与产品间就会完全脱节，这就是需求失败的信号。
二、许多企业为了赶项目工期，前期只是有简单的设计就进入开发阶段，而且对外声称自己是“敏捷开发”，敏捷成为不用写文档的借口。实际，在开发阶段，需求文档是非常重要的，它将有效的指导开发工作，让技术人员按照统一的标准实施，它将有利于让技术人员统一思想，开发时也不用频繁的进行沟通，前期需求阶段多思考后开发阶段就可以节省大量的时间。敏捷只适用于小团队作战，在大项目中，开发文档将保证所有的技术人员按照有序的、准确的方向前行。
三、很多公司为了应付客户或领导，在产品开发完成后补文档，这时编写的文档基本上没有什么价值了，真正要做好产品，需求文档的编写是成功的必要条件。
需求文档应该是共享的，所有项目参与人都可见，一方面有利于干系人理解产品，还有利于其它人提出不同的意见和见解，帮助产品优化。在项目中尽量用一些版本管理工具来管理文档，如CVS、VSS。这些版本管理工具可以设置权限，哪些人可以看哪些文档，哪些人可以修改哪些文档，在版本管理工具中都可以实现。另外文档要可维护，随着需求的变更需求文档也会跟着变化，要保证需求文档与产品功能一致。另外，为了保证产品文档的风格一致，尽量让专人负责文档的维护工作。
