大多数软件开发者都遭遇过在开发后期或产品交付后才意识到需求问题的情况。一旦基于原始需求的工作完成，修复需求错误通常需要付出大量额外努力。研究表明，相较于在需求开发 1阶段由客户找出并修正错误，后续的修复工作可能需要花费68至110倍的时间。另一项研究则指出，在需求阶段发现并修复一个错误平均只需30分钟，而在系统测试阶段发现问题，则可能耗费5至17小时进行修复。因此，任何及早检测需求规格说明中错误的措施都有助于大幅节省时间和成本。
许多项目（包括遵循瀑布模型的项目）往往将测试推迟到开发后期。与需求相关的问题常常潜藏在产品中，直至通过昂贵且耗时的系统测试或由客户揭示。若能在开发早期就开始规划测试计划和设计测试用例，就能及时发现并纠正错误，防止其进一步引发问题，并减少测试和维护费用。
测试活动应始终与开发活动同步推进。这一模式表明验收测试基于用户需求，系统测试基于功能需求，而集成测试则基于系统的架构。每个开发阶段都应安排相应的测试活动并为每种测试制定测试用例。尽管无法在需求开发阶段执行实际测试（因为此时还没有可运行的软件），但可以在编码开始前，根据需求构建概念性测试用例，以发现软件需求规格中的错误、模糊不清之处和遗漏点，并进行模型分析。
需求验证是需求开发过程的第四部分。一些作者在需求工程阶段使用“确认”一词，但在本讨论中，我们采纳IEEE术语，将“验证”定义为判断开发出的产品是否满足最初设定的需求。相比之下，“确认”更多地关注过渡产品或最终产品是否满足最顶层的特定需求。对于软件需求而言，两者之间的区别微妙且存有争议。
需求验证活动旨在确保以下几个方面：
需求验证旨在确认需求符合良好的表述特征（完整性、正确性、灵活性、必要性、优先级 2明确、无二义性和可验证性），同时也需符合需求规格文档的良好特性。需要注意的是，只有已明确记录在文档中的需求才能被验证；那些仅存在于用户或开发者思维中、尚未明确表达出来的隐含需求，则无法进行验证。
在收集需求并编写成需求文档 3后，需求验证并非孤立的单一阶段。一部分验证活动，如对渐进式软件需求规格说明的反复审查，会贯穿整个需求获取、分析和编写的全过程。而其他一些验证步骤，比如正式审查软件需求规格说明，则是在最终确定规格说明基线前进行的最后一道有效质量把关。
当项目计划或实际工作中出现结构破坏时，应适时结合需求验证活动，并为可能出现的返工预留时间，这通常会在质量控制活动之后进行。尽管有时项目参与者不愿花费时间评审 4和测试需求规格说明，认为这会延后交付日期，但这种观念忽视了验证需求的投资能带来的收益。实际上，通过早期投入以预防错误，每花费1美元就可能节省3至10美元的修复成本。高质量的需求将带来更好的产品质量与客户满意度，从而降低产品生命周期中的维护、增强及客户支持费用。在需求质量上的投资实则可以节省更多的资金。
本文将重点探讨两种关键的需求验证技术：正式和非正式的需求评审 5，以及从使用实例和功能需求中构建的概念性测试用例。
通常情况下，通过技术评审来发现产品问题的往往是非软件开发人员。需求文档评审是一种精细的技术手段，它能够识别出含糊不清、不确定的需求，以及由于定义不准确而无法作为设计依据的需求，甚至能揭示那些被误认为是需求的设计规格说明。此外，需求评审也为风险承担者提供了在特定问题上达成共识的机会。
以一次软件需求规格说明评审会议为例，四位用户代表参与其中，一位用户提出的问题可能导致需求的重大修改。会后，需求分析员和项目经理感到懊恼，因为在前两个月的需求定义会议中，该用户虽有出席却未提及此问题。经过调查发现，这位用户曾多次提出该问题但都被忽视。当评审过程中多数用户一致认为这是个严重问题时，分析员和项目经理意识到他们不能再忽略这个问题了。
不同类型的评审有不同的名称。非正式评审方法可能包括将工作产品分发给其他开发人员进行快速浏览和大致检查，同时由执行者描述产品并征求各方意见。这种评审方式有助于他人了解产品并获取非结构化的反馈，但其过程不够系统化、深入或一致性差，并且无需记录存档。
相比之下，正式评审遵循一系列预先定义好的步骤，且内容需要记录在案，包括确定审查材料、评审人员、评审小组对产品完整性的判断及是否需要进一步工作的决定，以及错误和问题总结等内容。正式评审小组成员对评审质量负责，开发者则对其所开发产品的最终质量负责。
正式技术评审中最佳的形式被称为审查。对需求文档进行审查是最高级别的软件质量控制技术之一。一些公司已认识到，花费一个小时审查需求文档或其他软件产品，可以节省十个小时的工作时间。尽管详细审查大型需求文档可能既枯燥又耗时，但我了解到的所有采用需求审查的人都认为投入的时间非常值得。若觉得时间有限，可以通过简单的风险分析模型来区分哪些需求文档部分需进行详细审查，哪些相对不重要的部分可通过非正式评审满足质量要求。
每次在进行需求获取研讨会 6后，由代表不同用户类别的小组对渐增型软件需求规格说明进行非正式评审，这一做法能迅速揭示出许多错误。从长远来看，为项目开发团队节省了大量的工作时间。
Michael Fagan是软件质量领域的先驱，在20世纪70年代早期，他在IBM公司内开发并推广了一套结构化的审查（Inspection）方法。这一方法后来被广泛认为是软件工程中预防缺陷、提高产品质量的最有效实践之一。Fagan的审查过程包括多个阶段，并且要求由受过专门训练的专业人员组成团队，对软件开发各个阶段产生的工作产品进行细致而系统的检查，以发现和修复潜在错误。
具体来说，采用Fagan审查技术的团队能够严谨地检查诸如需求规格说明书、设计文档、源代码、测试计划乃至项目计划等所有关键软件工件的质量。通过这种方法，可以在问题演变成昂贵的后期修复之前及时发现并解决它们，从而显著降低软件开发的成本与风险。
审查被定义为一个多步骤的过程，由受过专门训练的小组成员执行，他们专注于发现和修正工作产品中的错误和缺陷。这个过程确保文档和其它产出物在最终确定之前必须经过严格的检查关卡。尽管对于Fagan方法是否始终是最有效或唯一的审查形式存在学术讨论，但无可争议的是，正式审查是一种强有力的保证软件产品质量的技术手段。
在进行软件需求规格说明审查的过程中，参与者应涵盖多个关键视角：
为了保证审查效率和质量，建议审查小组的人数控制在7人左右或更少。人数过多可能会导致讨论分散，增加解决争议的时间成本，并且降低问题识别的速度，进而增加每个错误发现和修正的成本。
审查过程中，小组成员会承担不同的角色，这些角色在不同审查流程中可能有所不同，但核心职责相似：
审查过程是一个多阶段的活动，每个阶段的目的可以简洁地概述如下：
规划作者和调解者共同策划审查流程，确定参与审查的人员、审查员在会议前应获得哪些材料，以及需要召开多少次审查会议。审查速度对发现错误的数量有显著影响，审查软件需求规格说明时，较慢的速度通常能发现更多的错误。然而，由于时间有限，审查速度必须根据项目风险进行合理选择。一般而言，每小时审查4至6页的需求文档是合理的基准，但实际审查速度应根据以下因素进行调整：
通过综合考虑以上因素，审查团队能够更有效地安排审查速度，确保既能高效发现潜在问题，又能平衡项目时间和资源限制。
审查过程分为多个阶段：
在进行软件需求文档审查之前，需要确保文档满足特定的前置条件。进入审查的标准为作者和审查小组提供了明确的指导方向，避免将时间浪费在本应在审查前解决的问题上。调解者可以参照以下标准，在决定启动审查前对文档进行初步评估：
同样地，在宣布审查结束前，应设定一套退出审查的标准以确认文档质量达标。以下是关于需求文档退出审查的一些可能标准：
为了帮助审查员更有效地识别产品中反复出现的习惯性错误，针对公司创建的每一种需求文档类型制定特定的问题检查清单是十分有益的。这些清单可以提醒审查员注意以往常犯的需求问题。
然而，由于清单内容可能较为繁杂，没有人能够记住所有项目。因此，建议对每份清单进行定制化精简，确保其符合公司的具体需求，并根据过往经验调整清单内容以反映在需求中最常见的错误类别。为了提高审查效率，可以让不同的审查员分别使用完整清单的不同部分来查找特定类型的错误。例如，一位审查员专门核查文档内部的所有交叉引用是否正确；另一位审查员则专注于判断需求是否具备作为设计基础的可能性；而第三位审查员则集中评估需求的可验证性。
研究表明，为审查员分配具体的查错责任，并提供结构化的思维框架或场景指导他们去发现特定类型的错误，这种方法比起单纯分发一份通用的错误检查清单更能有效提高审查效果。
软件需求规格说明的审查清单:
使用实例文档审查清单:
通过在共享网络文件夹中对电子文档进行评审，传统的面对面评审会议模式得以改变。在这种方法中，审查员利用字处理软件的功能，在所审阅的文档中直接插入评论。每个审查员的评论都会被打上初始标记，以便所有审查员都能看到其他人的意见和建议。
基于Web的聊天工具可以实现远程实时讨论，但其提供的沟通渠道相对有限。若选择不采用面对面的审查会形式，应认识到审查效率可能会下降约25%。尽管如此，线上文档评审能够突破地域限制，让团队成员更灵活地参与并反馈，同时借助在线协作工具，即使无法达到与现场会议同等效果，也能在一定程度上确保审查活动的有效开展。
在软件开发过程中，特别是在需求分析阶段，编写基于功能（黑盒测试）的测试用例是确保系统行为清晰、无遗漏和准确的重要手段。通过从功能需求或使用实例出发设计测试用例，项目参与者能够更具体地理解系统在特定条件下的预期行为，并提前识别潜在的问题。
例如，考虑一个“库存管理系统”：
业务需求 [^businessreq] “库存管理系统”需要优化库存管理流程，减少过度采购和缺货现象，通过实时跟踪和精准预测库存水平以降低存储成本和提升客户满意度。
使用实例 其中一个使用实例是“请求补货”，它涵盖了允许仓库管理员或销售人员在库存量低于预设阈值时发起补货请求的路径。具体描述如下：
请求者通过输入商品ID、预期补货数量以及查看当前库存信息后，向系统提交补货请求。系统则根据现有库存、供应商 [^gongyingshangpinggu]供货能力以及历史销售数据，决定是否从内部仓库调配货物，或者生成并向供应商发送补货订单。
功能需求 当用户请求补货且内部库存足够时，系统功能应包括显示可调配的库存物品清单，并允许用户选择特定批次或数量进行调拨。如果内部库存不足，则系统应能自动生成包含所需商品信息及数量的外部采购订单草稿。
对话图 展示了“请求补货”使用实例的部分对话图，其中矩形框代表用户与系统的交互步骤，箭头表示可能的操作流程，如：查询库存 -> 提交补货请求 -> 查看可调配库存 -> 确认并分配库存或创建外部订单。
测试用例 针对这个使用实例，可以设计多个测试用例，比如：
正常情况下，当库存充足时，验证系统能否正确展示可调配库存列表，并成功完成库存分配。
异常情况下，当库存不足时，测试系统是否能够准确生成符合要求的采购订单，以及后续处理流程是否顺畅。
可选路径上，检验用户更改补货数量时，系统是否能动态更新库存状态和相应操作建议。开发团队会在编码之前结合需求规格说明、分析模型和这些测试用例进行审查，确保所有需求都被正确理解和实现，从而避免后期修改带来的额外成本和时间消耗。
为了验证这些需求是否得到正确实现，测试人员设计了一系列测试用例，覆盖正常流程、可选分支和异常情况。执行这些测试用例有助于揭示需求说明中的不一致、错误或疏漏之处，并促使团队及时对需求文档及分析模型进行修正和完善。
总结来说，通过在需求稳定时尽早开始编写测试用例，项目组能够在开发早期阶段发现并解决需求问题，从而减少后期变更的成本和风险。同时结合非正式的需求评审、软件需求规格说明书审查和其他验证技术，可以显著提高软件质量，控制时间和经济成本。
在执行这些步骤时，以下是详细说明：
审查功能需求 假设我们从项目软件需求规格说明中选择了“用户权限管理”这一页功能需求。该页面描述了系统如何管理和控制不同角色用户的访问权限、权限层级划分以及权限变更流程。
小组成员需要逐一审查每个需求点，例如：
全面审查与培训 如果初步评审发现问题较多，将组织更为详尽的审查会议，并邀请用户和开发人员代表共同参与整个软件需求规格说明的深度审查。在这过程中，进行培训以提升审查效率，比如教授如何识别模糊语言、确认需求的一致性和完整性、检查逻辑连贯性等。
定义概念上的测试用例 对于“用户权限管理”的一个未编码部分——例如，“当管理员更改用户角色时，应自动更新该用户的所有相关权限”，可以创建如下测试用例：
测试用例 1：
在这个阶段，确保所有参与者对上述测试用例所体现的系统行为达成一致意见，并对照需求规格说明核对，确保每个测试用例都有对应的、充分且必要的功能需求支撑；同时排除冗余需求，即那些不影响任何预期功能的行为描述。
本文同步发表在 软件需求探索的https://srs.pub/theory/xu-qiu-zhi-liang-yan-zheng.html