對無法在項目一開始就固化的需求進行演進型的設計。你現在不必要對這個系統進行過分的建模，只要基于現有的需求進行建模，隨著項目的進行，項目環境和需求發生變化時，再來完善和重構這個系統。
遞增的變化是指你不用在模型中包容所有的細節，你只要開發一個小的模型或是概要模型，打下一個基礎，然后慢慢的改進模型。
敏捷建模采取不同的設計態度來"擁抱變化"。它認為需求時刻在變，人們對于需求的理解也時刻在變。隨著項目的進行，項目環境也在不停的變化，因此你的開發方法必須要能夠反映這種現實。對于用戶的反饋，要勇于對自己的代碼進行修改，丟掉壞的代碼。
對于易變的需求，敏捷方法使用了一系列實踐。其核心則是迭代式開發，尋求快速的反饋，用戶經歷過一次或幾次的迭代之后，對軟件開發和業務需求如何實現已經有了形象的認識，用戶提出的需求基本上可以代表他們的真實需求。這時，就可以將需求進行凍結。后面如果還有修改，將是細節的調整，不會對軟件的架構產生重大的影響。
按照上述的敏捷方法的原則來設計系統，則能夠使我們正確的看待用戶需求的變動，從而較好的適應需求的變動。如果項目管理者和程序開發人員真正的理解并貫徹這種方法，用這種思想去管理項目，那么就能有效的避免出現項目后期軟件架構混亂、補丁加補丁、系統性能大大減低的情況。
2.項目管理的作用
1)推動技術與需求"匹配"
上面提到要采用敏捷方法的迭代式開發，盡快的凍結需求，那么通過項目管理的手段，可以控制和縮短需求凍結的時間。
項目管理是一種管理手段，目的是在指定時間和資源的條件下，保質、按時地完成預定的任務。作為一個項目管理人員，必須注意有些需求的變化是由于業務與設計的"不匹配"造成的，即用戶一方可能對信息系統的開發和實現方法，缺乏全面的了解，不懂得如何將傳統的業務模式轉換為信息系統所要求的處理模式。
另一方面，也可能開發商對用戶方的需求、細節了解不充分等因素，使得用戶方與開發方對工程的理解從一開始就存在著差異。因為業務人員開始提不出實際的需求來，而只是把大致的工作流程介紹一遍。而這種認識上的差異與理解的不同往往在開發初期并沒有表現出來，當軟件基本成型，給用戶演示時，顯出較大的差異。
作為開發商，過去經常將開發的注意力集中在"技術"上，即計算機軟硬件、操作系統平臺和數據庫等技術實現上。而對于信息系統的開發，則必須首先考慮到用戶的理念、方針和及其對技術方法的領會等各方面因素。往往這些因素對系統成敗所起的作用，比技術實現的因素更重要。
首先，項目設計組人員要向需求方的領導及業務人員闡述信息系統是如何實現的，什么樣的業務模式適合于網絡，怎樣處理和解決什么問題，需要在傳業務模式上做哪些改進，建立基本的操作規范等等。必須明確，信息系統改變了現行的工作管理模式，使工作人員失去了一定的靈活性和隨意性。如果不建立新的操作流程和規范，在傳統手工處理方式上，實現信息系統是不可能的。
其次，詳細的了解全盤業務流程之后，用基本用戶界面原型向需求方演示和說明方案，使業務人員真正理解技術實現的思路，能夠及時發現與實際不吻合或存在的困難，這樣才可能從工作流程上或技術上來解決這些問題。
當出現問題時，項目管理人員應迅速分析問題，正確判斷哪些問題屬于不適應新的工作模式引起的，哪些問題屬于操作不當引起的，哪些問題屬于系統本身不完善引起的。對于那些由于不適應新的工作模式引起的問題，項目管理人員應引導使用人員迅速適應新的工作模式，必要時也要說服用戶方的決策層采用行政手段推動實施;項目管理人員時刻注意取得決策層的理解與支持，幫助工作人員盡快地適應新的工作方式。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
