需求工程中的缺陷将给项目的成功带来极大风险，导致缺陷的原因主要包括以下方面：
缺乏足够的用户参与
　　客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。然而，还是应该在项目的早期让具有代表性的用户直接参与到开发队伍中，并一同经历整个开发过程。

用户需求不断增加
　　在开发过程中，用户需求经常发生变化，但是不断的变更会使其整体结构越来越乱，整个程序也难以理解和维护。如果要减少需求变更的影响范围，就必须在项目的开始对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。

需求模棱两可
　　模棱两可是需求规格说明中最严重的问题，它意味着不同的人对需求说明产生了不同的理解，或者是同一个人能用不止一个方式来解释某项需求说明。模棱两可的需求带来的后果便是返工--重做一些你认为已做好的事情，返工会耗费开发总费用的40%，而70%～85%的重做是由于需求方面的错误引起的。
　　处理模棱两可需求的一种方法是组织不同的人员从不同的角度审查需求。仅仅阅读需求文档不可能解决模棱两可的问题，如果不同的评审者从不同的角度对需求说明给予解释，而每个评审人员都能真正了解需求文档，这样二义性就不会直到项目后期才被发现。

添加不必要的特性
　　有时候，开发人员力图增加一些"用户欣赏"但需求规格说明中并未涉及的新功能，然而常常是用户并不认为这些功能性很有用。开发人员应当为客户构思方案，并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户的需要和允许时限内的技术可行性之间求得平衡。开发人员应努力使功能简单易用，而不要未经客户同意，自作主张。同样，客户有时也可能要求一些看上去"时髦"，但缺乏实用价值的功能，而实现这些功能只是浪费时间和成本。
　　为了避免这些危害，你应当明白为什么要包括这些功能，以及这些功能的"来龙去脉"，从而使需求分析过程始终是关注那些能使用户完成其业务的核心功能。

规格说明过于简单
　　客户往往不明白需求分析的重要性，只是提供一份十分简略的规格说明，仅涉及产品概念上的内容，然后让开发人员在项目进展中去完善，从而导致开发人员先建立产品结构再完成需求说明。这种方法可能适合于某些尖端研究性的产品或需求本身就十分灵活的情况，但在大多数情况下，它会给开发人员带来挫折，也会给客户带来烦恼。

忽略了用户分类
　　大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。
　　当今的软件行业依然存在着轻视需求工作的现象，而需求错误导致最后交付的软件产品不能满足用户的需要，因此，高质量的需求工程是软件项目成功的前提。

　　需求工程中的缺陷将给项目成功带来极大风险，如产品的成本过高、产品的功能和质量无法完全满足用户的期望等等。即使一个项目团队的人员和配备都很不错，但不重视需求过程也会付出惨痛的代价。总体来说，导致需求缺陷的原因主要体现在三个方面：需求的沟通与理解、需求的变化与控制、需求说明的明确与完整。
　　正确的需求过程强调产品开发中的通力合作，包括在整个项目过程中多方风险承担者（如客户、用户、业务或需求分析员、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者）的积极努力。让用户积极地参与需求收集过程能使产品更富有吸引力，而且能拥有忠实的客户关系。通过了解用户的任务需求而不仅仅局限于一些"华丽"的特性，你能避免在无用功能上白耗精力，并且用户的参与能弥补用户期望和开发者实际开发之间的"鸿沟（期望差异）"。将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成，也能确保软硬件系统功能匹配适当。有效的变更控制和影响分析过程也能降低需求变更带来的负面影响。最后，将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量，以使所有风险承担者感到满意。