降低需求分析的複雜度。
爲了解決項目進展緩慢的問題，儘早進入項目開發的實質階段，在需求分析的時候，降低需求分析的複雜
度成爲了關鍵。
如何降低需求分析的複雜度：
1，提高抽象層次
在軟件開發中我們面對的一個主要問題是複雜度，降低複雜度對生產力有很大影響。在更高的抽象層次工
作降低了複雜度並使交流變得容易。
2，隔離功能實現
把業務建模和功能實現分開來。在起初階段，只考慮業務領域實體的關係，以快速尋找系統中個實體的本
質關係。
3，運用統一建模語言（UML）
利用高級工具，方便了解其周圍的高級構件的合作而同時隱藏了不必要的細節。
4，運用統一開發過程（RUP）
不要一步到位，要形成迭代開發過程。
5，業務建模
業務建模是在需求之前的。
把一個項目分成10個核心工作流程（Core Workflows）和4個階段（Phases），並以核心工作流程爲Y軸，階段爲X軸建立起一個項目視圖（圖一）。
調查主要業務邏輯：什麼叫主要業務邏輯？包括了企業的主要業務流程、主要的業務規則、重大的算法。這些都是需要在一開始就十分明確的資料，需要在建模會議上了解清楚。當然，你不能對你的項目涉衆說，"這個，接下來，大家談一談主要的業務邏輯吧。"下面的涉衆一定摸不着頭腦。你還是應該引導涉衆，從涉衆的話語中捕捉你需要的信息。
避免細節：建模會議主要的目標是建立高階需求。如果把過多的時間花在討論雞毛蒜皮的小事，那就會浪費大家的時間。而在此時調查需求細節是沒有很大的意義的。因爲你對很多的事情都還不瞭解，需要進一步的深入。這時候的細節對你並沒有太多的幫助。
需求分析： 叫不懂又不願意學OO，RUP，business entity和UML的人搞需求是危險的。