作为产品经理重要的工作产出物之一，需求文档的完善和可用程度，直接决定了每个产品经理的专业水平。如果你的需求文档连开发都找不到可以吐槽的点，恭喜你，可以出师了。

周末跟之前的开发同事聚了一下，他跳槽了几家公司，在吐槽他们的产品经理，写的需求文档，真是一言难尽，记得之前他评价过我们公司的产品经理，是真的“把肉喂到开发嘴边去”，需求文档特别细，写代码看着就很舒服，省事太多。

是啊，这也是我一直要求的，不单单是产品经理，任何岗位都是，都要对自己的下游同事负责，这样整个团队的运转效率才是高效的。

当开发和测试不再吐槽你的需求文档了，你的产品专业就更上了一个台阶，你们的团队也会更和谐了。

因为我是做电商系统的，中后台，我就聊聊这方面的需求文档，应该怎么写，延伸下其实整个B端的产品经理，都可以参考下的。

01 首先要明确几个问题

首先，我们明确两个问题：

1）需求文档的目的：

需求和功能实现的中间环节，需要一个媒介，可以将产品经理的功能设计描述清楚，这是最主要的目的。其次对于一个项目，所有的材料也需要沉淀。

2）需求文档的面向对象：

面向对象有两部分，一是现有项目成员，设计、研发和测试，需要按需求文档进行功能开发测试工作；二是后续新人，需要按需求文档熟悉现有功能。

综上，需求文档应该具有简单、明确、通俗几个特点，也就是说用最简单的设计、最明确的流程、最通俗的文字来实现用户最复杂的需求。

02 需求文档的前言部分1）文档状态

也就是我们整篇文档的前奏，用来描述文档的一些基本信息。比如文档状态（初稿、副稿、终稿等）、文档名称（WMS系统二期文档）、版本号（V2.3.6）、作者、部门、完成时间、基本概况、保密级别等，对这篇文档给出一个最基本的说明。

2）方案概述

我们对于这个需求的整体方案描述是怎样的，这里面会牵扯到哪些点，同时也需要将这个方案同步给需求方，以确保两边信息一致。

在方案阶段也需要说明需求的背景和目的，是因为什么原因我们要开发这个功能，它的价值是什么，它上线后会给公司或者整体系统带来什么样的改变等。

3）要素定义

要素定义指的是一些专业词汇的解释。这个描述清楚，将有利于研发和测试的理解，更好地开发需求。道理很简单，产品经理作为技术团队对外人员和产品的设计者，他会对很多专业词汇有一定了解，但是其他技术人员不会。

比如开发Amazon损益表，里面有个字段叫“计提货损”，这个如果不解释下，估计很多人都不明白。感兴趣的小伙伴可以查下这个词。

4）权限说明

有些习惯放前面说清楚，有些习惯放后面，都可以。权限说明指的是你要做的这些菜单，哪些按钮要做角色权限，哪些字段要做数据权限等，尤其是数据权限，不建议大家固定几个字段，可以单独做一个数据权限控制的菜单，管控所有字段，这样会灵活很多。

5）测试要求

需求文档除了研发用来开发需求外，测试也会，这里为什么会强调写测试要求，是因为有些功能对于测试而言，是可以不测的，或者说应该有一定的特殊要求。比如我们的python，爬去amazon的一些review，如果涉及到竞品，数据体量超级大，这就需要说明一些测试要求。

03 需求文档的表单字段部分

表单就是我们说的菜单的界面，要展示什么内容。

1）整体描述

对于这个菜单的取值逻辑整体方案描述，说明这个菜单的数据是如何产生的，比如是按xx时间从xx菜单根据xx脚本产生的等，提供大家一个基本的认知。

2）菜单路径

要写明这个菜单在哪，尤其是新菜单需求，因为后续要配置菜单路径、按钮等，也方便你查看。

3）字段名称

这个菜单要展示的所有字段，在需求文档里一定要和原型图的顺序保持一致，一定！而且这个顺序也是有学问的，哪些字段比较重要，关注较多，哪些字段存在关联关系，都需要你考虑到位。

