需求有效性验证是要检验需求能否反映客户的意愿。它和需求分析有很多共性，都是要发现需求中的问题，但它们是截然不同的过程，前者关心的是需求文档完整的草稿，而后者关心的是不完整的需求。
需求有效性验证非常重要，如果在后续的开发或者系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。因需求问题而对系统做变更的成本要比修改设计或者代码错误的成本大得多，原因是需求的变化总是会改变相应的系统设计和实现，进而使系统必须重新测试。
在需求有效性验证过程中，要对需求文档中定义的需求执行多种类型的检查。
（1）正确性检查。开发人员和用户都应复查需求，以确保将用户的需要充分、正确地表达出来。
（2）有效性检查。某个用户可能认为系统应该执行某项功能，但是进一步思考分析后，可能发现还要增加另一些功能，或发现系统需要的其实是完全不同的功能。系统对其他用户也可能需要不同的功能。因此，任何一组需求都必须在不同用户之间协商确定。
（3）一致性检查。需求不应该相互冲突，即对同一个系统功能不应出现不同的或相互矛盾的描述。
（4）完备性检查。应该包括所有系统用户需要的功能和约束。在需求中应该对所有可能的状态、状态变化、转入、产品和约束都做出描述。
（5）现实性检查。根据对已有技术的了解，检查需求以保证能使用现有的技术来实现。这些检查还要考虑到系统开发的预算和进度安排。
（6）可检验性检查。为了减少在客户和开发商之间可能的争议，被描述的系统需求应该总是可以检验的，即能设计出一组检查方法来验证交付的系统是否能满足需求。
（7）可跟踪性检查。检查是否每一系统功能都能被跟踪至它的需求集合。(www.xing528.com)
下面一些需求有效性验证技术可以联合使用或者单独使用：
（1）需求评审。由一组评审人员对需求进行系统性分析。
（2）原型建立。为系统用户和最终用户提供一个可执行的系统原型，以此来实际检查系统是否符合他们真正的需要。
（3）测试用例生成。理想情况下的需求是可测试的，这也是近几年软件工程新的热点之一。如果用测试作为需求有效性验证的方法，就要设计具体的测试方法，这样可以发现需求中的很多问题。如果一个测试的设计很困难或者不可能，通常意味着需求的实现将会很困难，应该重新考虑需求。
（4）自动的一致性分析。如果需求采用结构化或者形式化的方法表示，并已经形成了系统模型，这时就可以用CASE工具来检验模型的一致性。
只有目标系统的用户才真正知道软件需求规约书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要（即需求的有效性），只有在用户的密切合作下才能完成。然而，许多用户并不能清楚地认识到他们的需要（特别在要开发的系统是全新的时候，情况更是如此），不能有效地比较陈述的需求和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出需要。
理想的做法是先根据需求分析的结果开发出一个软件系统，请用户试用一段时间以便能认识到他们的实际需要是什么，在此基础上再写出正式的“正确的”规约书。但是，这种做法将使软件成本增加一倍，因此实际上几乎不可能采用这种方法。使用原型系统是一个比较现实的替代方法，开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的成本和时间。用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。
需求有效性验证的困难不应低估。论证一组需求是否符合用户需要是很困难的，用户需要勾画出系统的操作过程并构想出如何把系统应用到实际工作中去，这种抽象分析工作对一个有经验的计算机专家也很艰巨。结果往往是不可能发现所有的需求问题，需求确认之后不可避免地再发生一些遗漏和错误理解的变更。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
