需求文档撰写方法论
作为刚刚开始接触产品经理的人，都知道PRD。而要写好PRD需要不断的打磨与锻炼。目前刚起步，主要做了执行的工作，查阅了一些前人的分享，现结合自己的经验整理出来，一方面，以自己输出的方式，加强自己对需求文档的理解，一方面与需要的人分享交流。
写需求文档，就像拍照一样，需要找好角度。目前大部分的PRD都是从战略和战术的角度去分析。
战略，是我们为什么要做这个需求，我们满足的痛点是什么。他的市场规模有多大。战略决定了我们到底做不做这个需求。他的面向对象是管理人员和高层。
战术，则是怎么实现需求。我们到底怎么做，做什么，才能实现这个需求，重点在执行。面向对象是设计师、前端、后端、测试以及运维等。作为新人，我先从战术的角度，讲几点方法论。从结构上到细节的分析一下需求文档要怎么写。
1、确定需求受众
写文档，就像做产品需求分析一样，我们一样要先了解我们的目标用户，他们在意的是什么，就给他们什么。需求的受众主要是技术相关人员，包括UI设计、前端、后端开发、测试、运营维护人员等。
-设计，指UI与UE设计，包括视觉设计与交互设计。设计需要知道业务流程，及前端的基本规则，便于将每个页面更user friendly的可视化。
-前端，指使用CSS和Html等语言实现页面的展示，静态的页面。设计需要知道业务流程、包括在所有的情况下的界面展示，及交互效果，以便他们实现静态页面。
-后端，指实现前端数据的动态展现，进行业务逻辑的判断。后端需要知道数据从哪里获取，从接口调取还是同步到本地再进行展示。数据的出参入参，业务逻辑的判断。
-后台，指数据库的管理以及接口的封装等。需要知道数据库的字段需求，便于数据字段的增减以及封装接口。
-运维，包括数据的埋点，为后续改善，获取数据支持。
不同的公司对于技术人员的划分以及定义可能也是不同的，此处仅仅是根据目前我工作中的总结得出的受众划分。
2、明确业务逻辑
按照工作的分工，可以判断不同职位的人关注的重点不同。但是有一点相同的是，业务的整体流程和结构是所有人都必须了解的。因此，在需求的开头，一定要写清楚整体的结构以及流程。产品的结构可以使用mind manager等工具，制作思维导图完成。业务的流程主要是从业务开始到结束的步骤概述。对于多个角色或者多个系统的，可以使用泳道图[1]，对于单个角色可以直接使用流程图，活动图[2]。同时可以配合使用状态图[3]和顺序图[4]。这里强调一点很多新人容易犯的错误，对于这么多工具常常不知道使用哪个比较好，其实只要明确我们的目的是让所有涉及项目的成员了解业务逻辑，而所有类型的图表主要是为了说明产品逻辑和业务流程，只要说明清楚，形式不是重点。
3、用例描述
用例描述是从人和系统的旁观者来描。此处详述一下用例描述。要具体的对每一个功能，每一步流程具体的说明使用场景、前后置条件、界面数据规则、状态逻辑、交互规则。使用场景、前后置条件和数据规则、交互规则是一定需要的，对于简单的页面，可能不会有状态变化。
用例描述模板
1）使用场景是帮助所有人理解此页面到底在什么地方出现，用户进入此页面的目的，我们设计此页面的目的，我们是否希望用户长时间留在此页面。
2）前置规则主要是针对同一个页面，可能会有不同的渠道进入，不同渠道进入可能可以展现的是不同的。需要明确进入页面的渠道、用户的身份权限。后置规则是在正常流程下，执行完此流程后的结果。比如，购买流程完成，结果是产品购买成功提示，订单生成。
3）界面数据规则主要是指数据的显示规则。a.不同角色、不同状态下，显示规则不同。比如登录与未登录情况。需要明确各个角色的权限下数据的显示规则。b.默认数据。同一个要素，可能有多个数据对应时，要写明默认状态下，数据的显示规则。比如默认价格的显示。还有可能网络状况不好，向后台请求不到数据，也要将默认图片打包进入安装包，显示默认框架与默认图片。c.排序机制。对于列表、排行版等需要排序的数据，确定排序规则。d.刷新机制。下拉，消息刷新，刷新多少。刷新不出来有什么提示。当状态发生了改变，数据显示也自动改变。此处的需求主要给前端展示以及后端数据提供。需要考虑数据落地本地，还是调用接口的实现方式。确定需要的字段，后台数据库需要增加字段，封装接口，前台调用接口在对应位置显示。需要确定前台与后台或者其他系统之间的数据传输，尤其当设计到多可系统时，此部分会较复杂。
4）状态逻辑是指的一个元素或者控件，在不同的情况下，可能会有不同的状态。元素是指概念上的，比如订单状态。控件是指物理上，通常是行动键的交互，比如按钮，选择框等。从元素的角度来说，需要确定有几种状态，对具体的状态进行定义，说明是什么动作触发了状态的变化，变化成什么样。比如订单状态，已支付、待支付、交易失效等。待支付的订单，点击取消，状态就变成交易失效。从控件的角度来说，需要确定该控件所有可操作的方式，每种操作对应的结果，包括提示等。此处的需求主要给设计、前端、后端以及后台查看。设计会根据不同状态设计出多个状态下的页面，前端则实现所有的静态页面，后端与后台配合实现数据的传输，界面数据的展示，业务逻辑的判断等。
5）交互规则是指页面与用户之间的互动反映，是UI设计和前端展示关注的重点。交互设计针对移动端有手势的动作，以及动作按钮等产生的交互效果。动作手势包括在左右划通常可以返回主界面;比如顶部有切换Tab，是采用左右划切换还是点击切换;还比如有些应用双击可放大页面，两个手指按住并同时向中间滑动，表示缩小页面，比如长按可能会弹出复制及粘贴的选择框。向下拉自动刷新。针对PC端主要是动作按钮，鼠标浮动产生的交互效果。比如链接、按钮的具体交互规则及异常处理。另外，整个场景由于网络问题、系统问题导致的异常也需要说明。
4、其他非功能性需求
1）缓存机制：每一步操作、每一个页面切换之后，都要想得到的数据需要缓存吗？缓存到哪里？清理缓存的实际是什么？
2）网络判断：一般涉及到下载或其他很耗费流量的操作时，会进行2/3G网络还是wifi网络的判断，当判断出是非wifi状态时，会进行提醒。其他需要向后台请求数据时，只进行简单的网络状况是否良好的判断，当网络状况不良时进行提示。
3）中断机制：除退出登录外，要考虑出现什么情况会导致用户中断操作。中断操作会有什么影响，比如是否要保存操作进度等等。常见的情况如：点击home键退到后台运行，按返回键，页面上有暂停使用的功能如倒计时音频播放过程中的暂停按钮。
4）运维需求：数据埋点，确定埋点的目标，再确定埋点的位置。为后续数据获取与分析奠定基础。
5）适配需求：相同后台，不同终端的展示，屏幕适配效果如何。确定app要适配的屏幕大小，iOS支持到什么版本，安卓要适配的分辨率是多少。然后要形成自己的直觉，适配的最小分辨率的屏幕最多能放多少按钮，现在的设计方案放在要适配的最小屏幕上，会不会太挤。当某一行字数太多时，一定要想这么多字放不放的下，放在一起好不好看。
5、同类控件的统一需求
若一个大的项目中，有一些相同的控件多次出现，比如分享、点赞、评论等功能，可以统一一个标准，将这类控件需求标准化，减少由于信息不对称的重复性工作以及不一致性。
6、需求文档的维护
写需求文档，很重要的一点是自己对于产品的逻辑有一个宏观方向的把控，微观细节的斟酌。作为一个新人，很多时候都是边做边学，需求文档看似好上手，有模板就可以照葫芦画瓢，可是细细研究就会发现无论从业务需求的角度，用户体验的角度，还是技术人员的角度，此文档都是可以深挖的。稍有疏忽，就会在后续评估以及与技术人员沟通的过程中产生新的模糊点，需要厘清逻辑，对文档缝缝补补。不得不承认，在整个项目的开始，即时文档已经达到团队成员的共识，在实施的阶段，也一样会发现各种问题，进行文档的调整。所以对于需求文档后期的维护也是非常重要，版本变更，需求变更都需要及时的更新。可能只有在产品完成的时候，需求文档才算是定稿。
声明：本文并非完全原创，以上总结是参考前人的分享以及自己在工作中总结的经验得出，所有引用的参考资料如下列出，不涉及版权问题。欢迎各位指正纠错。
参考资料：
http://www.woshipm.com/pmd/195719.html
http://www.woshipm.com/pmd/213894.html
《启示录》，[美] Marty Cagan
注：
[1]泳道图在纵向上是部门职能，横向是岗位（有时候横向上不区分岗位）。绘图元素与传统流程图类似，但在业务流程主体上，通过泳道（纵向条）区分出执行主体，即部门和岗位来。
[2]活动图（activity diagram，动态图）是阐明了业务用例实现的工作流程。业务工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。业务用例由一系列活动组成，它们共同为业务主角生成某些工件。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。
[3]状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。
[4]顺序图是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线
