由于开发人员没有参与过上一个版本的开发工作，他们对于旧系统并不了解．虽然在阅读了以前的需求文档以及使用了软件之后，大概对系统的功能有了一个初步的认识．但是对于系统中出现的各种逻辑关系并没有深入了解下去．作为项目经理，在这项工作中，失误之处在于任务的结果（即输出）没有事先定义清楚，从而也就导致无法确认目标是否已经达到，再加上需求文档描述的也不是十分清晰．最后，只是在开发人员觉得已经理解该系统的基本上，进行了下一步的工作．没有进行进一步的确认工作，不知道组员进行旧系统已经了解到了什么样的程度。这个问题的结果，就是直接导致了后期的开发过程中，由于对于原先系统的逻辑关系不是很清楚。对于旧代码理解和新代码编写进行地不是很顺利。
B. 对新需求的分析不够
这还是个老问题，但又不是一个问题．说它是个老问题，因为分析需求要求考虑细致全面，并且能引导客户，启发客户提供更有价值的信息。事实上，需求分析我们做的算是很尽力了，同时客户把需求一条条的列出来给我们，相对来说需求已经很清楚了。我们在接到这些需求后，不仅研究了新功能，还把他们对于旧系统的影响都做了分析。但还是有些问题没有能在需求文档中反映出来，后面的影响也是可想而知的了。我以前的文章中才曾提到过相关的问题，在这里就不再重复了。不过，从另一个角度来看，它又不是一个问题。为什么这么说呢，因为需求实在不是能够在分析阶段就能完全理解透彻的，甚至有的需求客户也模模糊糊，直到交付以后才提出了改动的要求。软件开发经过这么多年的发展，大家已经认识到了一点：需求是变化的。要达到能够拥抱变化的要求，我们要对开发方法进行改进，相关的问题我在后面也会提到。
需求分析阶段出现的问题，解决的可操作性不是很大，更多的是从思想或经验上解决，而后面几个阶段出现的问题都相对具体一些。
2、设计阶段
设计阶段的问题相对比较明显――结构设计不合理，或者说还不够。一个传统的Ｃ／Ｓ结构的系统，基本结构我们采用了经典的三层模型来划分系统。由于是在旧有系统上的改进，我们在尽量不改变原有系统的基础上添加新的功能。
文章来源于领测软件测试网 https://www.ltesting.net/
