基于软件风险管理的需求变更原因识别框架和案例研究

严玉清+孙为军+张振华

摘 要：识别软件需求变更原因并建立原因分类框架符合软件风险管理的要求。本文从软件风险管理角度出发，分析软件风险因素与需求变更原因的共通性；根据原因存在的客观性与否，把需求变更原因分为内因和外因，并对内因和外因所包含的各因素进行分析，建立软件生命周期中需求变更原因因素的分类结构框架。在问卷调查的基础上，计算内外因各因素诱发需求变更的贡献度，结果表明了原因分类框架的合理性和实用性。最后给出了进一步的研究方向。

关键词：需求变更；软件风险；内因；外因；贡献度

中图分类号：TP311.5 文献标识码：A

1 引言（Introduction）

软件开发项目不论其类型或规模大小，需求变更的有效管理是必要的。实施需求变更如同给病人动手术，要花费成本，延误开发进度，有可能使需求规格说明出现错误，影响软件开发质量，甚至导致开发失败。需求通常是很不稳定的，用户希望把一个需要点击两次的功能，改成点击一次，就会导致需求变更，并影响编码、测试及软件维护[1]。需求变更风险管理重在预防，有效预防需要有效的预测机制，需要有效识别需求变更原因，需要建立合理的原因分类依据和分类结构。

2 研究现状概述（Previous studies）

20世纪80年代前，主张冻结需求的瀑布模型盛行，但随着软件应用的日益普及，软件规模和复杂度不断增大，冻结需求的做法已经行不通，需求频繁变更给软件开发及其维护带来了巨大的挑战。为迎合需求变更，减少变更带来的影响和危害，出现了多种开发技术，例如：聯合应用设计、原型法、快速应用开发、敏捷方法等。同时，需求变更的原因成为业界和学术界一直关注的问题，学术界展开了广泛的探讨和研究。20世纪90年代，Harker等[2]详细分析了组织和用户需求有可能发生变更的五种来源：动态变更的环境、用户参与需求获取、用户使用系统并参与开发、情景行动和任务变更、有计划的组织开发约束，并探讨预防变更的相应对策。Kotonya和Sommerville[3]探讨了软件开发过程中需求变更的各种可能原因，例如：需求错误、冲突、不一致；技术、进度或成本问题；用户组织需求改变等。McGee和Greer[4，5]运用文献分析和实证分析手段，建立需求变更来源的分层视图并验证这种分类在实际开发过程中的效果。事实上，需求变更是对需求问题的修正。在引起需求问题的众多因素中，人是非常重要的因素。开发人员和客户的认知能力、情绪及人际关系都与需求变更问题相关。Anitha等[6]重点研究了作为非技术因素的人在敏捷开发过程中有可能引起的需求变更问题以及相应的对策。Janes等[7]的研究涉及探讨开发人员的感知和理解力、交际能力、情绪和行为特征在需求变更问题上所起的影响作用。

关于需求变更原因的识别和分类中，当前存在三个主要问题：（1）没有建立需求变更原因与软件风险因素间的联系，没有发掘这两类因素之间的共通性；（2）需求变更原因的分类缺乏原则指导，分类结构层次不清晰、不完整。

针对这些问题，本文首先建立诱发需求变更的因素与软件风险因素之间的共通性，然后从风险管理角度，提出需求变更原因分类依据，并对变更内因和外因进行分析，建立软件生命周期需求变更原因分类结构，并通过问卷调查，获得了开发人员的认可。

3 软件风险与需求变更风险的共通性（The commonality

between software risk and requirements change）

3.1 软件风险因素是需求变更的诱因

常见的软件风险因素有[8]：（1）合同风险；（2）需求变更风险；（3）沟通不良风险；（4）缺乏领导支持风险；（5）进度风险；（6）质量风险；（7）系统性能风险；（8）工具风险；（9）技术风险；（10）团队成员能力和素质风险；（11）团队成员协作风险；（12）人员流动风险；（13）工作环境风险；（14）系统运行环境风险。这些风险因素会直接或间接地诱发各种需求问题（图1），导致需求变更[7，9]。

requirements change

3.2 需求变更原因的分类依据

