需求分析阶段的输出，是开发软件系统的重要基础。1996年，基本科学指标数据库（Essential Science Indicators; ESI）在对17个国家3800公司的调查中发现大多数（＞50％）的问题存在于需求规格说明和需求管理中。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证：①一致性。所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。②完整性。需求必须是完整的，规格说明书应该包括用户需要的每一个质量属性的分析。③可实现性。指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。④有效性。必须证明需求是正确有效的，确实能解决用户面对的问题。

验证软件需求的方法：①验证需求的一致性。当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“验证”方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、需求分析说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而遗留，以致软件开发工作不能在正确的基础上顺利进行。为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性，从而能有效地保证软件需求的一致性。②验证需求的可实现性。为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。③验证需求的完整性和有效性。只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要（即需求的有效性），只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要（特别是全新系统，以前没类似经验时，情况更是如此）。只有当他们实际使用时，才能完整确切地提出他们的需要。一般先交付一个原型系统，用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。

随着互联网应用的发展，通过最小可行产品（MVP）发布上线，根据用户反馈快速渐进获取真实需求，甚至通过“试错”法低成本的验证需求。尽管这种方式看上去似乎不完美，但从软件工程的实质效果看，其效果明显优于“纸上谈兵”式的验证方法。因为大多数场景下，没有任何人知道全部需求，包括用户自己和需求分析师，只有快速小周期交付并验证，才能获取需求并验证需求。