当开拓和测试不再吐槽你的需求文档之后……

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

是啊，这也是我一贯哀求的，不单单是产品经理，任何岗位都是，都要对自己的下贱同事卖力，这样全体团队的运转效率才是高效的。

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

由于我是做电商系统的，中后台，我就聊聊这方面的需求文档，该当怎么写，延伸下实在全体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）添加/新增

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

①正常完成情形：

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

②添加里面的字段：

③校验：

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

①可勾选数量：

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

②可编辑条件：

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

③编辑后的状态：

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

④其他校验：

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

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）数据对接形式

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

①同平台

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

②其他平台

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

好啦，需求文档先容完了，有没有一些收成呢？欢迎大家留评谈论。

希望大略的笔墨对大家的产品学习有些帮助！

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

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