完成调研，就意味着已经弄清楚了需求的前世今生，就进入方案设计环节。我们所说的用例图、业务流程图、功能流程图、状态流程图、信息架构图、原型、交互界面、触发机制、数据流、方案策略等，都是方案要设计的内容。通常，我们先设计好了这些具有提纲挈领作用的核心框架之后，也就是完成方案设计之后，才会进入最终文档的输出。
01、用例图
所谓用例图，是指由参与者(Actor)、用例(Use Case)、边界以及它们之间的关系构成的，用于描述系统功能的视图。
用例图是外部用户所能观察到的系统功能的模型图，从宏观层面上表达了角色如何使用系统等信息。
用例图可以使用使用Visio或Axure等工具完成。
典型的用例图由参与者、用例、系统边界、箭头组成：
参与者：就是系统功能的用户。需要注意的是，参与者是角色而不是具体的人。用所示的一个小人表示：
用例：就是系统功能单元。是系统功能所完成的事件。用椭圆加文字表示：
用例边界：就是将一些相关的用例圈在一个方框中，来展示系统的一部分联系紧密的功能群。它可以理解为多个子用例的组合。
箭头：箭头表示关系。有四种类型，分别表示关联、泛化、包含和扩展关系：
02、业务流程图
用例图相对来说比较简单浓缩，开宗明义地告诉人们这是干什么的，但是远远没有触碰到业务的细节，于是就需要业务流程图进行详细地说明。
业务流程图与用例图的区别是前者更详尽，以点餐为例，其核心的业务流程（即步骤）。
业务流程图和用例图一样，都是需求文档的业务背景环节中的内容，帮助渎者了解需求要解决的问题发生在哪个情景中。
业务流程图与功能流程图的区别就是，前者描述的是用户处理业务的流程，后者描述的是系统功能运行的流程。
03、功能流程图
业务流程图是从业务活动的角度进行绘制的，业务的一个活动可能对应功能好几个功能处理步骤。
比如上述的“点餐”，在业务流程上就是一个事项，但是在功能上要进行多场景的描述：
因此，功能流程图更加接近需求方案，一般也是最主要的一个流程图，我们默认的流程图图就是功能流程图。
画流程图可以用Visio、ProcessOn或者Axure、XMind等。笔者认为有几个注意事项：
1）功能流程图核心是在描述操作相关的动作，因此每个方框中都是具体的事件，不要把状态放进去。如果要把状态的变化也放进流程图中，建议换个形状或者用备注的形式表达。也可以单独做一个状态流程图出来，以免不同类型的事物放在相同的图形中造成不伦不类。
2）表示判断的菱形当中，如果是是非判断，建议写成“是否xxxx”，读起来容易理解；如果是多重判断的话，建议写作“判断xxxx”。多重判断的时候每一条分支上面也可以增加文字辅助说明。
3）流程图的箭线之间最好不要交叉，合理的流程一般是可以做到不交叉的（当然这个不是必须的）。
如果流程图有过多交叉，或者发现不能成为闭环，那么好好检查下，可能是画错了。
4）对于复杂的流程图，建议事先在草纸上用笔画，通顺了之后再挪到电脑上画。因为草纸上画起来更加快，更容易与大脑的瞬间思路同步。
04、状态机
状态流程图和功能流程图相似，只是状态流程图针对状态的变化。
比如审核流程类功能，常常每通一关审核都会伴随状态的变更，且状态变化往往是作为分类或触发下一步功能的判断依据。
这时候，“状态”就是一个很重要的属性，因此，复杂的场景下一般都要单独做状态流程图。
有时候，我们不单独画状态流程图，而是将其结合在功能流程中，可以使用平行四边形表示。
05、功能结构图
在PRD（产品需求文档）中，有必要提供需求要点的汇总图，也就是功能结构图，有时候也叫功能架构图或信息架构图。
它就是以鸟瞰的角度，将该需求优化或新建的功能点列出来，好比是一个需求要点清单一样。
对于功能较多的需求，功能结构图是很有必要的，它可以对产品的基本需求具体化、轮廓化，起到核对单的作用。笔者做过的一款App产品的功能结构图：
06、原型图
原型图（demo）是需求文档的主要支撑部分之一。
后端产品往往是功能逻辑主导交互的，界面的变数不大，所以原型图的交互一般不用做太深太细，辅以文字说明会更直接明白。
由于原型是产品经理的必备技能，因此作图工具和用法就不用赘述。
07、数据触发机制和流向
后端产品十有八九是与数据有关系的。
因此需要明确数据运算触发的机制。
通常包括操作事件触发，和定时任务触发。
比如点击提交，这个动作事件将数据推送出去。
而定时任务就是一个定时脚本，由定时器定时触发执行。
多是一种异步处理思路。比如一些后置业务无需当场实时提处理，异步就可以节约资源。
另一种情况就是手动操作触发有困难。比如第三方什么时候完成订单我们不知道，这时候可以使用定时任务进行请求第三方。
数据流向，基本就是数据获取>暂存>预处理>核心运算>推送。整个过程会牵扯数据的粒度，运算规则，默认值、异常机制等。
08、功能实现机制
前面提到的方案设计要素，都是从一个方面或角度来说明需求方案的方向的，而功能实现方案则是整个文档的血液和灵魂，是最核心的部分。
实现方案包括逻辑规则、约束规范、实现机制、执行频率、异常机制、数据取值、逆向机制等。
实现方案的本质就是将需求转化为系统层面的解决办法。
因此功能实现方案在整个需求方案设计当中是最重要的，也可能是最难的。
通常情况下，后端产品都不是独立的一个产品，而是相互之间有关联的产品体系，具有业务逻辑的耦合性。因此功能实现方案一般可以从全局方案和具体方案进行设计。
（1）全局方案
就是解决目标问题的整体方案。需要考虑目标问题的范围、衍变性、复杂性等。
全局解决方案不局限于某一个系统或现有的资源，也不局限于当前时间。而是站在整个体系的角度考虑和规划的。看下面的例子：
案例：物流系统中，要求校验用户身份证信息后，才能选用A物流方式，否则不能使用A物流运输。而某些商品邮寄到某些地区只能使用A物流。
需求：那么为了确保万无一失，就要想办法获取几乎每个用户的身份证信息，确保所有销售网站的订单一旦需要使用A物流，就可以使用A物流。
分析：从全局来看，要么从根源，也就是销售网站下单的时候就统一加上身份证字段传给物流系统。
要么就在所有顾客资料库中维护该字段，然后在物流发货的时候统一调用。前者方案涉及到很多第三方网站，不容易实现；后者方案涉及到多个系统维护和调用，也比较麻烦。
究竟用哪个方案？是否有其他替代方案？这个就是全局方案要考虑的。全局方案更依赖业务整体流程和企业资源的最优化配置。
（2）具体方案
具体方案指的是具体到某个后端产品或系统上要复杂实现的方案。
以上面的案例来说，如果采用第二套方案，就可能需要在仓库系统统一维护用户的身份证，在抓单系统进行调用。这两个系统又各自考虑自己的实现的具体方案，比如数据运算机制、数据流转机制、规则设置方案、操作流程机制等。
因此具体方案更依赖于产品经理对具体产品系统的了解和具体机制的把握。
IBM推荐的需求文档模板：https://pan.baidu.com/s/1F4GL0Pm_PBbd-LCBHFyN6Q ，提取码：1234
