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