需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能知道但又不得不那么做。需求变化的后果可能是造成系统的重新设计，设计人员的日程的重新安排，已经完成的工作可能要重做或者完全抛弃，对其他项目产生影响，硬件需求可能要因此改变，等等。如果有许多小的改变或者一次大的变化，项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的出现，需求改变带来的复杂性可能导致错误，还可能影响工程参与者的积极性。
⑤、时间压力
软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。
⑥、自负人更喜欢说:'没问题','这事情很容易','几个小时我就能拿出来'
太多不切实际的‘没问题’，结果只能是引入错误。
⑦、代码文档贫乏
贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写得艰难必定读的痛苦”)。
⑧、软件开发工具
可视化工具，类库，编译器，脚本工具，等等，它们常常会将自身的错误带到应用软件中。就象我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只会使项目变得更复杂。
为了更好地解决这些问题，软件界做出了各种各样的努力。
人们曾经认为更好的程序语言可以使我们摆脱这些困扰，这推动了程序设计语言的发展，更多的语言开始流行，为了使程序更易于理解开发了结构化程序设计语言，如pl/1,pascal等;为了解决实时多任务需求开发了结构化多任务程序设计语言，如modula，ada等;为了提高重用性开发了面向对象的程序设计语言，如simlasa等;为了避免产生不正确的需求理解，开发形式化描述语言，如hal/s等，这使得建立基于自然语言的描述成为可能，人们以形式化语言来描述需求;为了支持大型数据库应用，开发了可视化工具，如visual studio、power builder等。程序语言对提高软件生产效率起到了一定的积极作用，但它对整个软件质量尤其是可靠性的影响，与其他因素相比作用较小。
可能是因为程序语言基于严格的语法和语义规则，人们企图用形式化证明方法来证明程序的正确性。将程序当作数学对象来看待，从数学意义上证明程序是正确的是可能的。数学家对形式化证明方法最有兴趣，在论文上谈起来非常吸引人，但实际价值却非常有限，因为形式化证明方法只有在代码写出来之后才能使用，这显然太迟了，而且对于大的程序证明起来非常困难。
受到其他行业项目工程化的启发，软件工程学出现了，软件开发被视为一项工程，以工程化的方法来进行规划和管理软件的开发。
针对需求不确定的应用，可以使用渐进和迭代类的开发模型。还可以采用快速应用程序开发(rad)和协同应用程序开发(jad)技术，由软件开发者和用户代表共同参与开发软件规范。rad和jad的基本思路是开发者和用户共同设计系统中的屏幕，开发者迅速地把实现这些屏幕的最基本功能编写好，然后把它们交给用户看，然后用户和开发者回顾这些屏幕以确认它们达到了用户的要求，这个周期一直持续到系统的基本部分定义完毕。一旦设计被用户接受，开发者将完成完全实现屏幕需要的代码。rad和传统软件开发项目之间的一个基本区别是：应用程序rad系统是按阶段发布的。传统项目一般一次发布，也叫“big bang”。rad方法使用高效开发工具，开发者能够非常迅速地设计出系统的基本屏幕，允许用户在开发周期中很早就能见识到系统将来看起来怎么样，避免了在传统开发项目中长篇大论并且枯燥难懂的说明。
文章来源于领测软件测试网 https://www.ltesting.net/
