在平常的工作中，我们总是会说需求不够明确，这是一种很笼统的说法，是我们对一份需求文档抽象的评价，其中包含的含义可能是如下情况：需求存在二义性、需求不明确、需求不完整、需求不正确，等等。

　　当我们反馈问题的时候，仅仅反馈需求不明确或者需求质量不好，是没有意义的，我们必须明确的指出具体的问题所在，这样才有利于需求的完善和质量提升。下面需求二义性、需求正确性、需求完整性几个方面进行说明。

　　一.需求二义性

　　需求描述的二义性一方面是指不同读者对需求说明产生了不同的理解；另一方面是指同一读者能用不同的方式来解释某个需求说明。

　　在需求阅读过程中，只要是不能够明确清晰理解的内容，都需要提出来，让PD给予确认修改。如某需求文档中对商品价格的描述，在不同的地方分别使用了价格、单价，这很容易引导读者以为是两个概念。

　　二.需求正确性

　　需求文档描述的内容，除了要求清晰的，还要保证内容是正确的。我们可以从以下方面进行检查：

　　1.功能是否正确合理

　　任何一个需求都不会凭空而降，都有它背后的理由。考虑问题的时候换位思考，运营/pd推出该需求的动机是什么，明白了背景，再去思考需求是否能满足背景要求，是否有损害到真正用户的利益。

　　2.与现有系统业务是否冲突矛盾

　　如果需求是和现有的业务紧密联系的，需要对现有业务进行一个梳理，确认新的需求不会和已有的功能是冲突矛盾的，或者与原有的业务意图是背离的。

　　3.用户对象是否正确

　　用户对象，会涉及到用户权限的问题，主要是看功能涉众描述是否正确，避免错乱和遗漏。

　　三.需求完整性

　　需求完整性包含描述不细致、不完整和缺失。

　　1.需求不细致

　　需求文档对一个功能点进行了描述，但是颗粒过于粗糙，细节信息没有被传递。比较常见的是页面元素的处理。比如这样的一个描述说明：点击网点名称，打开网点详细信息。网点详细信息页面需要输出哪些内容是不明确的，面对这样一个需求，开发可以根据自己的理解对信息进行输出，但是可能会与PD的预期有出入。

　　2.需求不完整

　　不完整是指需求文档有说明，但是没有给出明确定义说明。比如某个PRD文档中，有文字提及下单模式有预付金下单和非预付金下单，但文档中有详细描述的只有预付金下单，非预付金下单还没有来得露脸消失了，让读者完全搞不懂这是一种什么样的下单模式。

　　3.需求缺失

　　需求缺失则是彻底的遗漏，整个文档都没有出现，又可分为业务规则缺失和功能缺失。要找出需求缺失问题，必须熟读需求文档。

　　查找业务规则缺失问题，需要有业务基础，对现有的相关业务知识进行学习了解，对需求的背景进行剖析，在明确需求目的前提下，对需求已经提及的业务规则分析，查找是否有遗漏。

　　查找功能缺失问题，可以通过画系统功能模块框架图和活动图，明确各个功能是否能完整的流转，如果有数据是不能到达终点的，则是存在缺失的功能点。