后续针对菜单的优化，如果有增加的字段，也要写清楚这些字段的位置，比如新增“总金额”字段，位于“总数量”字段右侧。

4）取值来源

这个是讲如何取值的，从哪些菜单根据什么规则取来，是否是计算的，还是根据某些字段关联，又或是自己添加，或者系统的自动生成的时间等，是需要保存下来还是动态查询即可。

比如“一级站点”字段，取值来源为根据“二级站点”关联【站点管理】对应的“一级站点”，保存。

再比如我们一个菜单统计实时的“销售数量”，取值来源为统计时间为当天的【销售订单列表】状态为“shipped”的数量合计，动态不保存，这种每次点开需要查询一次，所以不应该保存。

5）取值表名

如果是从另外的平台获取而来，比如api拉的京东的报表，或者Amazon的报表，需要将报表的字段来匹配我们自己系统的字段，这就需要说明你要拉的这张报表的名字，并且需要把表的路径描述清楚。

6）取值表字段名称

同第5点，这个就是描述两张表一一对应的字段，这里要说明下，如果拉下来的是中文报表，除非与系统相冲突，否则是建议保留原始表字段名称的，业务方更容易理解。如果是对接Amazon的数据，可以找一个业务方来翻译下，谷歌直译的内容很多还是“挺惨”的。

7）字段举例

顾名思义，举例让大家看下，也是为了更好的理解。

04 需求文档的查询条件部分

方便大家筛选想要的内容而增加的一些条件，顺序一样需要与原型图保持一致，后续优化新增的查询条件也是要写清楚位置。查询条件的格式有很多种，大致分以下几点：

1）文本格式

需要写明能支持什么类型的内容输入，比如文字，比如数字；是否支持多个内容查询，多个内容查询中间需要用什么符号隔开；只支持精准查询还是可以支持模糊查询，模糊查询是单边模糊查询还是两边模糊查询，针对模糊查询这里有个技巧，就是数据量，数据量大的表单尽量减少模糊查询，很影响用户体验。

2）下拉框格式

可以是某些控件，比如日期；是固定的内容还是从别的地方动态取出，要不要去重；默认是为空还是某个值，支持单选还是多选；是否支持模糊查询（下拉框本身的模糊查询）。

3）复选（单选）格式

这算是另类下拉框格式吧，只是把内容全部放在外面了，可以同时选中多个或一个条件进行查询。

4）开关格式

类似第3点，也是一种选择格式，不过这个基本上是只能单选。

5）时间格式

这里单独讲一个时间格式，年份啊月份啊，或者到天到秒，很多封装好的控件都可以，到秒，需要注意下，如果是个范围的查询，那么前区间的需要到00:00:00，而后区间的需要到23:59:59，要不然查不出来，这是很多人会犯的一个错误。

6）最后注意一点

要说下样式，尤其是比较特别的，比如你的查询条件是收缩的，默认展示多少行等，要跟原型图保持一致。

05 需求文档的功能按钮部分

这算是最重要的部分了，也是真正体现一个产品经理水平的部分。

1）查询/搜索

查询算是最简单的按钮了，点击一下根据查询条件查出结果就好，有一个点需要注意下，默认加载页，对于字段很多或者数据量很大的，可以不显示，或者按固定一些条件，否则响应速度很慢会影响用户体验。

2）重置

重置查询条件和查询结果的，一般都会选择重置两者，会更方便，如果有特殊情况，只重置查询条件，保持查询结果不变，也可以，不过不太建议。

3）添加/新增

用于菜单新产生数据，可以按以下几个步骤：

①正常完成情况：

即需要描述清楚在什么条件下，选择哪些内容，可以正常添加成功；

②添加里面的字段：

必填项、非必填项；字段格式，文本、下拉框、日期、单复选等；文本格式要说明可以填写哪些内容，比如数字，字段长度要说明；下拉框格式要说明取值来源，固定哪些字段，还是动态取值哪个菜单，单选还是多选，默认有值还是为空；日期格式具体是到年、月还是到天、秒。

③校验：

