作为产品经理，撰写需求文档是一门必须掌握的基本功，那么除了知道需求文档应当包含哪些内容，你知道需求文档究竟应该怎么“写”吗？怎样才能写出一份可以让每个项目成员都能清晰明了得到所需信息的PRD文档呢？一起来看看作者的经验分享。
需求文档是产品经理的基本功，也是产品能力的体现，产品能力行不行看文档就能看出来。
我从实际工作+日常总结，整理了一些自己写PRD的方法，分享给各位，希望能对各位有用~
一、原则与前提在文章开始前，我们简单看下在什么时候用、谁去用，来明确需求文档的书写原则：
产品需求评审的时候看；研发技术方案设计、敲代码的时候看；UI进行界面设计的时候看；测试写测试用例、执行用例的时候看。PRD 文档的目的就是让每个项目成员知道需求为什么做、要做什么、怎么做。
所以可以得到PRD的书写原则有：
有理有据：从项目成员知道为什么做；全面、清晰、准确：让大家知道做什么、怎么做；易读性：让大家方便快捷的理解文档内容。明确了原则，还有2个前提：「需求类型、需求大小」
需求类型有：功能需求、接口需求、性能需求、策略需求、埋点需求、统计需求等等。需求大小：可以是从0-1的大项目，包含上边的所有需求类型，还有就是日常迭代版本的小需求。我们接下来文章内容都是基于以上原则与前提，接下来正文开始~
二、需求文档用啥写我们以终为始，先看需求文档的呈现方式。目前主要有以下2类：
1. Axure一体化需求文档使用Axure将全部需求文档，最终通过Axure打包提供出去。好处是方便查看，看原型的基础上又能看文档说明。但有一种不是很“严肃”的感觉。
2. Word版通过Word进行需求描述，并统一提供。容易留存，也比较正规，在阅读上以文字为主。
具体选择那种方式，可以先看公司要求。
像我之前有公司要求，必须用word，就算是有大量原型的，也只能把页面原型画好，然后再复制到word里，在word写需求内容。
如果没有要求，具体采用的方式可以看不同的需求类型：
如果只涉及到画原型的，可以使用Axure。
如果只有偏后端需求的，逻辑相关的需求，比如说是接口需求、算法需求，并不涉及到前端需求的，我们可以直接使用word写。
如果是做的大项目，同时有功能需求，又有接口需求、算法需求的，我建议都放在一起，比如说都用Axure写需求。
我之前做新项目的时候，同时提供了功能需求的axure文档+word版的接口需求，后来用例评审的时候，测试说不知道word版接口需求，之后我就统一写在axure里了。
三、需求文档包含哪些内容需求有大有小，同样的需求文档也有大有小，小到直接一句话描述，大到上百个原型页面，好几万个字。
一句话的需求我们在这就不说了，我们说下正常的需求文档。
不论是使用Axure还是word，也不论需求大小是什么，PRD文档中一般需要包含以下内容：
1. 文档修改记录需求文档在需求评审、研发、测试过程中一定会改的。
比如说加个限制，补充个遗漏的逻辑等等，不过我们一定要记录下修改内容，并及时更新需求文档、及时同步项目成员。
一般通过表格展示出以下内容：
修改内容：说清楚修改的哪个模块，哪个页面、哪个功能点。当然也可以分成修改模块、修改页面多个列。修改原因：就是为啥要修改，比如说逻辑缺失需要补充等等。修改人：谁改的。修改日期：修改时间。在使用Axure时，我们可以在文档修改记录中加上文本