第2章 需求和设计评审

只要是人，都要犯错误。当一个文档完成后，其中或多或少都会存在一些问题。软件产品的需求定义就更困难了，要把各种用户需求收集全或挖掘出来几乎完全不可能。即使获得完整的用户需求，要真正理解用户的本意也有难度，和客户的理解可能会有出入，准确描述这些需求也不是一件容易的事。

而且一旦需求出了问题，对后期的设计、编码影响很大，最终会影响交付的产品。即使在后期系统测试发现问题，也需要修改设计和代码，带来很大的返工成本。所以有必要进行需求评审，将需求定义（文档）中的问题找出来。需求评审，这项工作能实现一箭双雕的效果，不仅能发现需求的问题，而且能帮助大家更好地理解需求，达成一致的理解，有利于今后设计、编程、单元测试、系统测试、验收测试等工作的开展。

同样，设计也会存在问题，也需要评审，纠正设计问题，更好地确保系统的功能特性，特别是非功能特性，在设计中就得到充分的考虑。在这一系列测试活动中，需求评审、设计评审都属于“静态测试”，将测试活动延伸到系统需求和设计阶段，使测试活动贯穿整个生命周期，更好地将质量构建在软件研发过程中。在这一章，我们主要是通过需求和设计评审来掌握静态测试方法，包括评审过程和方法、文档测试标准等。