唯一性校验，按xx+xx属于菜单的数据唯一性校验，若有相同的是报错还是覆盖；匹配性校验，按xx+xx校验是否在哪个菜单存在，或者是否审核通过，如果不满足条件的报错；校验报错提示需要精确定位，让用户一眼就知道，要不然，就忙坏IT的同学了！

4）编辑/修改

编辑的界面展示基本上同添加，会多几个说明：

①可勾选数量：

是否可以勾选多行编辑，一般只允许一行，这里就需要添加校验，当然没勾选数据的更不可以编辑了。如果是每行数据本身存在编辑按钮，那这个忽略。

②可编辑条件：

很多条件下是不可以再编辑了，比如一个付款申请单，付款状态为已付款，那这个就要禁止编辑，这就是需要写清楚的。

③编辑后的状态：

编辑完成后，这条数据的状态是否要还原最初，尤其是审核状态，因为编辑后很多内容改变了，就需要重新审核。

④其他校验：

同添加一样了，应有的那些校验。

5）删除

删除就是要把数据删掉，有三点需要注意下：

①可勾选数量：

是否可以勾选多行删除，基本上是可以的，如果是每行数据本身存在删除按钮，那这个忽略。

②可删除条件：

很多条件下是不可以再删除了，比如一个付款申请单，付款状态为已付款，那这个就要禁止删除，这就是需要写清楚的。

③删除后的上游数据还原：

删除完成后，数据对应的上游数据是否需要还原，还是将付款申请单，从上游传来的，如果删除了，上游的已申请付款金额就要还原，这样才可以继续申请付款。

6）导入（上传）

可以算是批量添加，跟添加类似，但是校验逻辑要比添加多很多。

①支持的文件：

一般来说支持Excel，看看哪种格式的，.xlsx/.xls/.csv等，又或者其他格式，如果不属于这种的，导入需要报错提示，同时因为导入模板是固定的，这个每行的字段表头也要校验。

②必填项/非必填项：

同添加，哪些字段需要必填项，哪些非必填项，报错后需要提示到第几行，要不然体验太差。

③逻辑性校验：

同添加，这里校验的要更多，添加的很多内容界面可以显示出来，导入不可以，所以这里更要考虑全面，报错后一样要提示到第几行。

④重复性校验：

若系统中已存在重复性数据，是报错还是可以覆盖。

⑤新增导入：

有一种导入就是用于新增数据，系统没有的可以导进去，尤其是涉及到脚本跑出来的，很多是不可以增加数据的，这种新增导入要写清楚。

7）导出（下载）

导出无非三种，勾选的数据、当前页、所有数据，当你的数据量足够大的时候，可以采取异步任务执行，去一个专门的导出菜单慢慢跑数据，跑完了下载即可。这种适合于导出表单，也就是Excel。

如果是表单本身中文内容需要导出英文的，可以加一个语言转化控件，或者简单粗暴一点，固定语言匹配也可以。

导出其他格式就要提前把模板搞好，或者是下载原文件等。

8）审核通过

审核通过这里是统称，可能是初审、复审，可能是运营审核、财务审核，可能是一级也可能是多级，都需要写清楚。

①审核数据量：

审核一定需要勾选数据，但是否支持批量审核，需要注意，大部分支持体验会好一些，如果数据很重要，可以加只支持一条审核的校验。

②审核流：

建议不要固定死，最好是灵活性多级设置，并且是有设置按钮的，不是代码写死，比如按金额设置，多少钱以内一级，超过多少钱需要二级审核。

③下一级审核/数据流向：

审核通过后，下一级审核是到哪里，或者下一步的数据流向哪里，会匹配出哪些字段，哪些内容又会变化。

9）审核驳回

审核驳回也是统称，可能是初审、复审，可能是运营审核、财务审核，可能是一级也可能是多级，都需要写清楚，跟审核通过很多共性，也有一些区分。

②驳回原因：

这个一定要的，必填项，需要让申请人明确原因。

③数据还原：

审核通过是数据往下走，那审核驳回就是还原数据，比如一个采购合同的付款申请被驳回了，这个合同的申请付款金额就要还原，不能影响后续的付款申请。

