转自卖烧烤的鱼的博客：http://www.cnblogs.com/mayingbao/archive/2006/07/19/454925.html
验证 & 确认（Verification & Validation）的定义
验证：我们在正确地构建产品吗？（Are we building the product right?）
确认：我们在构建正确的产品吗？（Are we building the right product?）
验证&确认之间的差异：
验证：意即开发的每个阶段都遵循过程和标准。质量是它的目标。
确认：意即整个产品和过程都迎合用户的需要。用户满意是它的目标。
验证&确认的两个先决条件
1. 首先要了解谁是你的客户
Ø 了解他们不同的议程
Ø 你需要在识别，验证和确认需求时能够提供给你帮助的客户
Ø 很可能－你需要最终用户和投资者。每个人都可以在一定的关键领域帮助你。
2. 了解你的组织是如何开发软件
Ø 了解你组织采用的过程
也就是说，组织中：
l 要有一个书面化的过程
l 遵循这个过程
l 有需要时更新过程
l 确保过程真的可以工作
l 确保你使用了一个生命周期
l 遵循这个生命周期
l 有需要时更新生命周期并使用备选的生命周期
l 简言之－知道你实际上正在做什么
需求的验证
如上述，你需要知道你的客户是谁，因为他们必须参与到验证中。
验证的三个组成部分：
Ø 检查
Ø 度量标准
Ø 变更管理
检查
这里的问题是人们会用不同的方式解释需求。为了防止这个问题，你需要指出以下两个不同的问题：
l 我们所有人是用同种方式解释需求吗？
l 需求是完整的吗？
最好解决这些问题的办法就是利用checklist来确保你在检查时问了正确的问题。
另外，一个受过培训的，且有准备的检查小组加上足够的准备可以帮助
检查什么
l 软件需求说明书（或者任何你用来列举需求的文档）
l SRS的源文件或初始文件或其他任何先于SRS的文档
需求评审检查表
l 问题划分的完全吗？
l 外部和内部接口正确定义了吗
l 每个需求都可以测试吗
l 每个需求都可以被编号且容易被识别吗（需求是可追溯的吗？）
l 为用户做了必需的原型吗
l 阐述了隐含的需求吗（如数度，错误和响应时间）
l 在其他系统元素的限制条件里性能是可达到的吗？
l 需求和计划，资源和预算一致吗
l 显示给用户的信息列在需求里了吗
l 在需求了提及了未来的问题（更新，已计划的移植，长期使用）吗
你寻找的是什么。。。
需求是否：
Ø 明确
Ø 完整
Ø 可验证
Ø 一致的
Ø 可修改
Ø 可追溯
Ø 可用的
Ø 可以方便划分优先级别（可选）
确认对于软件来说是很困难的
基于三个概念
l 测试
l 度量标准
l 质量保证团队
测试是最不重要的，因为很难在编码之前测试需求，而且大多需求方法（原型，模拟）依赖大量的假设和简化。
最好确认需求的方法是在需求检查过程中让客户参与
l 最终用户
l 程序办公室
l 用户管理层
最终用户是最有效的，但也是最难让他参与。最终用户一般关注的是具体的一些小的细节，而需求关注的是大的方面。
确认一般只发生两次：
l 在需求收集/分析/评审期间
l 在编码之后，测试的时候。这是QA团队的职责。
其实这是相当危险的！首先QA和测试是极其昂贵的！！其次你可以做的任何缩短QA/测试阶段的事情都应该是很有用的。如果你依赖QA和测试来发现和修复错误，你的软件将很有可能
Ø 延迟发布
Ø 超支
Ø 在你发货后仍然充满了错误
确认总结
总言之－确认要求实施者和客户之间的tie-in。如果你不能拉你想要的那么多客户，那么就指派人做ALAC（Act Like A customer）。
建议大家关注以下两个方面
l 系统的外部接口
l 模块和子系统之间的内部接口