文档介绍：如何看待软件开发中的需求变更
对于软件开发项目来说,开发的过程中不可避免的会出现需求变更,发生变更的环节也比较多,因此变更控制显得格外重要。变更控制对项目成败有重要影响,项目开发之前要明确定义,开发过程中要严格执行。对变更控制的目的并不是控制变更的发生,而是对变更进行管理,以便更好的处理变更,确保变更有序进行,而这些变更都是靠文档来记录的,规范操作的,从而减少因为需求变更而带来的损失,加快项目的开发速度。  
文档固然重要,但精细到什么程度就有待大家一起探讨了。目前大部分都是为了文档而文档就失去了意义。在项目初期(范围定义),对于文档我更倾向于写个大概,具节开发的时候不断请教,文档的工作不是不断累进明细的,是越来越明确的一个过程。在工作分解结构之前,文档工作应该明细到每个模块的功能要求,界面要求,验收标准等内容。文档写出来后,不是放在那里睡觉的,而是需要拿它和客户周旋的。一旦文档得到客户或项目干系人签字后,就按照文档严格执行。在执行过程中,有项目干系人说这说那的,少了这个或那个功能,这个时候就要用文档来说话了,若在原有功能的基础上增加的话,写个需求变更,这个时候项目经理要对变更进行分析,提出一个或多个解决方案(即使在项目目标不允许的情况下也应该这么做),然后在项目的进度,成本,质量,资源的基础对其进行评估,在评估代价并且与客户讨论的时候,要让客户了解变更的后果,变更之后面临的最大问题就是项目延期,然后让客户做判断,无非下面几种情况:
,开发人员按照客户的要求修改,但要让客户知道为此要付出的代价。如果客户认为代价太大,那么开发人员就没有必要修改,按原来的进度走,但仍要记录变更,待下一版本在修改。 
,此时可能导致项目继续比较困难。如果客户不知道你为变更付出的代价,对你的辛苦便难以体会,以致没完没了的提出新的变更。  
正如前文所说,需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更,可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作,项目开发人员对于需求变更的正确态度应该和软件测试的态度一样,在需求变更发生之前尽量减少需求变更,以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更,这样做往往费力不讨好。 
相比于需求开发人员而言,客户可能对需求变更认识不足,认为他们出钱,程序员或软件开发公司就要为它服务,因此客户对需求变更往往更加肆无忌弹,