如何看待软件开发中的需求变更.doc

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