软件项目需求变更六大原则及应对之道

原创 2008年09月29日 18:12:00
 
变化并不是人们最害怕的,最怕的是跟不上变化的步伐。同样,在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础。   需求变更管理的需求
  需求变更是因为需求发生变化。根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。
  需求变更的出现主要是因为在项目的需求确定阶段,用户往往不能确切地定义自己需要什么。用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。
  于是,他们可能会想到各种新的功能和特色,或对以前提出的要求进行改动。他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。
  这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来管理需求变更,那么很可能造成项目进度拖延、成本不足、人力紧缺,甚至导致整个项目失败。
  当然,即使按照需求变更控制流程进行管理,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更管理的目的所在。
  六大原则
  实施需求变更管理需要遵循如下原则:
  1.建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。
  2.制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。
  3.成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。
  4.需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。
  5.需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。
  6.妥善保存变更产生的相关文档。
  应对之道   需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程,笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策:
  相互协作
  很难想像遭到用户抵制的项目能够成功。在讨论需求时,开发人员与用户应该尽量采取相互理解、相互协作的态度,对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求,也应该仔细分析原因,积极提出可行的替代方案。
  充分交流
  需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想,并加以分析和整理。同时,软件开发人员应该向用户说明,进入设计阶段以后,再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。
  安排专职人员负责需求变更管理
  有时开发任务较重,开发人员容易陷入开发工作中而忽略了与用户的随时沟通,因此需要一名专职的需求变更管理人员负责与用户及时交流。
  合同约束
  需求变更给软件开发带来的影响有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝接受或部分接受,还可以规定发生需求变更时必须执行变更控制流程。
  区别对待
  随着开发进展,有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况,开发人员可以向用户说明,项目的启动是以最初的基本需求作为开发前提的,如果大量增加新的需求(虽然用户认为是细化需求,但实际上是增加了工作量的新需求),会使项目不能按时完成。
  如果用户坚持实施新需求,可以建议用户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。同时,还要注意控制新需求提出的频率。
  选用适当的开发模型
  采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型,再与用户沟通。一般用户看到一些实际的东西后,对需求会有更为详细的解释,开发人员可根据用户的说明进一步完善系统原型。
  这个过程重复几次后,系统原型逐渐向最终的用户需求靠拢,从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。
  用户参与需求评审
  作为需求的提出者,用户理所当然是最具权威的发言人之一。实际上,在需求评审过程中,用户往往能提出许多有价值的意见。同时,这也是由用户对需求进行最后确认的机会,可以有效减少需求变更的发生。

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

令人烦恼的需求变更     在软件开发中,大家都会遇到过这样的问题:客户的一个新想法,就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些,毕竟功能性需求不实现...
  • xiaoxian8023
  • xiaoxian8023
  • 2013年05月07日 14:50
  • 2508

项目管理---项目经理如何应对客户的需求变更?

相信做软件开发的我们,大家都有这样的体会,当我们辛辛苦苦的熬了几个月的通宵、加班后,终于完成了客户提出的V1.0功能需求,当我们大家准备按部就班的进行系统上线时,客户、企业用户突然改变了需求,不想这么...
  • lishehe
  • lishehe
  • 2014年03月25日 20:04
  • 8553

项目需求变更原因及处理

 需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关,比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。不论在项目变更控制中采取什么方法、策略,对于项目本身的变化一定要时时洞悉,...
  • qq_14891839
  • qq_14891839
  • 2016年06月01日 14:29
  • 1978

需求变更应对之道

项目需求变更规范 一、需求变更的原因分析 需求变更可能来自方案服务商、客户或BD等,也可能来源于项目组内部。而需求变更的表现形式是多方面的,如老板临时改变想法、需求插入,某一功能需求的增加或减...
  • kuangshow0227
  • kuangshow0227
  • 2017年06月14日 10:19
  • 97

《领域驱动设计-软件核心复杂性应对之道》笔记

问题: 1、  何为领域驱动设计(DOMAINDriven DESIGN)? 2、  UBIQUITOUS LANGUAGE(领域通用语言)应该是如何去描述 3、      笔记: 1、 ...
  • flyweilai1287
  • flyweilai1287
  • 2014年06月02日 18:40
  • 1418

软件过程解决需求变更方案

软件的基础是需求,需求变动后数据库、设计、编码等都需要变动,严重的甚至会推翻原来所作的一切工作。 如果需求一直变动,就会进入需求设计循环,大部分时间都会化在需求变更后的设计变动上。这样总体上对理清...
  • tearsmo
  • tearsmo
  • 2011年09月01日 11:06
  • 935

软件项目的需求变更及对策

转自:http://www.uml.org.cn/RequirementProject/201405153.asp [摘 要] 需求分析是软件生命周期中的重要阶段,决定软件项目的成败;需求变...
  • yaoyuan_difang
  • yaoyuan_difang
  • 2014年05月15日 13:17
  • 2243

项目经理应对需求变更的策略

需求变更是一个无法避免的事实,它会导致软件开发过程中产生成本增加、质量不过关等风险,而且越往后的变更产生的风险将越大。在项目实施过程中,项目经理所要面对的将是一系列和多方面的考验。经常发生的、也很令人...
  • zhuzj12345
  • zhuzj12345
  • 2018年01月22日 15:40
  • 20

测试组如何应对需求变更

在测试过程中,如果有需求变更产生,必须通过测试组同意。   面对需求变更,测试组需要对变更进行评估: 1.       变更是否有详细的需求说明? 2.       变更涉及范围有多大...
  • BetterFate
  • BetterFate
  • 2013年09月05日 11:07
  • 675

《领域驱动设计 软件核心复杂性应对之道》 - 书摘精要

(序) 领域模型的最大价值是它提供了一种通用语言,这种语言是将领域专家和技术人员联系在一起的纽带; (P2) 模型是一种知识形式,他对知识进行有选择的简化和有目的的结构化; ...
  • GATTACA2011
  • GATTACA2011
  • 2014年10月02日 15:24
  • 615
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:软件项目需求变更六大原则及应对之道
举报原因:
原因补充:

(最多只允许输入30个字)