1、需求增加
2、需求删除
3、需求发生改变

我们在实施项目的时候，往往做着做着，突然发现项目的进度已经落下了这么多。查找其原因，我们往往会发现，项目的某些需求在悄然的发生着改变，或者是某些的功能在现有基础上功能增强了，或者是某些功能的性能上有更大的要求，或者增加了一些小的新需求，或者是某些需求的实现方式发生了变更。这些变更在悄悄的，让你不痛不痒的发生着，等你察觉出来这些改变给你的项目带来了什么样的灾难性的后果的时候，很多时候已经晚了，你的产品已经面目全非，你的项目已经无可救药的要100%延期了。

现在我们再来回想一下需求发生变更的原因。需求的变更，往往是以下几个方面引起的变更：
1、客户有新的需求提出；
2、客户在看产品演示时提出的更加具体的需求；
3、客户在看产品演示时提出已经实现的部分不符合他们的需要；
4、产品经理根据市场需要提出的新的需求；
5、SA提出的技术上的需要；

现在再来考虑一下新的需求提出来以后，得不到有效控制的原因。当第三方提出新的需求以后，往往是领导（有时候也是SA，这种情况下需求得不到有效控制的情况往往更加严重）一看“应该”只是一个小小的修改，没有太大的影响，所以直接吩咐开发人员去实现了，知会开发经理一声；好一点的，和开发经理或者SA商量一下，然后就将任务部署下去了。开发人员尽管不情愿（原计划之外的额外工作），但也是不甘不愿的完成了，但相应的设计文档、变更记录、需求规格说明书中变更？这些你别想了。不是只是一个小小的改变么？这些工作不作也罢了。

现在让我们来讨论一下需求变更得不到有效控制所带来的后果。首先，有些小需求看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能的领导或者SA没有考虑到的细节问题；其次，新需求的提出影响了项目原有的进程，它是中间插进来的空降任务，给项目组成员心理上造成一定的负面影响，新的任务说下来就下来了，原来的计划就没有太大的用处了，而且任务完不能按时完成也不是我的原因，领导部署新的任务了么；再次，那些客户头脑一热、领导一拍脑袋就部署下去的需求，往往得不到有效的设计和需求追溯，一不小心就被淹没了，找不到这部分是怎么设计的，对应于哪些代码，出了问题之后往往要耗费很长时间去定位和跟踪；最后，新增的任务的不到有效的审核，往往对整个系统的严谨性、健壮性和可维护性留下隐患。