你可以这样写需求文档 第02期：字段取值

作者简介

Jarvan，前百丽、环球易购、顺丰产品经理，现某互联网公司内部系统负责人，从 0 到 1 搭建团队、系统，目前管理团队近 20 人，从事跨境电商、零售行业产品经理多年，拥有丰富的后台产品经验。

我们说产品经理对外输出有三个内容，需求文档、原型图、流程图，其中需求文档承载了整个设计目标、过程及最终结果，所以是笔者认为产品经理最重要的输出点。

紧接上篇，笔者今天跟大家聊下需求里面的具体字段取值该怎么写。

六．菜单路径

很简单，就是让大家明确接下来的内容是哪个菜单的，不管是新开菜单还是原有菜单优化，一定要描写清楚，方便查找。

接下来的第七点开始，重点来了！

七．字段取值

1.描述整体字段如何取值：

整体描述下这个菜单的数据是怎么取过来的，比如是有定时任务，固定每天几点从 xx 菜单根据 xx + xx 维度或者根据 xx 规则来匹配出来的。

2.字段名称：

每个表单的字段，要严格按照原型图的顺序来，要不然开发和测试在看原型图和需求文档时，就会发生一些分歧，如果是优化需求，加的字段还要描述清楚位置，比如在 xx 字段右侧。

3.取值来源：

精确到字段，这个字段是如何取值的，用户导入和添加，计算，字段关联，系统自动生成，还是根据什么规则匹配出来，都需要描述清楚，同时还需要写明字段是需保存下来还是一个动态查询，通常来说，笔者都建议保存下来，一是方便查询条件的查询，二是方便其他菜单的字段取值，三是如果是业务数据，便于后续回找问题。

4.取值表名：

如果是对接的其他平台，比如 api 拉的京东的订单，Python 获取的 Amazon 的 business report，这些都需要在这里写清楚表名，需要根据表名去核对具体哪个字段。

5.取值表字段名称：

同第4点，描述情况两张表单的字段对应关系，这里着重强调两个点，一是如果拉下来的是中文表单，除非涉及本身系统字段名称，否则都建议用拉下来的表单本身字段；二是如果涉及多语言，比如有些 Amazon 的表单不同站点都用的本国语言，那就需要将不同语言的字段对应关系写清楚。如果需要翻译的最好是找业务方来确认下，自己的直译又或是谷歌、百度等的翻译，有时候真的不忍直视。

6.字段举例：

顾名思义，在最后写几个字段便于大家更好地理解。

八．查询条件

同样，查询条件的顺序也要跟原型图一致，如果是后续添加的，也一定要跟字段一样，描述清楚这个查询条件的位置。

查询条件大致分为以下几种：

1.文本格式

需要写明能支持什么类型的内容输入，比如只支持文字，或只支持数字等；是否支持多个内容查询，如果支持多个内容中间要用什么符号隔开；是只支持精准查询还是可以支持模糊查询，模糊查询是单边模糊还是两边模糊。

针对上面几点，笔者建议格式可以不固定，多个内容查询尽量不需要，需要的话用个英文逗号好一些，对于数据量大的菜单尽量不要模糊查询，会很慢。

2.下拉框格式

固定的一些控件，比如日期等；是固定内容还是动态内容，固定内容包括哪些点，动态内容是关联哪些菜单哪些字段，要不要去重等；默认为空还是某个值，支持多选还是只有单选；是否支持模糊查询（下拉框内容本身的输入字段查询，比如一些内容较多的查询条件）。

3.复选（单选）格式

这算是另一类下拉框格式，只是把内容放在了外面，方便一些。是只能选中一个还是可以同时选中多个，对于系统框架符合或者确实挺少的查询条件，可以采取这种形式，不过笔者不太建议，因为太占空间了。

4.时间格式

这里单独讲一下时间格式的，到年维度、月维度，或是天维度、秒维度，市面上都有很多封装好的控件，这里强调一个，如果你的查询字段是精确到秒但是你的查询条件是到天，那就需要你写清楚，前区间一定是到 00:00:00，后区间一定是到 23:59:59，这是很多产品忽略并且开发会犯错的点，一定要注意！

今天先聊到这里，下一讲会来细聊“功能按钮如何写”，同样重点！

写在最后：

笔者见过很多产品经理的“一句话需求”，也见过很多特别特别细的文档，两者对比真的差距明显。笔者一直认为“专业的人做专业的事”，既然你身为一个产品经理，对你的客户负责，对你的团队负责，需要将你该做的内容做好，当然了，如果团队比较成熟，开发和测试对内容也是知根知底，在不影响质量的情况下，为了节省时间，可以弱化一些需求文档的内容。

用最简单的设计、最明确的流程、最通俗的文字来实现用户最复杂的需求，这是笔者的坚守，也是笔者的追求，希望这篇文章可以给大家一些帮助，感恩。