今天仍然是3.3节、“关键的青春期，又见需求”，主要讲的是需求开发，俗称写文档。上一篇辨析了各种文档的区别和联系，下面作者就PRD进行了详细的说明，内容还是蛮多的，我看了两遍才慢慢有感觉了~

---

产品需求文档，PRD

通常一个项目会有一到多份PRD，每一个PRD会包含逻辑相关的若干功能点，这些相关的需求在“需求打包”的环节已经被识别出来，也就是产品需求列表里的若干行。PRD的结构如下图：

一份实际的PRD模板目录与结构示意图

总体说明

（1）修订历史：写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。

（2）项目概述：简单描述项目的背景、意义、目的、目标等，描述业务领域知识，让读者明白项目是为什么而做，这部分内容可以参考Kick Off会议所用PPT里面的内容。如果此PRD没有包含项目全部需求的话，也应做相应说明这部分需求是什么，其他需求在哪里等。

（3）功能范围：给出业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规则等。

（4）用户范围：对本PRD涉及的角色、系统做出简单的说明。

（5）词汇表：对本PRD涉及的专有词汇、术语、缩写等做出说明。

（6）非功能需求：如性能需求、数据监控的需求等。

（7）其他说明：其他任何需要说明的内容都可以写在这里。

用例文档部分

（1）整体说明：首先需要对这个PRD中所有的用例来个说明，给出用例的可视化表示，说明各个用例之间的关系，一般有类图、用例图、状态图几种表示方法（下面一部分会详述），其中用例图最为关键，下节里即将给出几个例子说明。

（2）接下来是用例的正文，由一个个的用例组成，这部分也就是我们常说的——用例文档。

（3）最后一部分“对单个UC的说明”是一些注释，常用的PRD模板里有如下内容：

    注1：视觉层面的描述通常直接通过Demo表达（如页面大小、颜色、字体、字号等）；

    注2：界面细节，引用界面规范文档（如表格中的文字对齐方式等）；

    注3：交互细节，引用交互规范文档（如出错提示的方式等）；

    注4：文案细节，引用文案规范文档（如各种提示文案等）。

接下来，作者详细介绍了用例文档部分，这部分大家比较陌生而且前面也没有提及。

学一点UML：类图、用例图、状态图

先解释下UML：统一建模语言，unified modeling language，它试图将软件工程的过程规范化。

公司一般会经历“人治→法治→德治”的三个阶段：人治是“由外而内”的被治，靠的是领袖魅力，更适合小公司；法治靠的是“硬法律 + 软伦理 + 执行者的以身作则”；而德治是“由内而外”的自治，靠的是企业文化，更适合大公司。很多小公司停留在第一阶段，很多大公司停留在第二阶段，只有少数公司才可能进入第三阶段。第三阶段和第一阶段表面上很像，但区别在于第一阶段根本无法，而第三阶段的法在每个人的心中而非纸上。

这也是产品和团队发展的必经阶段。一开始我们非常推崇个人英雄主义，或者在老板的带领下，或者自己带领几个菜鸟，没有章法地怎么快怎么做。慢慢地，产品越来越复杂，团队的新人也越来越多，于是我们开始在文档上做起了规范化的事情，从第一阶段走向第二阶段。在这个过程中，大家开始学起了UML，从产品设计的角度，作者把它对PD的价值简单理解成，提供了一系列的标准图形化的表达方式，把需求开发的过程串起来，充分体现了“字不如表，表不如图”的原则。

类图：Class Diagram

描述系统中出现的各个对象之间的关系，以及和外部系统的关系，这是对业务领域的描述，一个外行看了以后就应该了解此系统是做哪方面事情的。

用例图：Use Case Diagram

描述各个用例之间的关系，比如“include”或“extend”，用例包（将一组相关用例打包而成的模块）、用例和行为者（Actor）之间的关系。

状态图：State Diagram

表达系统里实体的状态转换，同样也是贯穿多个用例的。

上述几种图也可以看作是由整个产品最顶级的业务逻辑图细化而来，而对于商业演示场景所用的业务逻辑图的画法，团队内没有统一的意见，但一定要简洁清楚，因为受众都是大老板，他们没那么多时间看细节，所以这也意味着业务逻辑图最难画。

