如果有人说您只能对一个软件项目执行一次质量实践，您会选择什么？我会选择对需求进行同行评审，我认为这是我们今天可用的最高杠杆质量实践。
在同行评审中，工作产品的作者以外的其他人检查产品的质量问题和改进机会。审查需求是一项强大的技术。使用它们来识别模棱两可或不可验证的需求，查找尚未足够详细的需求，找出需求之间的逻辑冲突，并揭示许多其他问题。
同行评审最有效的类型是称为检查的结构化过程。需求检查是可用的最高杠杆软件质量技术之一。几家公司报告说，他们在检查需求文档和其他软件可交付成果上投入的每一小时可避免多达十个小时的人工。谁不想尝试可能提供1000％投资回报率的技术？
同行评审既是技术活动，也是社会互动。让一些同事告诉您您的工作出了什么问题是一种学问而不是本能的行为。软件组织需要一些时间才能将同行评审引入其文化。
本文改编自我的书（与Joy Beatty一起编写），第3版软件需求，指出了进行需求评审时遇到的一些常见挑战，以及有关如何解决每个挑战的建议。有关进行审查和检查的更多信息，请参见《软件中的同行审查：实用指南》一书。
大型需求文件
彻底检查长的需求文档的想法令人生畏。您可能会很想完全跳过审查，而只是着手进行构建实现，相信需求是正确和完整的，这不是明智的选择。即使中等大小的文档，所有审阅者也可能会仔细检查第一部分，并且有一些专家会研究中间部分，但可能没有人会关注最后一部分。
为了避免使审核团队不知所措，请在整个需求开发过程中执行增量审核。在敏捷项目上，花一些时间在每次迭代期间检查需求。即使您使用的是非正式需求方法，将一些头脑聚集在一起以确认理解，寻找隐藏的假设并确保已解决所有异常始终是一个好主意。使用检查对高风险区域进行仔细检查，对风险较小的材料进行非正式检查。您可能会要求某些审阅者从需求集中的不同位置开始，以确保新鲜的眼睛注视着每个部分。
要判断您是否真的需要检查整个需求集，请仔细检查代表性样本。发现的错误的数量和类型将帮助您确定对全面检查进行投资是否可能会有所回报。当然，即使您的样本看起来不错，您也无法确定其余部分可能隐藏的问题，因此那里仍然存在一些风险。
大型审核团队
许多项目参与者和客户都对需求有兴趣，因此您可能有一长串潜在参与者来进行需求审查。但是，大型的审核团队会增加审核成本，难以安排会议，并且很难就问题达成协议。我曾经参加过有十四位审稿人的会议。14个人以离开表示不同意，更不用说就某个特定需求是否正确达成共识。尝试以下方法来与可能庞大的检查团队打交道：
- 确保每个参与者都在那里发现缺陷，而不是受教育或保护政治立场。
- 了解每个检查员代表哪个角度（例如用户，开发人员或测试人员）。代表同一社区的几个人可以集中他们的意见，只派一位代表参加检查会议。
- 建立几个小组，以并行检查需求，并合并其缺陷列表，删除所有重复项。多项研究表明，与单个大型团队相比，多个检查团队发现的需求缺陷更多。这种并行检查的结果主要是累加的，而不是多余的。
- 召集一个由四到七个人组成的小型检查小组，但要事先将所需条件提供给其他有兴趣的利益相关者，这样他们就有机会贡献自己的意见。
地理位置分开的审稿人
如今，地理位置分散的团队经常合作来开发产品。这使评论更具挑战性。电话会议不会像面对面会议那样显示其他审阅者的肢体语言和表情，但是视频会议可以是一种有效的解决方案。Web会议工具使审阅者可以确保他们在讨论期间都在看相同的材料。
放置在共享网络存储库中的电子文档的审阅提供了传统审阅会议的替代方法。在这种异步审阅方法中，审阅者使用文字处理器功能将其评论插入文本中。每个评论都贴有评论者的姓名缩写，并且每个评论者都可以看到以前的评论者必须说的话。基于Web的协作工具也可以提供帮助。一些需求管理工具包括一些组件，这些组件可以促进不涉及实时会议的分布式异步审阅。
如果您选择不举行会议，请认识到这会降低审核的有效性。各种研究表明，在审阅会议中，参与者之间的协同作用和讨论通常会触发一些想法，这些想法会发现在个人准备过程中没有发现任何个人审阅者的缺陷。不过，异步检查肯定比根本不执行检查更好。只是不要让以文字处理器注释形式的辩论代替彼此交谈。
跨距离的协作通常涉及在不同文化中，有时在不同国家工作的人们。不同的文化对评论有不同的态度。例如，在某些文化中，人们很难对别人的作品进行批判性观察。结果，他们可能在审核会议上什么也没说。这是避免伤害他人情绪的好方法，但不是使工作产品更好的好方法。请注意这种文化差异，并尝试创建安全的环境（例如，无会议异步审阅），以使人们提出潜在的缺陷而不会令任何人感到不适。
没有准备的审稿人
正式审查会议的前提条件是参与者提前检查了正在审查的材料，并确定了他们想提出的最初问题。如果没有这种准备，您可能会冒着使人们花费会议时间在现场进行所有思考的风险，并且可能会遗漏许多重要问题。实际上，如果您被邀请参加需求审查并且没有足够的时间自行事先阅读材料，那么甚至不必费心参加会议。浪费每个人的时间。
一个项目有50页的需求规范，需要15个人进行审查（小组太大，无法有效地进行工作）。审阅者有一周的时间自行检查文档，并将问题发送回作者。毫不奇怪，大多数人根本没有看过它。因此，首席业务分析师安排了一次强制性会议，以使检查员共同审阅该文档。
BA将SRS投射在屏幕上，调暗灯光，并开始逐一阅读要求。（房间中间有一个非常明亮的灯，直接射在主角BA上–谈论成为聚光灯！）进入审核会议几个小时后，与会人员打着哈欠，注意力逐渐减弱。毫不奇怪，问题发现的速度下降了。每个人都渴望会议结束。BA最终让与会人员离开，建议他们按自己的时间审阅文档，以加快下一次审阅会议的速度。毫无疑问，会议期间的无聊触发了他们下一次的准备工作。
让评审为您服务
审查需求并不是每个人都乐在其中。同行评审可能是乏味且耗时的，有时甚至是压力大的。但是，如果您认真考虑要最大程度地提高软件质量，您的团队将使用更正式的检查仔细检查最关键或容易出错的部分，以复审他们的所有要求。我的一般规则是：“及早，经常，正式和非正式地进行审核。”
我知道已经通过需求检查的团队同意，他们花费的每一分钟都是值得的。使用本文中的建议可以帮助您的团队最大化他们在需求审查中的投资回报率。