④是否可编辑：

如果本菜单的数据审核驳回，这条数据应该可以被编辑的，要不然体验不好，如果是上游流转下来的，就要看情况，是否允许编辑。

10）撤回

撤回也算是自主审核的一个，为了用户发现问题后自主处理。

①撤回数量：

同样需要勾选数据，但是否支持批量撤回，需要注意，大部分支持体验会好一些，如果数据很重要，可以加只支持一条的校验。

②撤回条件：

允许撤回的条件怎样，比如一个付款申请单，当付款状态为已完成，肯定是不允许撤回的。

③数据还原：

当撤回成功，撤回数据本身的字段变化，尤其是审核状态，需要变成最初始的，撤回后下游数据是否要删除，都是需要考虑的。

11）作废/取消

作废有点类似删除，是对不方便删除数据的弃用。

①作废数量：

同样需要勾选数据，但是否支持批量作废，这个基本上都可以支持。

②作废条件：

允许撤回的条件怎样，同样拿付款申请单举例，当付款状态为已完成，肯定是不允许作废的。

③数据还原：

当作废成功，作废数据的上游数据哪些字段需要还原，因为需要让上游数据继续往下走。

12）打印

比如合同，比如付款的单据，很多需要打印功能。

①打印条件：

除了勾选数据外，打印的条件需要考虑，哪些条件下是可以打印的，尤其是设计审核流的，当审核不通过时，是没必要打印出来的。

②打印模板：

这个就是打印出来是什么样，需要提前固定好模板，哪个字段怎么取值，长度、宽度、颜色等，电子签名如何显示，电子签名简单一点，放个图片就好。

13）设置

需要根据某些动态取值确定审核流的，可以用到设置，一般会按审核流+金额（数字）等区分，下一级数值需区别于上一级等。

14）确认/提交

同审核通过，区别这个按钮使用对象一般是自己或者其他部门同级别人员，比较少自己的上级使用，注意的点参考审核通过。

15）复制

对于经常使用且添加相同数据的菜单需要个复制按钮，会方便很多，这个比较简单，一个需要勾选，另一个复制出来的内容，大部分肯定是一样的，需要描述下哪些字段复制出来是空的或者其他取值就好。

16）日志

一般会有这么几项内容。

①操作人：

记录这项操作的姓名，或者用户名。

②操作记录：

操作的按钮，比如添加、编辑、初审通过。

③操作时间：

操作的具体时间，需要精确到秒。

④备注：

记录一些操作内容，比如操作前后的数据变化，或者操作时填写的内容等。

⑤下一级审核流：

涉及到审核的菜单，加一个下一级操作会很方便，当然审核流也可以单独做。

⑥下一级审核流权限：

同5），让大家可以知道是谁该去处理。

17）入库/出库/调拨

库存功能会有这3个按钮，入库/出库/调拨会涉及这么几点：

①本身字段：

需要填写的数量、入库/出库/调拨地点、涉及到的单号（订单号/需求单号），有些详细的需要填写仓租量等。

②数据流向：

尤其是出库/调拨，点击出库/调拨后这条数据会流向哪里，这两个按钮还有重要一点，库存数量的变化，入库会导致在途库存减少、在库库存增加、总库存不变，出库会导致在库库存减少、总库存减少，调拨会导致调出方库存减少、调入方库存增加，一般是在途库存增加。

③校验：

入库的比如入库数量不能大于在途数量，或者发货数量，出库数量不能大于在库数量等，有些预出库的在途数量也算，那也可以。库存数量为0的，禁止出库，等等。

④调拨特殊校验：

调拨不同于出库，出库一般是有订单号，不会仓库间出，调拨属于，这里注意每个仓库会有对应的法人公司，不同的法人公司间货物往来需要结算，不仅仅是数量变化了，金额也会涉及，如果财务不允许，也可以禁止。

18）申请付款

跟钱有关的都是大事。

①正常字段：

一般需要填写金额、付款原因，金额如果是很多数据的合计，或者本身就有的，那直接取值就好。

②特殊字段：