需求问题的存在使得需求不得不发生变更[7，9，10]。需求问题可以出现在软件生命周期中的任何阶段，与各种要素相关：项目的复杂度和规模、开发人员的素质、客户的参与程度和理解力、政策和市场竞争等等。图1中，有些因素与人有关，例如：沟通不良、团队成员协作、团队成员的能力和素质、人员流动；有些因素与过程有关，例如：合同问题、进度问题；有些与组织有关，例如：缺乏领导支持、工作环境问题。从有效软件风险管理角度出发，一定要从软件生命周期去识别需求变更的原因，而且要考虑全面性并兼顾客观性，不放过任何细小的可能导致需求变更的因素或小概率事件，因为这些微小的因素有可能使软件开发过程及其产品出现灾难性的后果[7]。因此，我们提出了四个原则[11]：全局性（Holistic）、相关性（Correlative）、强内聚性（Strong Cohesive）和弱耦合性（Weak Coupling）。

Microsoft的量化研究表明，在风险管理中投入5%的项目工作可以获取50%—75%的如期完成的机会[12]，可见风险管理在软件开发中的重要作用。软件风险管理通常由六个步骤组成：风险识别、估计、分析、计划、控制和监督。风险识别就是识别各种风险因素。一方面，软件风险因素是诱发需求变更的因素。另一方面，需求变更是关键的软件风险因素，诱发需求变更的各种因素就是潜在的软件风险因素。因此，识别需求变更原因因素就是识别软件风险因素。

4.1 需求变更的内因

内因是指与项目本性相关，并有可能会诱发需求变更的因素。

Janes等[7]认为诱发需求问题的内部因素有两种：（1）项目的复杂度和开发持续时间；（2）组织结构。事实上，项目的复杂度是客观存在的，是项目的本性之一，是影响开发人员认知的重要因素。开发持续时间与多方面因素有关，既有客观的，例如项目的复杂度及规模、开发范围，也有非客观的，例如开发人员的素质、经验、开发成本、进度计划、客户的配合等因素。这里我们所认为的内因是客观存在的因素，因此开发持续时间不属于我们所讲的内因。组织结构包括开发组织和客户组织。客户组织通常指的是广大用户的代表。例如，淘宝购物平台，社会的每一成员都是其潜在的用户，但只有淘宝公司的运营部门成员能够代表广大的用户去选择开发组织，具有一定的主观性。因此组织结构不属于内因。我们所定义的需求变更的内因是：规模因素和复杂度因素。

这两个因素之间的联系是：项目规模大或复杂度高，将影响开发人员的认知（影响概念的完整性与一致性），影响需求的完整获取，会诱发需求变更。而且规模大的项目其复杂度通常都高，例如，飞机导航系统，各种子系统之间的一致性、并发性、容错性是复杂的。它们的区别是复杂度高的系统不一定规模大，例如植入人体的芯片系统，它涉及医学、人体解剖学，其复杂性是不言而喻的。

4.2 需求变更的外因

外因是除内因外可能诱发需求问题和需求变更的因素。图1的所有软件风险因素都是需求变更的外因。外因分为六类[12，13]：干系人因素、组织因素、技术因素、过程因素、环境因素和软件效能因素。

（1）干系人因素。干系人是指参与到软件开发过程中的开发人员、项目经理、营销人员、客户等，分为两类：a.开发人员：指参与项目开发、管理、销售的人员以及软件的维护人员；b.客户：指项目委托方人员及终端用户。开发人员会存在这些问题：知识结构不完整，缺乏沟通能力，经验不足，技术不熟练，工具掌握不好，学习能力不强，缺乏钻研精神，不熟悉项目背景，缺乏责任心，情绪不良。客户存在的问题：对产品的认识和了解不足，参与积极性不高，不积极配合开发人员，不遵守合同要求。

（2）组织因素。组织分为两类：开发组织与客户组织（也称用户组织，亦包括作为客户组织代表的提供开发资源的第三方组织）。开发组织存在的问题是：缺乏良好的企业文化和凝聚力，团队成员之间沟通不足，对开发人员或客户的培训不足，领导的市场开拓能力不强、官僚主义，开发人员流动频繁，办公环境不佳。客户组织存在的问题：组织结构、运作方式、商业策略发生改变，业务范围扩展。

（3）技术因素。技术包括工具在内分为：a.开发技术。开发技术和工具的熟练使用能够提高开发效率，减少开发过程中的错误包括减少需求问题及需求变更。常用的开发技术或手段有[8]：联合应用设计（JAD）、原型法、快速应用开发（RAD）、需求检查等。如果缺乏使用或不熟练使用恰当的技术，无疑会增加需求变更风险；b.管理技术。在开发过程中，除了要加强项目管理意识，在软件生命周期中实施规范的管理细则，还要懂得借助于一些商业变更管理系统工具[14]来协助需求的开发、降低需求变更的影响；c.集成技术。不论是同一个软件系统的开发还是大数据的应用，都存在着许多子系统，这些子系统必须集成在一起才能够使软件系统完整。这些子系统之间的集成依赖于接口需求的一致性，如果不一致，则会导致需求的变更。软件系统赖以运行的硬件环境、网络环境、支撑软件（如操作系统）的配置要与性能需求保持一致性，否则会诱发需求的变更。

