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

摘要近年来随着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]，但却没有归纳整理传统需求评审和新出现的需求评审（需求验证确认类的实践）之间的框架或者结构。

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

需求评审五个维度框架分析及其带来的启示-5-结束语
本文整理归纳了需求评审的各种类型,分析识别了需求评审的5大关键方面,提出了五维需求评审框架,并分析验证了此新需求评审框架的有效性.结合此新需求评审框架,对软件开发主要情境进行了分析,得到了15个高效需 ...
需求评审五个维度框架分析及其带来的启示-2-框架原理
本文试图归纳分析近年来出现的需求评审方式方法,全面涵盖系统性评审和非系统性评审,提出五维需求评审框架. 首先确定对于需求评审的定义,结合传统需求阶段评审和敏捷迭代开发中相关需求实践,得如下定义. 定义 ...
需求评审五个维度框架分析及其带来的启示-3-典型需求评审
典型情境是指软件开发的常见情境,本文选择如下来进行分析: 1. 传统瀑布模型开发下的需求评审 2. 使用IEEE Std. 1028的需求评审 3. 敏捷开发下的需求评审传统瀑布模型下的需求评审对 ...
需求评审五个维度框架分析及其带来的启示-4-需求条目化管理
需求条目化管理是指需求的主体分条目管理,比如对于用例.用户故事.特征点的条目化列表管理,有些工具中条目称为工作项(work item).条目化管理的特征是1,状态流转实现工作流:2,条目属性字段可定制 ...
Flutter框架分析（五）-- 动画
Flutter框架分析分析系列文章: <Flutter框架分析(一)-- 总览和Window> <Flutter框架分析(二)-- 初始化> <Flutter框架分析(三 ...
Linux ALSA音频框架分析五：HDA Driver分析
Linux ALSA音频框架分析五:HDA Driver分析一概述 HDA(High Definition Audio)是intel设计的用来取代AC97的音频标准,硬件架构上由hda dodec ...
在需求评审，测试需要关注的四类问题
参加需求评审时,我们一般通过业务场景.系统交互.功能点.项目,以上四个维度来进行问题的提出. 第一.业务场景中的用户故事方法论通过业务场景中的用户故事方法论,即站在用户的角度去考虑用户会遇到的各种情 ...
需求说明文档之阅读人员分析，如何提高需求说明文档的读者认可度
需求报告的最终目的是给人来阅读的,所以一定要考虑需求报告的读者群,有4类角色可能阅读软件系统的需求文档: 客户与用户业务高层: 用户的中层管理人员与具体人员: 用户IT主管与开发人员,包括设计人员. ...
五个维度打造研发管理体系【原创】
背景技术管理者(技术总监/经理/CTO)期望通过体系化的管理方式建设,能够在百人,千人以上的团队中有效的构建聚焦目标,自我成长,高效能的研发作战团队,快速拿出成果,支撑业务的快速发展. 痛点从小团 ...

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

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

最新文章

热门文章