用户需求作为整个软件项目中最关键的一个输入，需求变更管理能否做到位自然就成为决定软件项目成败的关键因素之一。对于需求变更，除了从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外，还应该改变我们的意识和对需求变更的理解，主动做好对需求变更的控制和管理，减少“需求变更之痛”。
第一步：先把理由说清楚
不管什么样的变更，首先都有第一步：变更申请。通常客户提出需求的渠道是非正式的，例如口述，打电话或当面交流，那就先由需求人员把变更描述记下来，请注意：一定要有书面的记录。然后，我们可以把需求变更申请的描述提交给客户，由客户进行签字确认。
同时，要引导客户说明进行需求变更的理由，要描述清楚如果变更被接受，对业务的正面促进，如果变更被拒绝对业务的负面冲击。对于有些强势的客户，可能直接说“就按我说的办”，这时就需要需求人员动动脑筋，从客户的谈话中间去捕获信息，从客户的业务角度出发去了解变更的必要性。
第二步：能否实现作评估
变更控制小组(Change Control Board，简称 CCB)要对需求变更实现的技术可行性进行分析和评价。是否要成立CCB可视公司的具体情况而定，对于简单的需求变更，由项目组进行分析即可，但对于较复杂的需求变更，就至少需要“技术大牛”和相关负责人对可行性和影响进行评估了。
第三步：可以实现看进度
这一步是评价对工期的影响，先看对具体活动工期的影响，再看对于整体工期的影响，一定要用数据来说话。有人可能马上会反驳说，工期评价没用，反正是自己消化掉。其实从这一步到第五步将工期、成本、质量都进行量化的重要目的就是强迫我们的项目组先要想清楚，一个变更意味着什么。如果自己心里都没数，又怎么去和客户交流?我们在项目中、甚至工作和生活中，就经常由于没有确切量化数据的支撑而产生不必要的矛盾和摩擦。
第四步：变更成本要算足
有些变更不仅会增加项目工作量而且会导致项目中需要添加新的人手 (可能因为独特的技术背景)，而现有的人员怎么样加班也是无济于事的。因此，项目负责人在接收到变更请求时，不仅要考虑工作量所增加的人天数，还要考虑现有人力资源能否满足要求。
第五步：质量不得有马虎
变更会带来潜在的质量问题是毋庸置疑的，而且问题可能会在设计、编码、测试和运行各个阶段引入。如果组织有量化的历史数据作参考(比如功能点、缺陷密度等),则开展变更所导致的质量问题分析相对容易些，否则只能进行一些定性分析了。例如要在测试阶段后期实施一项较大的变更，通过定性分析可知：由于引入新功能或修改功能可能会导致更多的缺陷，而在回归过程中如发现新的问题需要修改的话又可能带来更多的问题。
第六步：风险再细分
由于变更往往意味着要实现更多的功能，更多的功能意味着更多的工作要做，因而面临更多的变数，也即我们经常所说的风险。比如说变更往往伴随着工期的延长，而对于在异地开发的项目遇到此种情形更有可能导致项目组成员普遍的厌倦情绪，对应的风险表述就是项目组士气低下，导致工作效率下降，甚至会引起人员的流失。对于项目组来说，必须要预见这种类型的风险并制定相应的措施。
第七步：主意大家拿
最后一步是根据前面给定的各方面信息综合权衡以后做出是否变更的决定。实际上，通过实施上面六个步骤已完成了需求变更理由的描述、技术可行性分析和进度\成本\质量\风险的影响分析，这时再让相关决策人员来拍板就变得相对容易了。