根據項目類型的不同，需求定義的產物大致可以分為POS（Project Overview Specify，項目綜述）和Vision（願景）兩大類。
POS類
對於項目型的軟件開發工作，通常會在立項結束時編寫一份立項報告，最典型的格式包括POS、項目可行性報告、項目章程等。雖然在格式上有一些差異，不過內容上還是比較接近的，主要包括如下內容。
Vision類
對於一些生命週期相對較長、應用面相對較廣（例如將在多家企業中使用）的項目或產品而言，則會在POS的基礎上添加一些相關的內容。添加的內容主要是市場分析、規劃方面的，最有代表性的是RUP推薦的Vision文檔。如圖所示。
從上面羅列的內容中可以發現Vision文檔更加重視對市場潛在機會的分析，因此甚至會加入諸如SWOT（優勢、劣勢、機會、挑戰）等市場分析的內容。
關鍵要素分析
1.目標
一個好的目標描述應該滿足SMART原則：
● 必須是具體（Specific）的：目標必須能夠指導具體的工作；
● 必須是可以度量（Measurable）的：這樣才能進行成本/效益分析；
● 必須是可以達到（Attainable）的：否則是沒有意義的目標；
● 必須和其他目標具有相關性（Relevant）；
● 必須具有明確的截止期限（Time-based）。
而在具體的寫作過程中，應該注意從目標、業務優勢、度量指標、合理性、可行性和可達成性方面進行編寫。
2.範圍
需求分析人員在進行需求定義工作時，核心的工作就是確定範圍。但對於需求分析人員最大的困擾在於如何描述範圍？雖然很多書籍推薦通過上下文關係圖，但在實際的應用過程中仍然存在很多疑問與誤區，這裡推薦“兩圖一綱”的方法。“構件圖、上下文關係圖和需求大綱”
3.相關人員與用戶
在進行需求定義時，需要對和軟件項目相關的人進行研究。
對於用戶而言，我們需要收集和分析的信息包括：與主題相關的經驗、技術上的經驗、智力能力、對工作的態度、對技術的態度、受教育程度、語言技能、年齡、性別等信息。換句話說，是對其能力進行建模。需求階段描述的是用戶的能力特點，旨在提高可用性。
為什麼要對其能力進行建模呢？因為只有瞭解用戶的能力特點，才能夠真正提高軟件的可用性，因為可用性是相對而言的。
除了用戶之外的相關人員則需要了解他們對軟件系統的關注點，想通過系統獲得或實現什麼利益，這些信息對於項目實施過程而言是十分有價值的。
4.相關事實與假定
相關事實是可能對產品產生影響的外部因素，具體來說，就是要羅列出對產品產生影響的其他因素、系統和活動，以便提醒開發者可能對需求產生影響的一些情況和事實。例如：原有應用程序主要的問題就是查詢操作太慢，導致系統無法正常使用。這樣開發人員在處理新系統的查詢操作時，就會對性能問題予以足夠的重視。
而假定的內容包括需求定義階段中所做的假設清單，這些假設都是對產品開發有影響的；它和相關事實的區別在於，它不一定是真實的，它可能是對用戶能力、外部系統性能的一種假設。因此開發人員需要對這些假定進行核實，以免產生無用功的情況。
閱讀更多 產品與體驗 的文章