（4）过程因素。过程分为：a.计划过程；b.开发过程；c.管理过程。计划过程容易出现的问题有合同制订不科学，项目范围和目标不明确，对人力、成本、进度等资源估算不足；开发过程常常出现的问题是进度延误、成本超支、不遵守合同、开发范围扩大；管理过程常常存在的问题为项目缺乏合理统筹和管理，需求缺乏规范和有效的管理，不能够预见问题的发生，不遵守科学的管理流程和规则。

（5）社会环境因素。社会环境因素是指软件在其生命周期中对其生存有影响的并且难于预测和控制的一些社会因素。这些因素具有一定的随机性，是开发人员和客户无法控制的[14]。它包括：a.市场：出现新需求导致现有产品过时；b.竞争压力：竞争者发布新产品打压、影响正在开发或已经交付的产品。这种竞争压力常常出现在商业软件中[10]，例如现在的手机软件，同一种应用的软件在手机商店上五花八門，相互之间形成巨大的竞争；c.政法：政策、法律、法规发生变更。例如税收法的变更会影响税务系统，商业过程的研究会使商业规则发生变更[10]。

（6）软件效能因素。软件交付使用之后，有可能软件的使用成本高、易用性不好、没有真正满足用户需求[15]。软件效能因素包括：a.使用成本的可接受性；b.功能完整性；c.软件性能。例如：易用性、时间响应性、兼容性、适用性、容错性、安全性等。用户满意度就是软件效能因素的综合评价结果（通常是一个主观量）。

4.3 需求变更原因分类框架图

为了能够认清需求变更原因，我们构造了一个软件生命周期中需求变更原因分类框架图（图2）。内因有两层，外因有三层。在叶子层，仍然可以找出底层的原因因素。例如合同的计划问题属于计划过程问题，合同的遵循问题属于开发人员问题或客户问题。由此可见，底层的具体的原因可能属于几种类别，一定要分析清楚具体的原因才能找出其真正的出处，以便更有针对性地实施控制和管理需求变更。

图2有助于完整识别各类需求变更的原因，也有助于找到更细小的原因及其所属来源路径，使得需求变更的实施更有针对性。在实际的开发过程中，当找出了各种可能原因，还要在这些原因中继续判断主要原因和次要原因，但绝不能够忽略看似微不足道的诱因[2]。

5 变更原因贡献度计算和结果分析（The calculation

and result analysis of the contribution rates of

cause factors）

专家访谈与问卷调查是软件工程实证研究的主要手段[16]。为了对需求变更原因获得更直观、深入的理解，我们在广州一家著名的专注于电子政务系统开发的软件公司的开发人员中进行了一次问卷调查。

5.1 问卷调查的主要内容和方式

问卷主要了解四大部分内容：a.个人开发经历及企业基本情况；b.开发过程中需求获取与分析情况；c.开发过程中需求及变更管理情况；d.常见的软件风险因素、需求问题及变更原因。与本研究相关的问题是：在软件风险管理框架下，什么因素容易导致需求变更，其贡献分值是多少（在0—5中选填一个数字，数字越大，贡献分值越高）？

5.2 原因贡献度

原因贡献度是指某原因会诱发需求变更的可能性大小。贡献度分值越高，表明该原因越关键，在软件开发和项目管理时，越要重视这一因素及其与之关系密切的其他因素。

对回收的112份数据进行统计，采用算术平均法计算每个原因的贡献分值，分值再除以5得贡献度，如表1所示。

从表1可见，内因中的项目特征“复杂度”因素，贡献度为70%，表明复杂度高，对开发人员的认知是一个挑战。越复杂的项目，开发人员越要深入了解项目的背景并要与客户保持良好的沟通关系。外因下面的“人”因素下的“客户”子因素的贡献度最高，达到82%。

这表明客户的积极参与以及开发人员与客户进行有效沟通对避免需求变更有关键作用，这与我们已有的常识相符。“开发人员”的贡献度为68%，表明开发人员对成功开发的关键作用，这是不言而喻的。“开发组织”与“客户组织”分别为68%和66%，说明组织对开发过程的统一、协调配合及其管理的重要性。“开发过程”与“管理过程”分别为70%和68%，同样表明开发过程的顺畅性和管理过程的合理性的重要作用。另外，表1可反映这样一个事实，需求变更的主要因素是与人相关的因素。

