什么是初始階段 大多數項目需要一個簡短的起始步驟，在該步驟中要考慮以下幾類問題：
1、項目的設想和業務案例是什么？
2、是否可行？
3、購買還是開發？
4、粗略估計一下成本：是一萬還是十萬美元，還是上百萬美元？
5、項目應該繼續下去還是停止？
想要定義設想并大致得出所需的預算，就必須研究需求。但是，初始階段的目標并不是定義所有需求，或產生可信的預算或項目計劃。
對于是否存在過于簡化的風險，其理念是，就未來新系統的總體目標和可行性而言，只進行足以形成合理判斷的調查，并能夠確定是否值得繼續深入研究即可，而深入研究室細化階段的工作。
大多數需求分析是細化階段進行的，并且伴以具有產品品質的早期編程和測試。
因此，大多數項目的初始階段的持續時間相對較短，例如耗時一周或幾周。實際上，在許多 項目中，如果初始階段的時間超過一周，那么“初始”就失去了它的意義，因為初始階段只需確定這個項目是否值得認真研究，而不是真正去深入進行研究（這項工作應留待細化階段進行）。
用一句話來概括初始階段：
預見項目的范圍、設想和業務案例
用一句話來概括初始階段要解決的問題：
涉眾是否就項目設想基本達成一致，項目是否值得繼續進行認真研究
在迭代開發和UP中，初始階段的預算和計劃是不可靠的。它只不過提供了對工作量的粗略估計，幫助人們決定是否將項目繼續下去。
初始階段的持續時間 初始階段主要是為項目目標建立一些初始的共同構想，確定項目是否可行，并決定是否值得進入細化階段加以認真研究。如果預先就決定項目必須進行，并且項目顯然是可行的，那么初始階段會更加短暫。這時候，初始階段可能只包含第一次需求研討會，并為第一次迭代制定計劃，然后就快速地進入細化階段。
初始階段會創建的制品 PPT2列舉了一般在初始階段（或細化階段早期）會創建的制品以及各個制品所解決的問題。后續幾章將詳細解釋其中部分制品，特別是“用例模型”。 迭代開發的一個重要觀點是：在初始階段只完成其中部分制品，在后繼迭代中對其進行精化。而且，除非認定某制品很可能具有實用價值，否則不應該創建該制品。因為是在初始階段，所以相關的研究和制品內容都不多。
在初始階段可能要進行一些編程工作，其目的是創建“概念驗證”原型，（典型的）通過面向UI的原型來澄清一些需求，以及為關鍵的“顯示阻塞”技術問題做一些編程實驗。
是否意味著大量的文檔 記住，這些制品都是可選的。要有選擇地創建對項目確有價值的制品。因為這是迭代開發，所以重要的不是在初始階段創建完整的規格說明，而是形成初始、概略的文檔。這些文檔在細化迭代中精化，以便響應由早期編程和測試得到的極有價值的反饋。
同樣，創建制品或模型的重點不在于文檔或圖本身，而是其中蘊含的思想、分析和前期準備。這也正是敏捷建模的觀點：建模的最大價值是增強理解，而非記錄可靠的規格說明。
還要注意的是，可以在以后的項目中部分重用以往項目中的制品。一般在不同項目中，風險、項目管理、測試和環境這些制品都可能存在大量相似之處。所有UP項目都應該用相同的名稱，以相同方式來組織制品（例如風險列表、開發案例等）。這樣就可以方便地從以往項目中找出能夠在新項目中重用的制品。
何時知道自己并不了解初始階段
1、當認為大部分項目的初始階段會持續幾周或更長時
2、在初始階段試圖定義大部分的需求時
3、期望初始階段的預算和計劃是可靠的
4、定義架構（應該在細化階段以迭代方式來定義架構）
5、認為正確的工作順序應該是：1>定義需求 2> 設計架構 3>實現
6、沒有業務案例或設想制品
7、詳細編寫所有用例
8、沒有詳細編寫任何用例，與之相反，應該編寫10%~20%的用例以便獲得對問題范圍的真實認知
初始階段中有多少UML初始階段的目的是收集足夠的信息來建立共同設想，決定項目是否繼續進行，以及項目是否值得進入細化階段來認真研究。 初始階段更關注對基本范圍的理解以及10%的需求，這主要是以文字方式表達的。實際上，本書就是如此，大多數UML圖將出現在下一個階段--細化階段