改进的软件需求变更模型

王晓 张春海

摘 要：针对软件需求变更的不确定性，从团队自身因素与客户因素两方面出发，分析软件项目开发过程中发生需求变更的主要原因。通过对多家公司及团队的研究，比较多个需求变更模型，并比较不同模型对项目开发工作量的影响，得出最优需求变更模型。该模型具有文档体现完整、开发与管理同步、后期维护成本低等特点。

关键词：需求变更模型;软件需求;项目管理

DOI：10. 11907/rjdk. 181669

中图分类号：TP3-05文献标识码：A文章编号：1672-7800（2019）001-0051-05

Abstract： In view of the uncertainty of software requirement changes， this paper analyzes the main reasons for the changes of demand in the process of software project development from two aspects of team factors and customer factors. Through the study of a number of companies and teams， a number of demand change models are compared， the effects of different models on the project development work are compared， and the optimal requirement change model is obtained. This model has the characteristics of integrity of the document， synchronization of development and management and low maintenance cost.

0 引言

“項目的开始就代表需求变更的开始。”这句话直接表明在软件开发工程中，需求变更是无法避免的。需求变更在软件设计、编码、测试甚至维护阶段不断出现，既会对开发效率与上线时间产生重大影响，也产生了很多无用工作量，而且在需求变更过程中，软件的品质、成本也随之变化。为了保证项目的顺利完成，需要采取有效方法对项目变更进行管理，以减少需求变更带来的工作量，因此首先必须对需求变更因素与应对措施进行研究。目前已提出很多需求工程方法[1-2]，在软件能力成熟度集成模型（CMMI）中曾提出需求变更管理方法，其后一段时间，许多人在此基础上改进了需求变更度量[3]并不断加以完善，各软件企业也开发出适合自己的需求变更框架。然而根据统计，中小IT企业的项目失败率高达80%，这与企业未做好项目管理有着直接关系，其中项目需求变更是导致中小企业项目管理工作失败的重要原因之一[4]。通过深入企业调研，发现多数企业需求变更的框架文档不够完善，甚至出现企业因文档问题影响交付品质的情况。采纳或拒绝针对项目需求的变更请求是变更控制委员会（CCB）的职责，项目管理工程研究领域普遍认为成立变更控制委员会是控制变更最好的策略之一[5]。Cooper 等[6]专家基于依赖控制和数据依赖的模型图对软件需求变更进行研究与分析，以分析需求变更带来的影响。因为需求变更与软件生命周期结合紧密，为了将软件各个生命周期与需求变更整合起来，从而提高软件开发效率，减少不必要的工作量，并且提高软件交付质量，设计了需求变更框架。然而现有软件需求变更模型仍存在一些缺陷，比如有的软件需求变更可能导致工作量增加，或降低了软件交付品质。如何在需求变更时既不用增加太多开发工作量，又可以保证软件质量，是一个亟待解决的问题。因此，设计一个需求变更管理与开发并行的同步型软件需求变更模型是十分必要的。

1 软件开发及需求变更关系

1.1 软件开发阶段

项目一旦启动，则进入软件开发生命周期。软件项目生命周期分为：可行性分析、需求分析、概要设计、详细设计、编码、测试、维护7个阶段。根据其不同的生命周期模型，又分为瀑布模型、V模型、原型化模型以及迭代模型等开发模型。软件生命周期模型的出现始于W Royce在1970年发表的瀑布模型，使人们开始从更高视角审视软件开发活动[7-8]。然而实际的软件项目开发并不是一帆风顺的，项目需求变更穿插于生命周期的每一个环节。软件开发需要严格按照流程实施，并对需求变更流程路线进行统一规范[9]。

1.2 理论论述

IEEE（电气和电子工程师协会）定义软件需求为：①为了让客户完成某项功能或处理某个难题而必须具有的能力;②为了让系统能够符合某一标准或达到合同要求而必须具备的功能[10]。

1.3 需求变更

需求变更又称为需求变动，是指在与客户签订了项目或软件开发协议后，在完成交付之前，客户提出对项目或软件功能及非功能性的更改要求。需求最显著的特点是“随着项目而改变，随着项目进展而渐进明晰”，可以看出需求管理与项目管理一样，存在于项目整个生命周期中[11]。

1.4 需求变更与软件生命周期关系