比如有些可以使用抵扣，那这里就可以填写抵扣的单据，抵扣的金额，实际申请付款金额就会对应减少。

③校验/流向：

未申请付款金额为0不可以再次申请，审核状态未通过不可以申请，这些都是，申请完后的下游流向也要写清楚。

19）数量拆分

一行数据拆分成多行，这里的校验就是允许拆分的条件，这个还好，重点是拆分后的每行数据每个字段的取值，这个需要写清楚。

20）说明

这个说明是对菜单功能的解释，或者是简单的操作说明，类似于一个文本框，填写保存后可以放在菜单比较显眼的位置，让用户查阅。

21）其他

除了以上的，其他按钮比如付款、退货、兑换、任务分配等，都可以从上面找到共性，重点写清楚按钮的正向条件、逆向条件（报错）、数据流向、数据还原就够了。

06 需求文档的收尾部分

前面算是完成了90%，还有最后一些说明，也要注意下。

1）默认加载页

也就是进入菜单第一个显示的页面，默认显示每页多少行。对于字段很多或者数据量很大的，一定要考虑清楚，是否可以固定一些查询条件，比如一个几千万行数据的订单菜单，默认加载页的查询条件就可以固定一些日期，只显示当天的，或者只显示10行数据，甚至于可以不显示，这样响应速度就不会很慢影响用户体验。

2）数据初始化处理

尤其是上线新菜单，一定要考虑数据初始化处理，比如需要拉取一些数据的，或者需要跑几个脚本的，要写清楚。

3）历史数据处理

类似于第2点，这里一般是菜单的优化功能，是否会涉及到历史数据处理。

①本菜单

上线后，如果本菜单的字段优化涉及历史数据，比如一个Amazon的库存菜单，新增加了库存金额字段，保存下来的，上线后就需要将历史数据的库存金额刷上。

②关联菜单

功能关联到其他菜单的，还是拿库存举例，比如新增加一个菜单，【京东库存列表】，在【库存汇总列表】就需要加上京东库存，在途、在库，这里面的总库存字段计算逻辑也要更改，加上京东的库存，【京东库存列表】刷完数据后，【库存汇总列表】也需要处理。

4）定时任务

按字面意思拆分注意就好。

①时间

定时任务需要的时间点、频次，比如需要每天早上8:00:00开始执行脚本。

②任务

也就是脚本执行的规则，需要以哪些数据作为数据源，按怎样的逻辑执行，执行完成后数据如何存储，是否有按规则覆盖历史数据等。

5）数据对接形式

菜单是否需要对接别的系统，甚至于别的平台。

①同平台

对接同平台其他系统的，这个比较好处理些，大致有以下几种方式：

接口，使用接口调用的方式，可以是我们主动拿一些字段通过接口去获取，也可以是对方通过接口主动推过来，都可以。这里需要注意，是每次查询时动态获取，还是获取到的数据保存下来，需要写清楚，前者开发简单，后者会更方便。同步数据库表，也是分为主动和被动，这个占用资源会多一些，适合同步数据字段较多的功能，相当于把菜单的数据库表单复制两份，获取的是整张表。一边产生数据，另一张表就会有，可以是即时，也可以固定个脚本隔几分钟推一下数据。共享数据库表，也就是几个菜单都用这一张表，对比第2种，会更灵活些，也不会占用资源，如果需求一样，我会推荐这种形式。

②其他平台

也是两种形式，有接口的调用人家的开放接口，没有的想要获取数据，就需要Python了。

接口，拿平台对外公开的接口，我们去主动拉数据，一定要先查询接口文档，最好自己调用接口测试下能否获取到你需要的数据，这样开发会更明确。如果这方面处理起来比较困难，交给开发也好。爬虫，没有接口说明平台不想给你那么多数据，你就得用爬虫，目前国家禁止，一些平台也要设定很多反爬机制，需要多注意些，违规的自然不推荐。

好啦，需求文档介绍完了，有没有一些收获呢？欢迎大家留评讨论。

希望简单的文字对大家的产品学习有些帮助！

本文由人人都是产品经理作者【PM产品小6】，微信公众号：【PM产品小6】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。