提到需求文档，作为产品小白也应该会有些熟悉，作为产品经理必备三大文档之一（另外两个是BRD、MRD），日常工作接触频率肯定会很高。
PRD文档通常有WORD版和原型版，前者顾名思义。后者则是在原型的基础上加入功能需求，给研发、设计人员更加直观的体现。
本文结合自身经历过的一个WORD版PRD文档，从几个角度介绍一下PRD文档如何编写，不同公司不同项目所应用的PRD文档内容可能有所不同，理解PRD文档的本质，具体问题具体分析。
结合思维导图，对产品需求文档的整体框架进行了一个整理（再次重申，不同产品框架会有所不同）
一、文档描述
1.文档目的
PRD文档的主要面向群体是研发，是在BRD、MRD文档之后，对产品需求的进一步细化，通过结构化的语音让研发更容易理解产品需要做的内容是什么。
2.产品目标
产品希望达到什么目标，满足用户什么场景下的什么需求。其实还是从用户、需求、场景的角度来阐述产品的目标。
3.术语缩写
产品的业务逻辑上有很多术语，也许是技术研发人员不了解的，通过术语缩写的解释，让研发人员对产品的业务逻辑更加明确，不会影响产品研发进度和内容。
4.版本状态
通过版本状态，修订人以及修订内容，让以后接触的人可以快速了解产品情况，同时对于产品需求变更有更明确的认知。
二、产品描述
1.整体流程
对产品的整体信息架构以及产品的业务流程进行梳理。
产品信息架构图，明确产品的信息架构。
业务流程图，明确业务流程，区分不同角色的业务操作。
2.需求描述
针对业务流程，进行具体需求描述，细化业务需求。
3.角色区分
通过上图可以发现，有些业务流程中会出现多用户多角色的情况。针对不同的角色在业务流程中的不同定位，对用户区分后，对具体角色进行不同需求描述。
具体角色的业务操作
三、功能描述
1.业务流程
通常一个产品会包含多个功能模块，针对每一个细化的功能模块，又有具体的业务流程。
2.界面原型
关于产品原型，我曾经看到过关于草图、原型图、高保真原型图的争论，其实在我看来并不一定要每页做到高保真原型图的境界。原型图做好在和研发、设计沟通过程中也会涉及到变动。在我看来，只要能表达清楚业务逻辑、页面流程、功能描述即可。不要一味追求高保真而忘记注重产品本身。
本文中设计的PRD文档是一个J2EE的ERP系统，在项目前期没有做原型，然后项目因为成本问题最后落地，所以没有原型图展现。
3.业务说明
针对复杂的业务逻辑和业务流程，对角色进行区分，针对不同角色的操作进行需求描述。本文中基本所有功能模块都涉及到多人协作的业务流程，所以对角色的区分以及对不同角色的不同需求进行了详细描述。
4.字段说明
字段说明涉及研发人员在进行产品开发时的细节问题，一般会对数据字典，字段的类型，范围进行说明，方便研发人员进行产品研发。
四、非功能需求
根据不同产品及公司需要，这部分内容可能会有所不同。本文中实战案例中非功能需求包括安全性、统一性、实用性等原则。
五、其他
六、实战案例
本文中的截图以及产品需求文档，是一个真实案例。本人在深圳对某物流公司进行2个月的深度调研，通过和客户讨论、现场观察实际操作人员行为、征求业务人员意见等多种方式进行需求收集、整理、分析，最后整合出了一份长达100页的需求文档。该项目涉及功能模块很多，任何一个功能模块拿出来都可以形成一个功能产品。所以在参考的过程中，可以有选择的看。
七、总结
需求文档的撰写往往依据BRD、MRD文档的相关信息，对之前获取的需求、业务逻辑等进行分析整理，从而形成的一份提供给研发、设计人员参考的PRD文档。在编写过程中一定要根据具体情况具体分析，形式不重要，只要研发能看懂，文档能体现出来产品的整体需求，就是一份好的产品需求文档。