需求变更与软件生命周期存在密不可分的联系，如图1所示。当需求分析完成后，需求变更便贯穿于后续每一个环节，大到项目架构设计，小到编码实现，都可能发生变更。由于所处外界环境及客户需求的不确定性，当一个软件需求发生变更时，可能会给软件开发人员带来较大工作量。另一方面由于需求变更的模糊性，也可能导致最后开发的软件质量不符合用户要求。因此，如何评估并减少变更对工作的影响，既是对项目经理管理层面的挑战，也关系到项目能否按时交付。

1.5 需求变更与用户满意度关系

需求变更与用户满意度关系来自于KANO模型，该模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的可对用户需求进行分类与优先排序的有用工具，体现了产品性能与用户满意度之间的非线性关系。其主要是从顾客角度认识产品或服务需要，首先需要满足的是顾客最基本的需求，即第四象限的“当然质量”，因为这些需求是顧客认为必须达到的;其次需要尽力满足客户的“期望质量”，即第一象限，这是质量的竞争性因素;最后为了提升客户忠诚度，需要争取实现第二象限的“迷人质量”。

2 需求变更因素分析

当变更发生时，首先要询问相关开发人员，综合评定变更的影响，其次设计对应方案并对其进行工作量评估，最后根据设计方案进行开发工作。本文提出在项目开发中影响需求变更工作量的两个因素：自身因素与客户因素。

2.1 自身因素

2.1.1 团队专业性

专业素质表现在编码与设计方面。作为一个专业软件开发人员，在软件项目开发过程中，应该了解项目所处行业环境，关注行业动态，从而能够准确获取或描述客户需求，对于客户的大致需求可以从多个角度给出设计方案[12]，并且对后期可能存在的需求变更预留接口。此外，软件设计人员需及时与客户沟通，从客户角度出发，了解对方需求中的专业术语，使团队具备较强执行力。

2.1.2 文档完整性

一套专业、系统的文档，不但有益于逻辑梳理以及与客户的沟通交流，而且在出现需求变更时，能够准确把握需求变更点，从而大大提高工作效率。软件开发人员在需求变更不确定的情况下，通过阅读完整文档，能够更深入地了解客户需求、节省开发时间。因此，当需求发生变更时，应及时更新文档，以有效保障项目品质。

2.1.3 编码规范性

程序代码风格的规范性，对于后期需求变更的开发效率也有着很大影响。规范的编码风格，使代码具有很高的可阅读性，降低了不同开发人员之间的沟通障碍。当文档与代码可以一一对应，即使开发者中途离开项目组，继任者通过对应关系，也可以很快进行定位，节省了浏览业务逻辑的时间，提高了代码的可扩展性、可阅读性与可维护性。规范的编码风格对于排查需求变更点可提供很大便利，从而当需求发生变更时能够尽量降低对现有开发功能的影响，并且有效降低软件开发人员工作量。

2.2 客户因素

2.2.1 客户业务素质

客户业务素质是影响软件需求变更的重要因素[13]。对于客户而言，业务素质主要体现在对专业词汇的表达及期望业务需求的描述方面。其中由于部分专业词汇的使用可能非常频繁，因此对于需求初始的定位与设计而言，保证初始需求的完整性以及与客户沟通的及时性，会使需求变更发生的可能性大大降低。

2.2.2 提出时间

软件需求变更提出时间对需求变更工作也有着很大影响。例如：2016年开发了一套SAP系统，2017年进入测试阶段时发现已测试的A模块业务需求与现实业务不符，想要对该模块进行修改，时隔一年之久进行修改与刚开发一个月时即进行修改，其工作量相差甚远。

2.2.3 修改位置

在软件开发过程中，项目设计为项目架构部分，然后根据设计进行编码。如果客户提出的需求变更位置位于架构部分，将可能对项目整体设计带来重大影响。

3 常见需求变更模型

3.1 执行优先性模型

当客户提出需求变更时，可根据执行优先性模型对变更进行评估，确定设计方案，然后指派人员执行。

