产品经理必读：需求文档自检清单

我们公司之前是没有专业的测试的，所以测试都是我自己上。

我们的系统主要是数据逻辑比较复杂，一般我自己在测试时，主要是在正向逻辑上进行验证。最多是在数据逻辑上考虑闭合，再为下一次写相似的需求时，把类似的数据漏洞进行填补。

因此之前的测试中，很容易是自己写的逻辑，自己发现逻辑漏洞，然后改掉。

现在我们具备了专业的测试团队之后，发现专业的测试同事，他们会关注各种细节边界，这让我觉得需求文档上写的需求过于简单了。

这种情况也不是一开始就暴露了，在需求评审和测试用例评审的时候，可能是大家都在原有的模式中，比较关注主线逻辑，因此对这些细节并没有在意。

这导致测试过程中发现这些问题时，开发觉得需求增加了。这样很影响项目的正常交付，未来也不好预估工期。

因此我整理这份需求文档的自检清单，防止设计过程中的遗留和问题。

关于需求文档的自检清单，我主要分三个方面：从文档表达上、界面交互上和逻辑上。

一、文档表达

我认为好的文档，最基础的就是表达上能让开发测试清楚的知道需求，减少反复的需求确认，因此我把它作为第一点。

1. 错别字

对于错别字，很容易导致一些误会，让开发理解错误的需求。或者对于一些系统提示，粗心的开发会直接根据文档复制粘贴，不进行检查，这样的结果就是系统提示是带有错别字的提示。

所以这一定是我们要敲响鸣钟的第一点，不能写错别字。

2. 言语通顺性

团队里有一个小姑娘，每次写出的文档，表达出来的意思要么很口头，要么读起来和需求像是两个意思，甚至语言都不通顺。

我对她的建议是：每次写好文档，都自己反复的去读，让语句能够通顺；如果实在不行，就看看其他人优秀的文档，是如何进行表达的，进行模仿着写。但一定要自己反复读自己的文档，确认言语是通顺的。

3. 语言表达的简单整洁

这种情况是对于一个比较复杂的交互和逻辑，有时候很容易在表达上变得很拗口。

虽然意思的一样的，开发在理解后也是没问题的，但是读起来就是需要花一定时间去理解；这会加大双方的沟通成本，开发会确认自己是否有理解错误。

个人对这种情况的描述，一般情况下是尽量进行拆分，把逻辑分层段。能进行举例说明的都进行举例说明。

二、界面交互

在界面交互上，对于只陷在主线逻辑是否走通的思维里时，往往会忽略很多异常情况。

1. 界面布局

最基本的，就是界面设计时的布局一致性等。这主要靠设计原则来规避，具体可根据“尼尔森十大可用性原则”进行自检。

2. 非正向操作

用户按流程进行正向的操作的时候就是我们原本的设计，但实际情况中，如果用户没有按照正向流程进行使用，且系统不进行提示，这很容易对系统数据产生影响；或者因为开发没有考虑到这种情况，导致流程卡住不能正常进行。

因此在需求设计时，就需要考虑多种非正向操作的情况，对于非正向操作进行正向操作的提示或流程的阻碍。

3. 数据计算异常

因为是涉及的计算逻辑比较多，参数的未维护或者维护错误、中间过程计算异常，都会导致最终结果无法展示。

若产品中未考虑这些情况，当出现数据计算异常时，用户甚至不知道是哪里出的错误，只能求助于服务公司。

因此，友好的提示：能够快速让用户意识到错误点在哪里，快速的将流程走下去，而不是花人力去寻找一些简单的问题，浪费业务的时间。

4. 数据填写的异常

这个其实很多情况是上一个“数据计算异常”的前置条件，如输入的数据格式不正确、输入的数据过长、输入的数据为空，这些都很容易导致后续的计算出错。

输入的数据在逻辑上处于什么作用也需进行分析，需要根据逻辑来判断是否要对该数据增加其他校验。

三、逻辑

因为是数据系统，逻辑上的问题会比较多。

我们有专门的数据分析团队，他们会给我进行一些特殊数据上的特殊逻辑处理，但是实际的业务数据中还是会出现一些我们考虑不全面的情况。

1. 逻辑上是否闭合、是否存在断层

一般在数据分析提供给我们逻辑时，我们会进行逻辑图的绘制。这一过程中，逻辑是否走通、是否存在断层比较容易发现，这一习惯能保证正向逻辑上不存在漏洞。

2. 存在极端值的情况

虽然数据分析是通过实际值进行检验逻辑的正确性的，但因为样本数据过小或者样本数据中不存在极端值的情况，所以很容易在测试同事测试时造了极端值或者在客户遇到了极端情况下才暴露出问题。

这些极端值是存在共性的，因此把遇到极端值的情况进行罗列，在后续的文档编写时进行对照，能避免反复遇到同类问题。

四、总结

自检清单的对照，是为了让我们吸取教训。

在今后的文档编写时，更注重输出文档的需求准确性和逻辑严密性。让人一读文档就知道需求是什么，且开发的系统是完善的。

本文由 @汪仔6880 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议