4.5.1　需求验证的任务

需求验证是以用户需求为基础的，确定系统需求是否完整、一致、正确和可行。不可能在需求开发阶段真正进行任何测试，因为还没有可执行的软件。然而，可以在开发组编写代码之前，以需求为基础建立概念性测试用例，并使用它们发现软件需求规格说明中的错误、二义性和遗漏，还可以进行模型分析。

充分理解需求，确保需求理解与需求分析人员是一致的；从可测试的角度发现《用户需求说明书》中不可测试的需求，提醒需求分析人员尽早修改；从测试人员的角度发现《用户需求说明书》中不完整性的需求，提醒需求分析人员及时补充遗漏的这部分用户需求。

通过验证，有利于以下几方面：

（1）减少需求缺陷。

（2）减少返工。

（3）减少不必要的特性。

（4）降低改进成本。

（5）加快开发进度。

（6）提高沟通效率。

（7）控制需求改变。

（8）对系统测试的评估更准确。

（9）提高客户和开发人员的满意度。

需求验证是需求开发的第四部分（前三部分为获取、分析和编写需求规格说明），需求验证所包括的活动是为了确定以下几方面的内容：

（1）软件需求规格说明正确描述了预期的系统行为和特征。

（2）从系统需求或其他来源中得到软件需求。

（3）需求是完整的和高质量的。

（4）所有对需求的看法是一致的。

（5）需求为继续进行产品设计、构造和测试提供了足够的基础。

我们可以再简单理解一下验证和确认的区别，判断最终开发出来的系统和用户想要的系统是否一致的过程叫做确认，对于所理解和描述的需求和当初的想法是否是一致的过程叫做验证。需求的验证包括很多内容，涉及软件开发中上下游相关人员参与。首先结构和文档化后的需求需要用户来验证是否和他们的想法是一致的，是否把用户的真实意图描述清楚了，以保证需求本身的正确性。对于后续设计开发阶段的人员，也需要对需求进行评审以保证需求的可实现性，确认需求描述是否清楚，是否可以实现；对于业务对象，需要确认流程和规则是否存在不可实现的模糊描述词语；对于测试人员，主要确认需求是否是可测试的，是否在需求描述中引入了较多的易用、较好、应该等不确定和不可测试的词语。对于大型的软件项目，如果有专门的产品化标准和UI（User Interface）组件，还需要对需求的易用性和产品交互等方面进行评估，以评价整个软件系统的产品化。

确认软件系统已经开发完成后交付给用户后验收的时候，用户确认系统是否实现了当初的需求。为了保证确认过程的顺利，就必须重视需求验证的过程，需求验证不仅仅是需求阶段对需求文档的评审，还需要关注设计、开发等各阶段对需求的实现情况的验证。