用例文档，UC

用例整体说明部分结束，就要进入单个UC的写作了。UC是需求人员写给开发人员看的一种最基本的文档，查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求的，20世纪初，一些牛人们才将这种方法正式归纳为用例法。之后在互联网和软件行业，又继续发展，逐步形成了今天的用例文档，或者说“任务分解”等描述需求的方法。理想状态下，一个UC代表了产品需求列表里的一行，但实际上并不绝对，也可能多个UC满足一个产品需求，或者一个UC涉及多个产品需求。

UC里要写哪些内容

首先是UC概述：

（1）用例的唯一标识：这项经常偷懒不写，关系并不大；

（2）用例名称：用一个短语讲清楚这个UC是做什么的。一个UC写一个任务，任务的粒度可以自行把握，比如同样是“增加、删除、修改订单”，在新人、新业务的情况下，就最好分为三个用例详细描述；如果是“老人”、老业务，也许用一个“管理订单”的用例描述就足够了。

（3）业务描述：商业目标、用户目的等业务内容，说明为什么要做这个UC？

（4）需求描述：产品需求，需要实现哪些功能点，这个UC要做什么？

（5）行为者：该用例的Actor；

（6）前置条件：触发这个用例的前提是什么？

（7）后置条件：用例完成，后续动作是什么？

（8）其他说明：任何其他信息，针对这个UC的特殊说明，没有就空着。

然后是UC主体：

（1）界面描述：通常互联网、软件产品中界面描述会占很大的篇幅，给出截图，界面上各种元素的说明，并且会和Demo关联起来，当然还有一种做法是单独写界面文档，然后与UC文档互相引用。

（2）业务规则：整个用例的通用规则，比如限制条件、。而界面元素或流程中的私有规则则不适合写在这里；

（3）流程描述：分主干、分支和异常三种，描述在这个用例发生的过程中，由什么事件触发，系统与用户之间产生何种交互步骤，这里尽量用时序图和活动图来替代文字描述，具体的例子下一节给出。

现实中的UC会做得比较美观，这也是为了防止大家看久了白底黑字太无聊。从下表可以看到对于界面描述、业务规则、流程描述的写作，我们都有一些模板式的总结，这些都是特定的产品、特定的团队通过不断优化得到的结果，并且会继续优化下去。经常有网友问作者要文档模板，但作者认为其用的非常个性化，拿过去直接用会有很多的地方不适合，甚至产生负作用，所以建议大家按照本节讲述的内容做一个最简单的模板，把现在你觉得没用的内容都删掉。然后在实践中慢慢优化，切身体会到缺什么了时再添加内容。

现实中的UC模板

UC一般只用来描述功能需求，它不便于描述诸如产品扩展性、系统容量、人员培训等非功能需求，所以我们把非功能需求部分写在PRD的总体说明里。

【注】：UC里对语言的要求比较高，需要做到：无歧义、完整、一致、可测试等，相信为此吃过苦头的同学都有体会，举几个简单的例子。

无歧义：比如“小明和两个部门的同事一起去餐馆”，就不知道“两个”是形容“部门”还是“同事”。

完整：比如“小明预算不超过100 元”，其实是不完整的，应该是“小明的人均预算不超过100元”，如果他和大毛一起来，则预算是200元。

一致：比如“小明非工作日去餐馆吃饭”与“小明周末去餐馆吃饭”就不一致，国庆节、春节怎么算？

可测试：比如“点菜时要考虑到金额限制”，就没有办法验证，应该说“如果金额大于100元，则需要修改点菜单”。

再学一点UML：时序图、活动图及其他

刚才提到了UC里的流程描述，我们再学几种UML的图，它们描述的是用例的内部事务。当然，用例内部不一定是“单个用例”内部，也可能有用例之间的关系。这些图在描述业务规则和流程的时候非常有用。

时序图：Sequence Diagram

也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间。

活动图：Activity Diagram

比较接近我们常说的流程图，描述各种动作如何引起系统变化，善于表达泳道较多、分支较多的情况。

协作图：Collaboration Diagram

