可以这么说，
需求是“根”，
需求是最难的，
所以一旦需求变更了，会很麻烦的，
所以需求评审也就显得尤为重要了。
就目前国内软件的形势，
需求变更是免不了的，
是常事，
所以了解学习需求变更流程是必须的。

对于需求变更现在很多项目都会频繁出现，让开发人员很头疼的事情，所以在做需求的时候还是要给予很高要求的，让需求尽量做得精细，可以采用评审来完善，但评审绝对不能流于形式。变更的复杂性也能约束需求分析人员的做事谨慎度，让他们尽量的考虑清楚一句话绝对不能出现二义性，让客户跟项目走起来。

精品的东西一定要下，我正在学着写需求呢

需求变更的前提是需求基线的清晰或者需求定义清晰 对用户需求理解正确; 现实中需求变更是不是由于需求定义不清晰造成的? 如果是那这就不属于需求变更了!

好东西，回家学习去。
另，一个建议：如果将文中流程图直接提供Visio对象就更好了~~~~~~~~~~~

有些时候不是我们真正的需求在变，而是我们的设计不够灵活，不要把一切易变的都归结为需求。

不错，给自己的流程提了个醒。

需求变更很有必要的，学习一下；实战的比较有说服力，谢谢分享。

就算有流程，需求变更也是建立在对项目范围可控的基础之上

我有问题，如果项目周期较短，前提项目计划并没有做太多的风险估算，走需求变更流程过于冗长，该怎么办？