5.3 加权原因贡献度

考虑到参与问卷调查的开发人员中有的经验丰富（参与开发项目超过30个），有的是新手（只参与了五项）。为使回收的数据更具有客观性，在计算原因贡献分值时，把开发经验折成一定的权值。我们设计了如表2所示的经验权值赋权方法，计算出这批问卷表对应的平均权值为0.93。利用表1所使用的数据，并通过加权，得表3，最终结果与表1相吻合。

6 结论（Conclusion）

本文从软件风险管理角度出发，建立了软件生命周期需求变更的内外因结构框图。这一分类方法具有客观性、全面性和推广性，有助于识别实际软件开发过程中各种软件风险因素和需求变更因素。我们所进行的实证研究分析结果表明了这一分类的合理性和因素之间的可区分性，结论是可靠的。

下一步，我们需要针对特定类型的软件开发项目（例如基于大数据应用的软件或各种手机APP软件或政务软件）研究这一分类模型的可裁剪性及其扩展性，通过收集实证数据，进一步分析因素之间的相关性，找出与特定项目开发相关的关键风险因素和关键需求变更诱因，用以构建理论上和实践上都有指导作用的软件风险和需求变更预测方法体系。

参考文献（References）

[1] M.R.Strens and R.C.Sugden.Change Analysis：A Step towards Meeting the Challenge of Changing Requirements[C].IEEE Symposium and Workshop on Engineering of Computer-Based Systems，Proceedings，1996：278-283.

[2] S.D.P.Harker and K.D.Eason，J E Dobson.The Change and Evolution of Requirements as a Challenge to the Practice of Software Engineering[C].Proceedings of the IEEE International Symposium on Requirements Engineering（RE93）USA，IEEE Computer Society Press，1993：266-272.

[3] Gerald Kotonya and Ian Sommerville.Requirements Engineering-Processes and Techniques[M].John Wiley & Sons，1997.

[4] S. McGee and D.Greer.A Software Requirements Change Source Taxonomy[C].ICSEA'09，Fourth International Conference on Software Engineering Advances，2009：51-58.

[5] S.McGee and D.Greer.Software Requirements Change Taxonomy：Evaluation by Case Study[C].2011 IEEE 19th International Requirements Engineering Conference，2011：25-34.

[6] Anitha P.C.，Deepti Savio，V. S. Mani.Managing requirements volatility while "Scrumming" within the V-Model.2013 IEEE Third International Workshop on Empirical Requirements Engineering （EmpiRE），2013：17-23.

[7] Janes A，et al.Managing Changes in Requirements：an Empirical Investigation[J].Journal of Software： Evolution and Process，2013，25（12）：1273-1283.

[8] 韓万江，姜立新.软件项目管理案例教程（第2版）[M].北京：机械工业出版社，2009.

[9] Karl E.Wiegers.More About Software Requirements：Thorny Issues and Practical Advice[M].Microsoft Press，2005.

[10] Karl E.Wiegers.刘伟琴，刘洪涛，译.软件需求（第2版）[M].北京：清华大学出版社，2004.

[11] Yu-Qing YAN，Zhen-Hua ZHANG.A Method to Connect the Sources of Software Risk and Requirements Change[C].2016 International Conference on Management Economics and Social Development，2016：1179-1185.

[12] 胡勇，谢康，肖静华.软件项目风险管理的协同过程模型[J].现代管理科学，2007（03）：8-10.

[13] 严玉清.需求演化及依赖关系研究[D].广州：中山大学，2011.

[14] Bano， M.，et al.Causes of Requirement Change-a Systematic Literature Review[C].The Institute of Engineering and Technology，2012：22-31.

[15] Tom DeMarco & Timothy Lister.Peopleware[M].2nd Edition.Beijing：Tsinghua University Press，2003.

[16] Annabella Loconsole.Empirical Studies on Requirement Management Measures[C].ICSE'04 Proceedings of the 26th International Conference on Software Engineering，2004：42-44.

作者简介：

严玉清（1963-），女，博士，副教授.研究领域：软件工程，软件需求管理，软件度量，运筹学.

孙为军（1975-），男，博士，讲师.研究领域：软件工程，机器学习.

张振华（1972-），男，博士，副教授.研究领域：服务外包软件项目风险管理，模糊推理.