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

摘要 近年来随着CMMI、敏捷软件开发的推进，出现了多种多样的需求评审类型，这些类型超出了标准评审类型的范围。根据这些情况进行分析，得到了一个新的软件需求评审框架，这个新框架由5个维度组成：
1，组织形式；2，时机；3，侧重；4，评审者；5，对象
分析了分别在传统开发和敏捷开发下的典型需求评审情境，显示新框架能够适用于所有系统性的和非系统性的评审类型上。从分析中得到了15个有价值的启示。新需求评审类型的设计和对需求评审类型的选择可以从这个新五维需求评审框架中受益。根据启示，得到了一个多级小瀑布生命周期模型，这个新模型可以大幅度的优化传统瀑布生命周期模型，具备灵活的自调整自适应能力。
关键词: 需求变更; 需求评审; 需求条目化; 多级小瀑布; 需求工程

在软件开发中，需求变更被视为导致软件开发失败的主要原因。早在1988年BILL CURTIS等人的研究表明：需求的冲突和变化对于生产效率和质量存在巨大影响，识别到学习、技术交流、需求协商和客户交流是非常关键的过程[1]。这些过程在当时的软件过程模型中描述得非常糟糕，而当时的软件过程模型把重点放在了如何通过一系列的产物（比如需求功能规格说明，代码，等等）来得到软件产品。当时的软件过程模型对实际的软件开发没有提供足够的用于指导软件开发技术研究的洞察力，这些模型只是描述了一系列开发任务，而对以下事情没有帮助：项目团队成员必须要学习哪些新信息；如何协商不一致的需求；设计团队如何解决架构的冲突；这些因素及其它类似因素是如何影响项目本身的不确定性和风险。虽然时光过去了整整27年多，但是这一段文字在今天读来都仍然让人感觉汗颜。
在1988年以前，瀑布型生命周期模型（下文简称称为瀑布模型）是占主导地位的生命周期模型，从时间上可以合理的推断[1]文中所说的当时软件过程模型就是以瀑布模型为主。而在[1]文中提到了螺旋模型-“Boehm的螺旋模型是一种很有前途的从宏观层面来管理这些问题的尝试”。螺旋模型的特征是快速原型迭代增量进化并结合风险分析[2]。
复杂软件系统中分析和处理可能存在不一致的需求描述,这解决得好坏直接影响到需求规格说明的质量,进而影响到最终软件产品的质量[3]。为了在需求方面克服不一致和变更问题，需求评审成为试图解决此类问题的第一道关口：在需求阶段或需求活动时就马上识别到需求不一致，这样修复成本是最低的。人们对此开展了大量的研究[4][5]。但是直到最近几年的研究，需求变更导致软件开发延期甚至失败仍然是困扰软件行业多年的老大难问题[6][7][8]。
源于瀑布模型的传统软件需求评审发展得很全面规范[9]，其中最突出的代表是IEEE软件评审和审计标准Std.1028[10]，最早版本是1028-1988，历经1028-1997，当前最新版是1028-2008，最新版IEEE Std. 1028-2008对比1997版没有本质性差异[10]。在最新版中，仍然是定义了5类评审审计，分别是管理评审（Management reviews)、技术评审（Technical reviews)、检查（Inspections）、走查（Walk-throughs）、审计（Audits）。这些类别都是系统性的（英文原文是“systematic types of reviews and audits”），不符合此标准的其它评审类型都是非系统性的。显然的，还有许多非系统性的评审类型，IEEE Std 1028-2008说明：“本标准无意阻止或禁止使用的非系统性评审”,“判断一个评审或审计必要性的流程没有定义，并且没有说明评审或审计结果的处置”，“本标准没有建立对于实施具体评审的需要，这些需要定义在其它软件工程标准或本地流程中”，“本标准的使用者应说明何时何地使用本标准与及任何的故意差异”[10]。所以，IEEE Std. 1028并没有完全解决上述问题，留出了大量的空白需要填补。而确实在实际的软件开发中，就算是需求文档得到了正式批准，遭遇需求变更仍然是经常性的[11]。
自1991年起，软件能力成熟度模型(Capability Maturity Model，简称CMM)在全世界范围内广泛传播，2002年能力成熟度模型集成(Capability maturity model integration，简称CMMI）发布，2006年，CMMI全面替代了CMM，至今CMMI得到全世界大范围的使用。在CMM3/CMMI3中，同级评审（也称同行评审或者同级互查）是其要求[12][13]，随着CMM/CMMI的推广，同级评审也被应用到包括需求文档在内的各类工作产物中，对传统的需求评审带来了变化[14]。
传统的基于文档和文档评审的方法在2001年起的敏捷运动中被视为官僚繁琐、繁文缛节[15]，而在敏捷首先着力的需求领域，IEEE Std. 1028简直就是“罪魁祸首”。而最近十多年来，敏捷软件开发带来了新的变化，提出拥抱变化，不再假设软件需求可以被冻结[16]，传统的需求评审方法在敏捷环境下已经不再奏效[17]，而敏捷软件开发确实带来了很好的效果。敏捷软件开发的特征有迭代增量开发、软件尽快可运行、短距沟通、业务方参与和快速反馈[18]，简直是针对了1988年BILL CURTIS等人所识别的问题[1]。另外也明显可以看出敏捷软件开发与螺旋模型存在渊源关系[19]，让人不得不感叹BILL CURTIS等人早在25年前的先见之明。
但是敏捷软件开发各个流派对需求管理方法各异，实际效果并不完全尽如人意，仍然存在不少争议和模糊的地方。而以瀑布模型为核心的传统开发方式，对于有些组织而言是虽然难以（也许也不必）转换成敏捷短迭代开发，但也从近年来的敏捷发展中获得了启示，出现了新变化，就需求评审领域出现了更加高效的评审方式方法，将在下文进行说明分析。
1995年Kim, Lesley Pek Wee等人发表了《一个软件开发技术评审的框架》[20]，对当时出现的各类技术评审、审查和走查进行了分析，归纳了其框架，但显然的此框架不可能覆盖后续出现的新情况。而自敏捷开发在全球的推进传播，已经有许多研究表明敏捷开发其实同样是符合需求工程的宗旨[21]，但却没有归纳整理传统需求评审和新出现的需求评审（需求验证确认类的实践）之间的框架或者结构。