“需求变更”——软件需求管理中最让人头痛的东西，而且是不能避免的，每个项目都会出现，只是变更多或少的问题，不能完全杜绝，能做的只是预防，极少需求变更。还是按照上面的方法来写，什么是需求变更，需求变更的影响，需求变更的预防。
需求变更通用的说法是，软件产品中增加某个功能，删除某个功能，或者对某个功能进行修改（当时老师说以前他们内部没有需求变更这个词，不管是增加，删除或修改，都做为新需求），需求管理的核心就是降低需求变更频率，对需求变更进行预防。
再来看看需求变更可能产生的影响：每个人都深有体会的：
1、 对成本的影响——不用解释了；
2、对开发进度的影响——开发人员说“万恶的变更……杀……”；
3、对发布进度的影响——测试人员说“还有时间测吗，直接发布？”；
4、对人员安排的影响——开发人员与测试人员“help me！还有空闲的人吗？”；
5、……
需求变更成了罪大恶极的家伙，人人喊打了，可是“需求变更”真的有那么多“变更”？老师在里面有句话说的很有思考性“需求一般是不会变化的，变化的是我们对需求的认识和理解”。
“One Page”方法，每次的“需求变更”，都记录为新需求，记录成新的需求文档（也叫一页纸需求文档），前期项目中会定义好项目里程碑，项目进度严格按照里程碑进行，产生“需求变更”后，对于很小“需求变更”在当时里程碑中解决，其它“需求变更”做为新需求在下一里程碑中解决。
堵不如疏，变更不可避免，分析出变更的原因，找出根源，从根源上解决，“需求”就是根源，需求分析的好坏决定着需求变更的多还是少，“需求分析”好与坏是由需求人员，需求获取，需求团队来决定的，参考后续系列文章。
版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
本文出自hjjlearning的51Testing软件测试博客：http://www.51testing.com/?18049
相关阅读：
