需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因：
（1）、范围没有圈定就开始细化
细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。当细化到一定程度后并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是手工添人的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。
（2）、没有指定需求的基线
需求的基线是指是否容许需求变更的分界线。随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少），其过程如下：变更请求à比较基线à变更实现。
（3）、没有良好的软件结构适应变化
组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。但适应变化必须遵循一些松祸合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。
2、如何控制需求变更
按照现代项目管理的概念，一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小，就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。
进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证项目变更的规范和有效实施，通常项目实施组织会有一
（1）、项目启动阶段的变更预防
对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候千万不能手软，这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。相对于需求来说，什么WBS、风险管理、计划进度都是次要的，只要需求做好了就会一帆风顺。
（2）、项目实施阶段的需求变更
成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点：
需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。
需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。
小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。
精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。
注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/