需求评审五个维度框架分析及其带来的启示-2-框架原理

本文试图归纳分析近年来出现的需求评审方式方法，全面涵盖系统性评审和非系统性评审，提出五维需求评审框架。

首先确定对于需求评审的定义，结合传统需求阶段评审和敏捷迭代开发中相关需求实践，得如下定义。
定义1(需求评审). 需求评审是指基于需求文档阅读或者观察软件运行并且对当期工作有时效性的人工检查。

根据以上定义，需求评审的范畴不包括机器自动检查，不包括需求审计；包括了需求上线后的校对，包括了系统性需求评审和非系统性需求评审。观察软件运行与测试有部分重叠，但并不是测试，比如说有些观察时，鼠标和键盘在演示者手中，而有些观察是在试用。
本章分析识别需求评审的5大关键方面，分别是：1，组织形式； 2，时机； 3，侧重； 4，评审者；5，评审对象。下文进行一一说明。

需求评审的组织形式分类

表1 需求评审组织形式分类表

组织形式分类	说明
非即时评审	将需求发送给1位或多位评审者，评审者独立的进行评审，返回评审发现，不安排会议。其优点：成本最低，评审者时间安排灵活，缺点：响应慢，交流不充分，容易马虎。
结对评审	双人在可全程实时口头交流的情况下，包括面对面、远程语音或视频，进行需求评审[22]。结对是来自于英文Pair, 仅指双人即时交流，并没有固定结对的暗示。优点：面对面交流反馈快，互相启发，可深入交流，缺点：需要协调两个人的时间，可能激化潜在的人际冲突。
有预审的会议评审	会议形式，参会人数多于2人，评审者在会前预审，作者和评审者在会议中交流探讨。优点：业界已经积累了许多评审流程[10]，会前会中会后都有相当成熟的指导，各方交流较充分，能得到正式结论，缺点：协调多人时间，总工作量比较大。
无预审的会议评审	会议形式，参会人数多于2人，作者和评审者在会议中交流探讨。优点：较之有预审的会议，省去了预审，节约工作量，会议上各方交流较充分，也能得到正式结论，缺点：协调多人时间，总工作量较大，由于没有预审，不排除会上需要更多时间来说明情况，甚至出现存在明显理解差异，导致会议失败。

说明：非即时评审加上无预审的会议评审将组合得到有预审的会议评审。

需求评审的时机分类

需求评审时机分类是区分何时进行需求评审。
表2 需求评审时机分类表

时机	说明
里程碑评审	需求完稿后，关键各方参加评审，一旦通过，就进入下一阶段工作。顺利的话，只需一次需求里程碑评审。
非里程碑	完稿评审 需求完稿后，为确保里程碑评审通过，先进行的评审，可以分部分进行。为方便计，以下简称完稿评审。
分段评审	按时间分段进行，提前发现并解决问题。
定期评审	定期进行评审，其频度要高于分段评审，一般高于等于每月一次，低于等于每周一次，比如每周、每双周、每月。
高频按需评审	按照需要，频繁的开展，比如针对指定功能的桌查，每天或每几天发生，频率高于每周一次。以下简称高频。

需求评审的侧重分类

需求评审侧重分类是区分是从技术还是从管理角度来评审产物。
表3 需求评审侧重分类表

侧重	说明
技术方面	从需求技术角度来评审，发现需求技术方面问题，比如错漏、模糊、前后矛盾等等。
管理方面	关注于需求开发与管理的过程规范、进度、规模、工作量、成本、前期评审情况等等

需求评审的评审者分类

需求评审的评审者分类是区分上级是否参与评审。
需求评审者分类表

评审者	说明
严格同级	也称同行，这样的评审不直接影响作者和评审者绩效考核，可以让作者和评审者更自如的表达，让评审者更客观的评审，作者、评审者之间没有任何上下级关系，即是作者不是任何评审者的上级或下级，评审者之间也没有上下级关系。
无作者上级或称同级	评审者中没有作者的上级，评审者之间可能存在上下级，最新CMMI for DEV V1.3中没有采用严格同级来实施同级评审，只说明了由作者的同级人员来实施同级评审[23]，而在实践中不少的同级评审包括有作者的下级，这不违背“使用同级评审数据来评价人员的绩效”的禁令[23]。这是最常见的同级评审形态，下文的同级评审是指无作者上级的评审。
含作者上级	评审者中包括作者的上级。评审表现可能被上级用于评价人员绩效。下文有称为非同级。