表达不同对象之间是如何互相影响的。这幅图在日常的项目中用得不多。理论上它和时序图是可以等价转换的，只不过时序图关注交互在时间上的步骤，而协作图关注交互过程中各个对象间的关系。

很多时候多种图都可以描述同一件事情，只是视角不同而已，选用哪个关键是看针对特定的系统，从哪个角度来描述更容易让受众理解。另外还有表述软件实施的构件图、描述硬件结构的部署图，这些图更偏向技术一些，对PD的用处不大。

【工具】：上述这些UML图都是用Visio画的。再次强调，工具是为人服务的，如果团队里其他成员都看不懂UML图，且学习成本太高，那一定不要强推UML，寻找合适自己的工具吧。描述需求的原则很简单：把要做的事情跟受众说清楚！

产品Demo

PRD写完了，工程师拿着它就可以开发了么？不是。还缺了很重要的一块，产品Demo，也经常被说成是产品原型、演示版。

【Demo与用例文档的关系】

对于某个产品功能的用例是否包含界面的描述，每个团队有自己的做法，好坏难以评估，这取决于产品的特点、团队的习惯等，我的建议是不妨再次应用做产品的思路，去问问这些文档的用户，即团队里的开发工程师、测试工程师，按照他们喜欢的方式写就好了。但用例里最多只能放Demo的截图，所以如果要表现更多交互和视觉的细节，Demo是必须独立存在的。现在应该有一些可以嵌入富媒体内容的文档方式，可以直接把Demo嵌入用例，不过作者没有尝试过，说周围也尚未看到有人用。

【主导与参与】

作者认为Demo最好是由用户体验部门的同学主导，即使团队中可能并没有这样一个叫User Experience，简称UE的部门，那么做这个事情的人也许叫用户体验师、交互设计师、视觉设计师，甚至是比较过时的称呼——美工。但产品经理也必须参与Demo制作的过程。Demo的制作在产品会议之前就可以开始了，有可能的话在BRD中展示出来，很可能成为争取资源的加分因素。最关键是要保证Demo的设计师们充分理解商业目的和用户目标等，让大家在方向正确的前提下再自由发挥。

【Demo的发展过程】

Demo也会经历从低保真到高保真，从抽象到具体，从全局到细节的渐变过程。

一般来说，最开始会有一个纸面Demo，铅笔加A4纸的组合，或者是马克笔加白板再用手机拍个照，有了这样的东西，大家就可以开始沟通了。其实这些线下的工具，纸、笔、白板，加上口头交流，可以帮助我们进入很高效的工作状态。

接下来会有一个线框图，只关注界面框架而不考虑细节，使用的工具可以是Visio、PPT、Word，甚至Windows操作系统自带的画图板。

进一步，我们要关注视觉效果，也许会用PhotoShop做几张典型页面的效果图。然后，表达交互细节，使用Axure、Dreamweaver制作页面，这页面很可能就是将来产品里真实可用的网页了。

产品不同，用到的Demo工具会不同，或者各个阶段也会不同，但最重要的不是工具，而是内心的想法。实际工作中，PD肯定会对Demo给出一些自己的想法，甚至经常自己做，越是低保真的Demo我们做得越多。

团队分工的形成总有各种各样的原因，凡事向好的方向看吧，如果要我们做Demo，那么就更加全面地锻炼了能力，如果有UE的同事，我倾向于信任专业人员，只提建议而不做决定，让专业的人做专业的事，这样产品才更完善。

概要设计与详细设计

作者发现，在写UC的时候，经常写着写着就觉得是在越俎代庖地做概要设计，甚至是详细设计的事情了。比如，对于网页上简单的一个“公司名称”字段，就有很多细节的设计使人纠结，询问工程师后也常常会得到相反的答案：有人希望你写得越详细越好，而有人希望你交给他决定。后来渐渐总结出两种做法。

第一，不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。比如上例，在业务上需要对“公司名称”的长度做何限制由PD确定，而“公司名称”的数据在数据库里如何存储，由工程师决定。

第二，细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。比如上例，通过几次协商，我们确定了以后产品中出现的各种字段的各种限制规范，下次再写UC的时候，只要引用规范即可，省去了很多重复劳动。