1、范围没有圈定就开始细化
细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。
当细化到一定程度并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是人工手动添加的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。
2、没有指定需求的基线
需求的基线是指是否容许需求变更的分界线。
随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来，是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少）。
3、没有良好的软件结构适应变化
组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。
但适应变化必须遵循一些松耦合合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。
三、需求变更控制
前面已经说过了，在软件开发项目开始之前，就要消除“绝不允许发生需求变更”的思想。在项目进行，一旦发生需求变更，更不要不一味的抱怨，也不要去一味地迎合客户的“新需求”，而是要管理和控制需求变更。
1、 分级管理客户需求
软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全的正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到了客户的投入收益，所以有的时候项目经理反倒应该为客户着想。
文章来源于领测软件测试网 https://www.ltesting.net/