编辑导语：对付产物司理来说，建造一份满足的需求文档是必需要把握的技术。然而在设计需求文档的进程中，涉及到许多的小细节，稍不留意就很难取得满足的结果。如此一来，就要学会对需求文档举办自检，本文作者就为我们列出了一份清单。

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

我们的系统主要是数据逻辑较量巨大，一般我本身在测试时，主要是在正向逻辑长举办验证。最多是在数据逻辑上思量闭合，再为下一次写相似的需求时，把雷同的数据裂痕举办填补。

因此之前的测试中，很容易是本身写的逻辑，本身发明逻辑裂痕，然后改掉。

此刻我们具备了专业的测试团队之后，发明专业的测试同事，他们会存眷各类细节界线，这让我以为需求文档上写的需求过于简朴了。

这种环境也不是一开始就袒露了，在需求评审和测试用例评审的时候，大概是各人都在原有的模式中，较量存眷主线逻辑，因此对这些细节并没有在意。

这导致测试进程中发明这些问题时，开觉察得需求增加了。这样很影响项目标正常交付，将来也欠好预估工期。

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

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

一、文档表达

我认为好的文档，最基本的就是表达上能让开拓测试清楚的知道需求，淘汰重复的需求确认，因此我把它作为之一点。

1. 错别字

对付错别字，很容易导致一些误会，让开拓领略错误的需求。可能对付一些系统提示，粗心的开拓会直接按照文档复制粘贴，不举办查抄，这样的功效就是系统提示是带有错别字的提示。

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

2. 言语通顺性

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

我对她的发起是：每次写好文档，都本身重复的去读，让语句可以或许通顺；假如实在不可，就看看其他人优秀的文档，是如何举办表达的，举办仿照着写。但必然要本身重复读本身的文档，确认言语是通顺的。

3. 语言表达的简朴整洁

这种环境是对付一个较量巨大的交互和逻辑，有时候很容易在表达上变得很拗口。

固然意思的一样的，开拓在领略后也是没问题的，可是读起来就是需要花一按时间去领略；这会加大两边的相同本钱，开拓会确认本身是否有领略错误。

小我私家对这种环境的描写，一般环境下是只管举办拆分，把逻辑分层段。能举办举例说明的都举办举例说明。

二、界面交互

在界面交互上，对付只陷在主线逻辑是否走通的思维里时，往往会忽略许多异常环境。

1. 界面机关

最根基的，就是界面设计时的机关一致性等。这主要靠设计原则来规避，详细可按照“尼尔森十大可用性原则”举办自检。

2. 非正向操纵

用户按流程举办正向的操纵的时候就是我们原本的设计，但实际环境中，假如用户没有凭据正向流程举办利用，且系统不举办提示，这很容易对系统数据发生影响；可能因为开拓没有思量到这种环境，导致流程卡住不能正常举办。

因此在需求设计时，就需要思量多种非正向操纵的环境，对付非正向操纵举办正向操纵的提示或流程的阻碍。

3. 数据计较异常

因为是涉及的计较逻辑较量多，参数的未维护可能维护错误、中间进程计较异常，城市导致最终功效无法展示。

若产物中未思量这些环境，当呈现数据计较异常时，用户甚至不知道是那边出的错误，只能求助于处事公司。

因此，友好的提示：可以或许快速让用户意识到错误点在那边，快速的将流程走下去，而不是花人力去寻找一些简朴的问题，挥霍业务的时间。

4. 数据填写的异常

这个其实许多环境是上一个“数据计较异常”的前置条件，如输入的数据名目不正确、输入的数据过长、输入的数据为空，这些都很容易导致后续的计较堕落。

输入的数据在逻辑上处于什么浸染也需举办阐明，需要按照逻辑来判定是否要对该数据增加其他校验。

三、逻辑

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

我们有专门的数据阐明团队，他们会给我举办一些非凡数据上的非凡逻辑处理惩罚，可是实际的业务数据中照旧会呈现一些我们思量不全面的环境。

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