此时的评估变更审核是对工作量及可行性的评审，因为一旦需求发生变更，往往需要对原有进度进行重估，并修改设计、重写代码、修改测试用例、调整项目计划等，从而影响整个项目完成时间、质量及成本等多个要素。如果对当前项目影响过大，则会驳回变更或与客户方面协商解决方案。审核变更不仅仅是同意或驳回，更是对项目的整体把握，并进一步确定合同范围。因此，该模型只适用于小型项目，由于缺乏明确的文档管理，无法对客户需求进行追踪记录。如果项目体积过大或需求变更频繁，则需要开发人员重复阅读与修改既定代码，从而增加了工作量，并影响开发进度。如果审核环节控制不好，还会导致项目进度延迟、质量不过关及成本严重超支等诸多问题，甚至可能因变更过多产生分歧导致项目半途而废。因此，需要使用拓展性强、性价比高的需求管理系统对需求管理流程进行固化[14]。

3.2 书面说明性模型

因执行优先性模型对于需求变更管理不够严格，因此出现了书面说明性需求变更模型，如图4所示。该模型详细记录了变更发生后对项目的分析、评估过程，并生成文档加以保存。

当客户提出需求变更时，首先需要提出《需求变更说明书》，然后由产品经理配合书面化《需求分析说明书》，评估需求变更的影响，形成“两表一书”，并由需求变更控制委员会进行审核。若审核通过，则对产品进行修改及测试，验证变更效果。该模型可对变更需求进行书面化约束，以方便对项目的管理，但在需求分析说明书完成后，无法及时与客户再次确认变更内容，可能造成对产品修改不够准确的情况。由于需求变更可能经常发生，即使与客户确认变更内容之后，客户仍有可能再次改变需求。如果每次发生需求变更时，项目人员都需要提交变更申请，再对变更需求进行分析、估算与审批，则会严重影响项目进度。而且每次提出需求变更的紧迫性不同，如果按照客户提出的变更顺序进行项目修改，势必会影响项目总体规划及进度，增加开发人员工作量。

4 新的需求变更模型——同步型需求变更模型

针对上述需求变更模型存在的缺点，经过改进，提出一种新的需求变更模型——同步型需求变更模型，如图5所示。

4.1 区分需求变更影响规模

根据需求变更对软件项目的影响范围，对项目执行进度的修改过程进行优化。对于小范围的变更，如修改一个页面的某个标题或文字问题，开发者仅需要10分钟即可完成的任务，则可直接提交开发人员修改，无需进行可行性判定及评估审核。这样不仅提高了客户满意度，而且提高了修改效率。对于中大范围的修改，则需要由需求变更控制委员会确定需求变更影响范围，并分析变更带来的潜在影响[15]，采用的分析方法包括基于QFD与DSM的软件需求变更影响分析方法[16]、面向对象的软件变更影响分析方法[17]、基于语义的需求变更影响分析方法[18]等。

4.2 需求变更优先级

由于客户提出的需求变更具有不同优先级，此时可参考KANO模型对客户需求进行判定，并在其基础上更新需求内容，提高项目完成品质，尽力提高客户满意度，以实现“迷人质量”。因此，新模型强调按照需求变更的优先级进行修改，并对于可以分批次上线的项目进行拆分，优先对紧急上线的模块进行修改，对于不影响上线部分的需求变更，可以在此之后再与客户沟通，详细分析客户需求，明确修改内容。

4.3 设计符合度

当设计人员完成详细修改方案后，将设计后的版本内容与客户进行沟通，只有当设计方案得到双方肯定后再进行开发，才能防止因修改的设计不符合要求而造成返工，产生多余的工作量。

4.4 软件开发与修改同步

对于设计人员提出的修改方案，由开发人员加以执行，同时由项目经理修改项目进度，随后反馈给开发人员，以防止开发人员因等待项目修改导致开发进度延误，提高开发效率。

4.5 多模块协同并统一测试

现代软件的开发都是团队型作业，对于大的项目，该分工方式可以提高效率，同时降低代码耦合。企业中众多需求变更模型都是以单一模块开发为主，一旦对其它模块造成影响，只能依托集成测试与系统测试才能发现。如果在变更前即能考虑到变更的影响模块，并分模块解决问题，则可提高团队间协作能力，降低开发成本。

5 应用实例

在典宝网项目的信息维护模块开发过程中，多次出现需求变更，其中包含页面修改、逻辑修改、接口对接、传值修改等方面。项目组对于需求变更带来的影响，先后采用3种模型对工作量进行了评估。对比结果如表1所示。

