需求文档怎么写？这里有一套思维框架

需求文档，或许叫解决方案文档更合适。

百度随便搜一下『需求文档』，大约几十万个结果。想必我们都看过不少这种文章，下过不少模板。很多时候还是不得要领，一想到写文档就头疼。

这篇文章关注的不是写成什么样，然后给大家一个模板了事，也不会讲文档的结构应该怎样。

思路清晰，做事才能高效。本文关注的是写作背后的思考过程是怎样的，现在，把我的一些思考分享出来。

引言

说需求文档之前，我们先了解一下『需求』这个词。很多场景下，我们都会用的这个词。调一下字体颜色，也被设计师说成是需求，需求这个词感觉有些被泛化了。

而产品经理在作需求分析的时候。这个需求的定义是指：谁在什么情况下想做什么，以达成什么结果？简单来讲，就是某个角色想得到或完成什么？需求是需求方的渴求，只跟需求方自己相关，是不带解决办法的，提出解决办法是产品经理的工作。

如果有人说，我想加个按钮，产品经理正确的做法是搞清楚用户的出发点是什么？为何要加？有没有更好的解决办法？而不是马上就把按钮加上。

传统的软件需求分析理论中，需求可以分为三个层次：

业务需求（Business requirement）标志组织或客户高层次的额目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。

用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

我们在做需求分析，也按照这个思路来进行。

第一步，公司想干什么？

正确定义问题，是成功解决问题的一半。

宏观上，你需要对组织的优势、劣势非常了解；需要对用户构成及特点很熟悉；需要对市场变化趋势有把握。

在以上的背景条件下，提供一个解决方案，其实就像是在大生态下面，打造一个微型的生态。

假设我们在经营一片果园，目标就是种出好吃的果子。

先解构这个小生态，是由哪些要素组成？比如需要有果树，需要有肥沃的土壤，需要有人去打理等等。

更进一步，生态里面的哪些要素是变量？有哪些变量是我们可以调整的？

这过程中遵循的一些本质的规律是什么？比如光合作用，比如温度变化与甜度的关系等等。

最后，评估这个果园经营状况需要哪些指标？

上面其实有些像是商业需求分析文档，站在一个宏观的角度去看待问题，想办法建立一个可以良性运转的生态。

上面完成之后，我们再把视角放大，把这个小生态放到整个大生态里面去审视：对原有整个体系会产生怎样的影响？还有哪些点没有想到呢？

第二步，各个角色能做什么？

接下来我们进入用户需求分析。

简而言之把自己代入到这个生态里面的每一个具体角色，思考需要完成哪些事情。注意，这个角色不一定是指人，也可以指一个系统。从进入这个生态开始，到离开这个生态，这个角色要完成哪些事情？

这一步梳理完了之后，输出用例图及每个用例的详细描述。

有必要的话，可以按价值取向对用例进行分类，比如说效率向、利益向。再用KANO模型分析一遍，这样下来，基本上对需求会有透彻的理解了。

用例，是以使用角色的视角，描述与系统的交互的过程及结果，关注的是用户可感知的层面。
每个用例完成情况的衡量标准是什么？都得想清楚，因为我们是为一群用户来做设计。

第三步，用户完成的过程是怎样的？

明确了能干什么事，那么就下来就把每一件要干的事解构出来。这个阶段，输出流程图即可。

流程图是以过程为中心，用全局的视角，关注事情怎样被完成。
一件事情可能有很多角色参与，共同来完成。每一个流程图都为了获得一个结果，各个分支都得考虑到，也就是说，必须是一个闭环。

用例和流程图梳理完了之后。建议大家把各个用例涉及到的数据实体罗列出来。数据的状态转换是怎么样的？这个也非常重要的，通常是输出状态转换图。

第四步，用户的页面交互是怎样的？

这里我说一个观点：
用例是对用户需求的描述，流程图为用例服务，原型是为流程服务。

写文档就是从抽象到具象的过程。原型之前的工作就是抽象的部分，是可以脱离某一种具体实现方式及页面而存在的。

作图之前，还得再做一部分抽象的事情。

先把用户触点想清楚，你是想自己做个APP呢，还是做公众号呢？或者小程序呢？如果是已经成形的产品，基本上就没什么可想的了。

然后作一个页面结构图，这个相当于文章目录，梳理完毕之后，各个模块需要哪些页面就清楚了。每一个页面基本上可以与流程图的节点对应起来的，大家可以以这种方式去自查。

作一个页面，也得有大局观。页面在整体的流程当中，扮演什么角色？比如说商品详情，这个页面要负责销售转化。用户在这一步关注什么信息？他的决策依据是什么？这些都需要对用户有很细微的理解，才能在满足用户需求的基础上提升转化。

每个页面上的数据展示规则或者交互效果说明的有必要说明的，等直接在页面上标示说明。比如时间是显示年月日还是显示X天前？页面的显示相关规则不要与前面的用户流程图混在一起，页面只关注微观的呈现。

注意，每个页面都得与数据状态转换图对应，思考各个元素在各种状态下的呈现。

页面建议用Axure的母板来做，做完了所有页面，再与相关的用例描述、流程图对应起来，平铺在一个页面，做好交互跳转指示。

文档到这一步，基本上就差不多了，实际工作中可能还有其他部分，比如说非功能性需求、性能需求等。

总结

需求文档是对解决方案的描述，思考过程是从宏观到微观，从抽象到具象，类似哲学上还原论的思考方式。

抽象的工作没有完成之前，先不要去做页面这些具象的工作。

再次说明：
用例是对用户需求的描述，流程图为用例服务，原型为流程服务。
我的思路就是以用例为中心。

以上希望对大家有用。另外，建议大家去学习一下UML，包括它非常有用的一些图表，这对理清思路大有裨益。