如何应对软件开发中的需求变更

如何应对软件开发中的需求变更

【摘要】在软件项目开发的过程中，软件的需求变更是一个回避不了的问题，它的处理的好坏，更是决定软件开发项目是否能够顺利、完美、高效率得到实现的关键。本文针对STS8000测试系统在软件项目开发过程中出现的常见问题，探讨了如何应用项目需求变更管理、项目目标管理、版本更新管理与软件测试管理，从而帮助并促进软件开发人员开发出更加完美、高效、稳定、有质量的软件产品。

【关键词】需求变更管理；软件项目目标管理；版本更新管理；软件测试管理

随着软件系统的规模、复杂度日益上升，软件开发过程中的各种质量管理已经成为保证软件系统开发效率、质量、成本的关键性因素。软件行业在现在的众多行业里是一个极具挑战性和创造性的行业，体现了软件开发者的智慧和汗水，同时软件开发是一项复杂的系统工程，牵涉到许多方面的因素，在实际工作中，经常会出现各种各样的问题。如何总结、分析并解决软件开发过程中各种问题，对于项目开发人员与管理人员来说，是在今后的项目中取得成功的关键。

目前，STS8000系统在软件方面出现的问题主要有下面几方面：

1、客户不断提出新的需求。软件开发人员不断地陷于满足用户需求的过程中。似

乎，我们在需求上无能为力，我们永远在追赶客户的需求，满足他们的现状，

把N多家的客户需求都加进软件中，只要能实现的，我们尽量咬牙实现了。最

后，我们发现，我们的软件无比复杂，谁也不知道这个需求当时为什么是这样

的。因为无比复杂，所以稳定性更成了问题。代码互相交叉，根本无法理清有

多少交叉影响点。

2、改正了旧问题，又冒出更多新问题，问题层出不穷；维护的工程师都快崩溃了，

天天在祈求，千万别接到客户电话。对于修改现有代码适应新客户新项目，这

种情况出现的非常多。客户打电话说了一个需求，能技术达到就答应下来修改，

修改完就给客户覆盖，根本没有需求变更管理、版本更新管理。而这样的代码，

还不是一个特定客户一套特定定制化代码，是要给其他客户也更新的。很可能

这个客户好使，那个客户使用其他功能的时候就出了错。按下葫芦起了瓢，是

很常见的现象。

3、由于长期陷于满足用户需求的过程中，天长日久，软件工程师就会木然、倦怠，

会形成做一天和尚撞一天钟。有问题就打补丁，客户不嚷嚷就懒的修改，代码

不优化、不封装，界面不友好，架构更是没架构。模块难度、工期质量考核无

法量化，更无法与个人收入挂钩。

以上三个问题，其实归纳起来就一个关键点：如何处理好需求这个问题，从而使客户、公司、研发人员多方达到共赢。下面，就这个关键点，谈谈我的一些看法。

一、必须进行需求变更管理

软件，尤其项目型软件，不修改是不太可能的。但是，在修改软件时，不能进行就事论事的修改。否则很容易陷入到某一家客户具体的需求中，而不会考虑其他客户的需求兼容，

从而导致修改的软件有很大局限性。最后形成只能一家维护一套代码，最后客户越多就越累，维护成本也越高，从而由于客户多而拖累死。软件质量也没法保证。要想改变这种现状，就必须把需求整理好。

需求变更的出现主要是因为在项目的需求确定阶段，用户与软件项目组往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需；软件项目组以为自己清楚，但实际上他们是根据目前已知的有限了解来确定软件的具体需求。随着开发工作的不断进展，系统功能的开始展现，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色。特别是在用户已经长期使用过同类产品以后，针对一个新的测试系统，他们提的新要求就更多，需求变更因此不可避免地一次又一次出现。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目不断处于更新、待完善状态中。如果再加上没有一个完善的软件测试与发布系统，软件新的更改的质量就没法得到保证，更会让软件项目组整天处于焦头烂额中，甚至导致整个项目的失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。针对变更控制流程，通常实施需求变更管理需要遵循如下原则：

第一、需求变更要有统一的归口。所有的需求变更都必须汇总到项目经理或专门负责需求变更管理的人员手中。

第二、把需求分类，做个EXCEL表格，量化解决。这个需求管理表格会有下列这些项：客户名称、需求提出人、提出日期、功能模块名、客户现在版本号、需求描述、需求分类（需求、BUG）。需求描述不清晰是反复修改的罪魁祸首。对于BUG，要有

错误报错整个的屏幕截图，千万不要就截那个错误消息框那么一小块。

第三、对需求进行评估。一个项目中需求调研的充分与否是项目日后成败的关键要素之一。

在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。

客户想要什么？要这干什么？为什么这么想？会不会有别的想法？

通过以上四步我们的目标是：搞清客户的要求，找出要求的逻辑，客户想要的结果，同时排除开发的风险，挖掘与控制潜在的要求，把客户的需求合理化，简单化，说白了就是别搞个逻辑又复杂又不实用的东西出来。

第四、在需求变更评估通过后，在修改需求或BUG的时候，要按照模块来集中修改，而不要挑好改的先改了，不好改的就最后改。按照模块来集中修改，你会通盘考虑所有这些需求和BUG，而不是糊窗户式的补窟窿。