5.2 需求分析和评审

5.2.1 需求分析

测试人员从软件生命周期的需求阶段就开始介入。在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即哪些功能点需重点测试、哪些无需，以便同步制定测试计划。

对于需求要关注的地方：

找出不可测试的需求点。
找出用户提出的、但未被完整描述的需求点。
找出描述有歧义、二义性、模糊的需求点。
客户需求。
市场同类型软件需求。
行业规范。
特殊需求。

5.2.2 需求测试

在需求测试中，重点检查需求规格说明书中是否存在描述不准确、需求定义模糊、需求用例不正确、语言存在二义性等等问题。如果不对这些文档进行检查，将可能在后期的测试工作中不断接到系统修改、需求变更等问题。

需求测试我们主要从以下几个方面考虑：

完整性：每一项需求都必须将所要实现的功能描述清楚，从而为开发人员设计和实现这些功能提供所有必要的需求依据。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾，或者与我们的项目宣传资料要一致。
可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明书的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如需求用例或别的来源。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在SRS（软件需求规格说明书）中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

需求规格说明书（SRS）测试步骤：

获取最新版本的SRS，同时尽量取得用户原始需求文档；
阅读和尝试理解SRS描述的所有需求项；
对照SRS Review Checklist进行检查并记录；
针对检查结果进行讨论、修订SRS后回到第一步，直到Checklist的所有项通过。

需求测试检查表：

序号	内容	满足/正确	问题描述
1	是否描述系统的所有输入，包括输入源、准确性、取值范围和出现频率？
2	是否描述系统的所有输出，包括输出的目标、准确性、取值范围、出现频率和格式？
3	是否描述所有(主要)的报表格式？
4	是否描述所有硬件和软件的外部接口？
5	是否描述所有的通信接口，包括握手协议、差错检测和通信协议？
6	从用户的角度来看，是否描述了对所有必要操作的预计响应时间？
7	是否对时间方面问题进行考虑，如处理时间、数据传输和系统的吞吐量？
8	是否描述用户想要完成的所有(主要)任务？
9	是否每个任务都描述了所使用的数据及产生的数据？
10	是否描述了安全级别？
11	是否描述了系统的可靠性，包括软件产生故障的后果、故障后重要数据的保护、错误检测和恢复？
12	是否描述了可接受的折中原则，如健壮性和正确性之间的选择？
13	是否详细说明了(最大)内存容量和(最大)存储容量？
14	是否详细说明了系统的可维护性，包括适应操作环境变化的能力、与其它软件的接口、精确性、性能和附加的可以预知的性能？
15	有些信息只有到开发时才能获得，是否对这些信息不完全的领域进行描述？
16	你是否对需求的某些部分感到不满意？是否有些部分不可能实现，但为了取悦客户或上司而放在需求之中？
17	是否用用户语言，站在用户角度上来写需求？用户这样认为吗？
18	是否所有的需求都避免与其它的需求发生冲突？
19	需求是否避免了对设计的详细说明？
20	对需求的描述是否一致？是否有的需求说明很详细，有的需求说明很粗糙？
21	需求是否足够清晰，以至可以转交给一个独立小组来实现，并能够被理解？
22	每个条款都是描述问题及解决问题吗？每个条款都能被追溯到问题的源泉？

产品经理在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，参与对需求分析文档的评审，检查文档是否满足了需求，是否与需求一致等等。

5.2.3 评审

在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员，对软件产品进行评价和批准。目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施。同时找出在性能、安全性和经济方面的可能的改进。

需求评审会议通常由产品经理主持并讲解，测试团队可以使用上述需求分析和测试的方法参与并对需求得到细致完整的理解。

5.2.4 输出

需求评审会议在与会的各方对需求规格说明书的理解达成一致时通过，并输出需求规格说明书。

在和客户以及项目组的交流确认过程中，也会以原型图的形式得出项目基本的外观布局和各个模块部分之间的关系。

5.2.5 需求变更

虽然经过了严格的流程以及评审，但是在实际的研发项目中，需求发生变化是普遍存在的现象，发生了需求变更，通常遵循下面的流程进行处理：

建立变更控制委员会（CCB）：变更控制委员会应该由项目的相关人员组成，由他们确定哪些需求需要变更，这些变更是否在项目范围之内，并对这些变更进行评估来作为需求变更接受或放弃的标准。
变更申请：如果用户需要变更需求，则填写《需求变更申请》，经客户方和服务方共同确认后，发送给变更控制委员会；
变更分析：变更控制委员会召集相关人员对《需求变更申请》进行分析，评估，得出结果接受变更或者拒绝变更，并给出决定哪些变更需要修改和什么时候修改，哪些变更无法修改并说明原因；
变更实施：评审通过的《需求变更申请》，确定开发时间和纳入的版本，制定开发计划；修订并重新评审《需求规格说明书》；
变更验收：对于需求变更而进行的版本更新，需交付相应的《版本更新说明》。