对无法在项目一开始就固化的需求进行演进型的设计。你现在不必要对这个系统进行过分的建模，只要基于现有的需求进行建模，随着项目的进行，项目环境和需求发生变化时，再来完善和重构这个系统。
递增的变化是指你不用在模型中包容所有的细节，你只要开发一个小的模型或是概要模型，打下一个基础，然后慢慢的改进模型。
敏捷建模采取不同的设计态度来"拥抱变化"。它认为需求时刻在变，人们对于需求的理解也时刻在变。随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。对于用户的反馈，要勇于对自己的代码进行修改，丢掉坏的代码。
对于易变的需求，敏捷方法使用了一系列实践。其核心则是迭代式开发，寻求快速的反馈，用户经历过一次或几次的迭代之后，对软件开发和业务需求如何实现已经有了形象的认识，用户提出的需求基本上可以代表他们的真实需求。这时，就可以将需求进行冻结。后面如果还有修改，将是细节的调整，不会对软件的架构产生重大的影响。
按照上述的敏捷方法的原则来设计系统，则能够使我们正确的看待用户需求的变动，从而较好的适应需求的变动。如果项目管理者和程序开发人员真正的理解并贯彻这种方法，用这种思想去管理项目，那么就能有效的避免出现项目后期软件架构混乱、补丁加补丁、系统性能大大减低的情况。
2.项目管理的作用
1)推动技术与需求"匹配"
上面提到要采用敏捷方法的迭代式开发，尽快的冻结需求，那么通过项目管理的手段，可以控制和缩短需求冻结的时间。
项目管理是一种管理手段，目的是在指定时间和资源的条件下，保质、按时地完成预定的任务。作为一个项目管理人员，必须注意有些需求的变化是由于业务与设计的"不匹配"造成的，即用户一方可能对信息系统的开发和实现方法，缺乏全面的了解，不懂得如何将传统的业务模式转换为信息系统所要求的处理模式。
另一方面，也可能开发商对用户方的需求、细节了解不充分等因素，使得用户方与开发方对工程的理解从一开始就存在着差异。因为业务人员开始提不出实际的需求来，而只是把大致的工作流程介绍一遍。而这种认识上的差异与理解的不同往往在开发初期并没有表现出来，当软件基本成型，给用户演示时，显出较大的差异。
作为开发商，过去经常将开发的注意力集中在"技术"上，即计算机软硬件、操作系统平台和数据库等技术实现上。而对于信息系统的开发，则必须首先考虑到用户的理念、方针和及其对技术方法的领会等各方面因素。往往这些因素对系统成败所起的作用，比技术实现的因素更重要。
首先，项目设计组人员要向需求方的领导及业务人员阐述信息系统是如何实现的，什么样的业务模式适合于网络，怎样处理和解决什么问题，需要在传业务模式上做哪些改进，建立基本的操作规范等等。必须明确，信息系统改变了现行的工作管理模式，使工作人员失去了一定的灵活性和随意性。如果不建立新的操作流程和规范，在传统手工处理方式上，实现信息系统是不可能的。
其次，详细的了解全盘业务流程之后，用基本用户界面原型向需求方演示和说明方案，使业务人员真正理解技术实现的思路，能够及时发现与实际不吻合或存在的困难，这样才可能从工作流程上或技术上来解决这些问题。
当出现问题时，项目管理人员应迅速分析问题，正确判断哪些问题属于不适应新的工作模式引起的，哪些问题属于操作不当引起的，哪些问题属于系统本身不完善引起的。对于那些由于不适应新的工作模式引起的问题，项目管理人员应引导使用人员迅速适应新的工作模式，必要时也要说服用户方的决策层采用行政手段推动实施;项目管理人员时刻注意取得决策层的理解与支持，帮助工作人员尽快地适应新的工作方式。
文章来源于领测软件测试网 https://www.ltesting.net/
