为什么需要需求确认

先从这幅图看起，这不是心血来潮弄出来的，这是一个研究给出的结论（Kelly，Sherief and Hops 1992），我只给出了10倍代价的图，这个研究给出的结论是在需求阶段修复错误往往只要30分钟，而在测试过程中修正错误往往需要5~17个小时。
换句话说，就是在需求阶段修正错误是值得的，也是必须的。因此发现需求中的错误成了至关重要的活动，这些错误包括不符合用户的需要、没有正确的描述、需求冲突等等，我们把这个过程叫需求确认。
我们要讨论的内容就是需求确认的目的，何时开始需求确认，怎么做。

需求确认目的

这个问题很难回答，也很好回答，我们上面已经说过了，需求阶段修正错误可以付出很小的代价，也就是说能省钱。
我更喜欢《软件需求》中关于这个目的的描述：

1
2
3
4
5
6

1. 软件需求能够准确地描述了预期的系统能力和特征，并且这些能力和特征能够满足不同干系人的需要。
2. 从业务需求、系统需求、业务规则及其他来源中正确产线需求。
3. 需求是完整的、可行的、可验证的。
4. 所有需求都是必要的，并且整改需求集合满足业务目标。
5. 所有需求彼此是一致的。
6. 需求能够为后续的设计和构建提供充分的依据。

何时开始

如果你问我什么时候开始做需求确认，我的答案是越早越好，当然，前提是你完成了需求捕获和初步的需求分析。

需求确认的过程

首先我们要抛弃需求评审即是需求确认全部的思想，且需求确认也不是需求工作的终点。需求确认过程的活动应该是多个部分组成的，需求评审是必须的活动；原型可以根据需求的成熟度来决定是否采用原型，当然，也可以把原型理解为需求过程中的一种工具，可以随时使用；而需求测试是最有挑战的活动，很难去推动测试部门建立一种概念测试的观念，在没有实物前提下对需求测试对于很多测试工程师来讲，也是一个挑战。

需求评审

需求评审是一个强大的工具，可以帮助需求作者及开发团队发现需求不明确或者不可验证、定义不清晰导致无法设计等问题，那么，需求规格或需求文档的作者这个时候就要摆正心态，想想评审的单词是“Review”，就是让别人给你看一遍的意思。
评审的形式也多种多样，我们主要考虑非正式评审的需求走查和正式评审的需求审查

需求走查

Walkthrough，这个单词的字面意思是演练、预演、过一遍的意思，所以这个活动的重心也就出来了，那么如何有效的开展走查是一个重要的问题。

这是别人的见解

1
2

系统性的走查目的是为了评估一个软件产品。走查可能也会有让培训软件产品受众的目的。走查的作用还有交流技术、交流不同风格变化。 走查不仅可以发现异常，也可以指出不足之处（例如，软件产品的效率和可读性问题，设计或代码的模块化问题，或无法验证的规格）。参与走查有4个角色，分别是走查组长、记录者、作者、走查成员，走查至少需要2人。任何走查组成员的行政上级都不能参加走查。走查的最主要活动是作者或走查组长详细的展现所评审产物的每个部分，走查组识别并提出发现的异常和问题。走查的标准最少输出物总计有9项。走查不要求产物已经全部完成，可以按需高频开展。 
在本五维需求评审框架中，走查属于有预审的双人即时或者会议形式、技术方面的定期或高频的同级需求文档评审。双人走查是标准允许的最少人数。双人走查与会议形式走查其实存在较大的差异：双人走查可以使用一台普通显示器，利用普通能够坐下两人的工作位置即可，这样就能够高频按需开展，会议形式往往需要会议室，而会议室在多数组织是稀缺资源，如果所有项目团队都开展需求和代码会议走查，那么每二周一次的会议室预订都未必能够保证，所以难以按需开展。代码走查是常听到的词汇，但是需求走查在中文世界很少提到，而在敏捷软件开发中已经显示了其有效性。

需求审查

需求审查的单词是“inspection”，这个词也是有两部分，spection是检查的意思，加入前缀in，那么就是深入检查的意思，也就是审查啦。

需求原型

需求测试

需求确认中的常见误区

需求验证形式化：许多时候是为了过流程，否则会阻塞开发，因此走一个正儿八经的流程，但实际上并没有达到效果；
不重视：随便找个用户代表签字，责任为先，影响很不好；
开会跑偏题：时常会开成批评会、吵架会、翻书会、语法纠错会。