需求评审的对象

需求评审的对象分类是区分不同的评审对象
表5 需求对象分类表

对象	说明
需求文档	各类需求文档，比如需求规格说明书，用例分析，用户故事等等，在CMMI的过程域分类下，属于验证，处理的是工作产品是否适当地体现了规定的需求，确保“正确地做了事”。优点：能够较早的开展，提前发现问题，大大降低后续修复缺陷的成本；缺点：不够直观，尤其难以判断交互易用性。
软件运行	软件运行提供直观的操作场景，包括原型、敏捷迭代可交付物，值得说明的是界面原型也属于软件运行范畴，虽然界面原因可能无法真正运行，但其能演示操作场景。在CMMI过程域分类下，属于确认，证实产品在被提供时（或者在其将被提供时）能满足其预期的用途，确保“做了正确的事”。优点：直观展现实现的需求，可以更好的判断需求，尤其是交互易用性（usability）[24][25]；缺点：得到可运行软件需要等待较长的时间。

关于正式和非正式评审

不少文献使用正式评审和非正式评审对评审分类[26]，这有部分是对于IEEE Std. 1028中systematic review和non-systematic review的翻译，也有对CMMI DEV V1.3中“formal and informal reviews”的翻译[27]。但是部分组织在实际命名本组织的评审方式时，直接采用“非正式评审”和“半正式评审”作为评审名称，这样的名称在实践中带有强烈的马虎、不作数的暗示，导致“非正式评审”“半正式评审”不能发现有价值的问题，往往是为了走评审流程而形式主义开展这些评审。作为严谨、专业的做法，在中文环境下不应当将评审命名为“非正式评审”和“半正式评审”。应当采用专门能描述评审特征的名称来命名，比如本文提到的各类称呼。本文所识别框架没有采用正式、非正式作为分类，本文认为所有的评审都应当是正式的，哪怕比如说是双人随时发起的没有任何记录的桌查，或者团队15分钟需求状态一览会议，这些只是采用了不同的评审方式方法。

需求评审框架组成

以上识别的5个最关键维度组成了需求评审的如下表的五维需求评审框架。
表6 五维需求评审框架

维度	说明	常见情况
组织形式	如何来组织评审	非即时，结对，有预审的会议，无预审的会议
时机	何时举行评审	高频次按需，定期，分段，完稿，里程碑
侧重	评审主要关注的方面	技术方面，管理方面
评审者	评审中可以提出意见的人员	严格同级、同级（评审者不含上级），评审者含上级
对象	评审的目标对象	需求文档，软件运行

可以看到各种各样的需求评审都可以按此框架来进行分析解释，也可以从此框架中寻找发现适合不同情境的有效需求评审方式方法。按以上框架中5个方面的分类，其组合总共有4×5×2×3×2=240种。可能有读者看到这里会认为，有些组合在现实中是不会出现的，比如高频结对管理方面评审，但是套用一句广告语“没有不可能”，下面将分析已经存在各类需求评审。下文也将继续探讨在不同情境下如何灵活应用，如何搭配得到高效组合，识别新的评审方式方法。

常见的需求评审举例

为了便于理解以上各方面分类，请看如下常见的需求评审。
表7 常见需求评审情况

典型情况	情况1	情况2	情况3	情况4	情况5
常见称呼	需求里程碑评审会	需求分别同行评审	需求结对评审	需求分段同级互查	需求管理评审
组织形式	有预审的会议	非即时	结对即时	非即时	有预审的会议
时机	里程碑	完稿	定期	分段	里程碑
侧重	技术为主+管理为次	技术	技术	技术	管理
评审者	含上级	同级	同级	同级	含上级
对象	需求文档	需求文档	需求文档	需求文档	需求文档

上表中情况1的需求里程碑评审会就是传统瀑布模型中的需求评审会。