PRD里面，一个完整的功能模块需求，应该怎么写？

写PRD是产品经理的基本功，大部分需要做执行的产品经理，都会花很多时间在写PRD上，写好PRD，才能将用户需求更好的转为产品需求，让产品方案落地。

PRD分为很多个模块，一份完整的PRD应该包含如下这些模块：

在实际的功能中，耗费时间较多，又主要是具体的用例（功能）模块，因为每个产品，都可以拆分成一个个独立的用例，用例的拆分，可以按步骤或者按功能模块，详细的拆分方法，可以看刀哥之前的文章，这里不详述。

本文的重点是分享具体用例的详细写法，把一个个的用例写好，可以极大的提升整个PRD的质量，减少和前后端开发撕逼，减少需求的变更，可以腾出更多的时间去研究行业，研究竞品，研究用户。

产品经理的核心竞争力，一定是对行业、用户的认知，产品的基础工作，花的时间越少越好。

01.用例

在说如何写用例之前，我们先来说一下，什么叫用例。用例是对用户通过系统完成目标的一系列过程的描述。用例是一个逻辑过程，一个标准的用例名称应该是动宾结构，比如登录系统、录入资料、找回密码……

一个完整的用例，我把它分成几个核心部分：1、前置条件/后置条件；2、业务逻辑；3、界面交互。完整的结构如下：

一个用例包含的关键要素

用例是UML里的标准术语，在实际和业务或者研发打交道的时候，经常叫做功能模块，功能模块也好，用例也好，产品经理自己一定要清楚这些概念的底层含义。

02. 前置条件/后置条件

需要提醒一点的是，在写具体需求的时候，不一定要按照某种严格的格式去写，除非公司有严格的要求，刀哥也有比较规范的PRD模板，关注公众号『刀哥说』，回复1可以自取。

但是在写的时候一定要按照这个思路，第一步，是先思考前置条件和后置条件，这个部分写的内容并不多，但是通过这部分的描写，就能弄清楚用户在执行完这个功能后，系统处理的结果是怎样的。

前置条件比较常见的就是用户状态、等级和类型等，比如用户要成功登录系统，前置条件是用户状态正常，后置条件是成功登录，进入系统。

比如用户要在系统里面新增一条数据，前置条件是登录状态，具备功能的操作条件，后置条件是完成在系统里面添加条数据，完成数据创建。

前后置条件有时甚至都不用写，比如用Axure写PRD的时候，但是产品经理心里一定要有数。

03.业务逻辑

这个部分，我觉得是最重要的模块，比界面交互还重要，也是产品经理的核心，产品经理的交互能力比较差还可以通过UED团队来弥补，如果业务逻辑差，那真是没得救。

业务逻辑我把它分成几个部分：主流程、分支流程、业务规则。

主流程，是通过活动图的方式，说清楚用户和系统的交互主流程。

分支流程，是在主流程的基础上，梳理各种分支和异常情况。

业务规则，则是流程判断的依据。

我拿一个审核工单的用例为例：

审核工单的主流程、分支流程和业务规则

实际梳理业务流程时，可以将分支流程和异常流程也加入到流程图里面去，颗粒度也需要自行掌控，根据团队情况。

这种业务流程图，也叫活动图，是用户和系统的交互过程，也是业务逻辑部分重要的分析工具。

系统在处理或者判断的时候，需要根据一系列的规则来执行，在梳理主流程和分支流程的时候，可以针对具体的流程节点，梳理业务规则。常见的业务规则如排序、数量、状态、顺序、时间。

梳理业务规则的时候可能会用到ER图和状态机图，有兴趣可以刀哥之前关于业务流程的文章。

04.界面交互

按『用户体验的五个要素』来划分，界面交互属于表现层和框架层，界面交互涉及到细节比较多，如果考虑不全的话，会产生很多细节问题。

业务逻辑部分，后端开发更关注，而界面交互部分，前端开发更加关注。

界面交互有几个核心部分：字段规则、界面展示、控件、页面跳转。

界面交互的要素

1）字段规则：字段规则主要是输入类的字段，所有输入的字段，需要考虑输入控件的类型、是否必填、字段规则、提示这几个要素，在写PRD的时候，可以通过表格的方式呈现。

2）控件：界面上有哪些交互控件，控件在不同状态下的展示样式，比如输入框默认状态、失焦状态，输入内容时，是否支持一键清除等，输入错误时，边框是否变红等。

3）页面跳转：点击链接或按钮，跳转到哪个页面，跳转到页面时，是否会带上参数，跳转页面后，再返回，界面上的数据怎么处理。在加载页面时，是否显示loading，加载失败怎么展示，页面404、500等缺省页面是否有准备。

4）展示：数据展示的规则，界面展示的每一个数据的来源是哪里，如果超过长度怎么展示，不同状态下怎么展示，空状态怎么展示。

其他还有一些常见的比如列表排序，数据埋点等，都是属于界面交互的部分。

05.写在最后

之前刀哥写过一篇文章，把做产品当做玩游戏，一共有四关：

只有过了基础的第一关，才能进入第二关，而要过第一关，就需要踏实的基本功，如果基本功不好，永远过不了关，一直在做功能，而不是做产品。

写好PRD还有一个很好的方法是，把写PRD梳理成一个SOP，归纳一套组件库，汇总一份自查清单，有标准模板，也有标准的写作思路，这样就能保证输出高质量的PRD。