由表1不难看出，对于细微的修改，3个模型的工作量基本一致，书面型模型所需时间略长。因为按照书面型需求变更模型进行需求变更，编写文档会在一定程度上增加工作量。但当修改内容较为复杂时，同步型模型所需的工作量会降低。对于书面型模型而言，由于其逻辑比较明确，可以准确定位问题点，且便于修改，但因编写文档时任务无法同步进行，将延误开发进度。同时可以看出，执行型模型的修改工作量显著高于后两个模型，主要是由于其业务逻辑较为复杂，不易定位，且文档不够完整，因而导致开发质量大幅降低，并且在需求变更次数增加时，其工作量也会不断加大，从而导致开发内容与原需求区别较大，提交的文档也与代码内容存在差异，同时增加了维护成本。需求变更模型工作量对比如图6所示。

6 结语

根据Zowghi等[19]对软件开发组织历史数据的分析，得出需求变更对软件项目的延期与超支有着显著影响。由于在需求管理过程中具有很大风险[20]，因此采用一个好的项目需求管理模型进行进度控制是非常重要的。该需求管理模型既要能够产生足够的文档以保证项目产品品质、降低维护成本，又要避免开发延误，防止产生额外工作量。本文对于多家公司及团队的需求变更模型进行分析，发现同步型需求变更模型可有效解决传统需求变更模型工作量较大、易阻塞的缺点，其良好的文档管理过程既减少了需求变更造成的工作量，并能有效保证软件品质，又减少了后期维护成本，从而使开发过程更加顺畅。

参考文献：

[1] 陈小红，尹斌，金芝. 基于问题框架的需求建模：一种本体制导的方法[J]. 软件学报，2011，22（2）：177-194.

[2] 李引，李娟，李明树. 动态需求跟踪方法及跟踪精度问题研究[J]. 软件学报，2009，20（2）：177-192.

[3] 李萍，许晓兵. 基于CMMI的信息系统需求变更度量问题及其改进方法[J]. 科技与管理，2011，13（6）：72-75.

[4] 卢晓东.  中小IT企业项目变更管理研究[D]. 北京：中国科学院大学，2014.

[5] 缪晨辉. 新产品开发中的需求变更控制管理[J]. 项目管理技术，2008（S1）：315-318.

[6] COOPER D， CHAN M W， HARDING M， et al. Using dependence graphs to assist manual and automated object oriented software inspections[C]. Proceedings of Software Engineering Conference，2006： 42-58.

[7] 邢彬彬，姚郑. CMM/CMMI与软件生命周期模型关系的研究[J]. 计算机应用研究，2007（11）：65-69.

[8] BROOK S F P. 人月神话[M]. 汪颖，等，译. 北京：清华大学出版社，2002：367.

[9] 李俊炜. 软件开发中的需求分析及变更管理研究[J]. 无线互联科技，2017（10）：60-62.

[10] COMMITTEE S E S. IEEE recommended practice for software requirements specifications[C]. IEEE STD， 2002：1-40.

[11] 陈冬冬. IT项目需求管理浅析[J]. 电脑知识与技术，2017，13（32）：117-119.

[12] 王焕青. 基于需求条目的变更管理[J]. 科技资讯，2017，15（13）：100-101.

[13] 李波. 软件需求变更的影响因素和控制管理研究[J]. 通讯世界，2015（18）：221.

[14] 鲁先鹏. A公司软件需求管理研究[D]. 北京：北京交通大学，2016.

[15] 刘华虓，金英，马鹏飞. 一种需求变更影响分析方法[J]. 计算机研究与发展，2013，50（8）：1769-1777.

[16] 王跃鹏，张春海. 基于QFD和DSM的软件需求变更影响分析方法与应用[J]. 微型机与应用，2017，36（9）：74-77.

[17] 刘志宏.  一种面向对象软件变更影响分析模型的研究与设计[D]. 镇江：江苏大学，2007.

[18] 蒋高，郭树行. 基于语义的需求变更影响分析的技术研究[J]. 科技创新导报，2013（25）：248-249.

[19] ZOWGHI D，NURMULIANI N. Proceedings of the 9th Asia pacific software engineering conference[C]. IEEE Computer Society，2002： 3-11.

[20] 沈建明. 項目风险管理[M]. 北京：机械工业出版社，2003.

（责任编辑：黄 健）