作为产品经理重要的工作产出物之一，需求文档的完善和可用程度，直接决定了每个产品经理的专业水平。如果你的需求文档连开发都找不到可以吐槽的点，恭喜你，可以出师了。
周末跟之前的开发同事聚了一下，他跳槽了几家公司，在吐槽他们的产品经理，写的需求文档，真是一言难尽，记得之前他评价过我们公司的产品经理，是真的“把肉喂到开发嘴边去”，需求文档特别细，写代码看着就很舒服，省事太多。
是啊，这也是我一直要求的，不单单是产品经理，任何岗位都是，都要对自己的下游同事负责，这样整个团队的运转效率才是高效的。
当开发和测试不再吐槽你的需求文档了，你的产品专业就更上了一个台阶，你们的团队也会更和谐了。
因为我是做电商系统的，中后台，我就聊聊这方面的需求文档，应该怎么写，延伸下其实整个 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）审核驳回
审核驳回也是统称，可能是初审、复审，可能是运营审核、财务审核，可能是一级也可能是多级，都需要写清楚，跟审核通过很多共性，也有一些区分。
②驳回原因：
这个一定要的，必填项，需要让申请人明确原因。
③数据还原：
审核通过是数据往下走，那审核驳回就是还原数据，比如一个采购合同的付款申请被驳回了，这个合同的申请付款金额就要还原，不能影响后续的付款申请。
原文: https://www.msn.cn/zh-cn/news/other/%E5%BD%93%E5%BC%80%E5%8F%91%E5%92%8C%E6%B5%8B%E8%AF%95%E4%B8%8D%E5%86%8D%E5%90%90%E6%A7%BD%E4%BD%A0%E7%9A%84%E9%9C%80%E6%B1%82%E6%96%87%E6%A1%A3%E4%B9%8B%E5%90%8E/ar-BB1mizUZ?ocid=msedgntp&pc=DCTS&cvid=6657d2421a1f45ce838a8e96e9bd4b76&ei=49
当开发和测试不再吐槽你的需求文档之后…