簡介 本章簡要介紹迭代和進化式需求，并且描述特定的UP需求制品，以此為后續的面向需求的章節做好鋪墊。
定義：需求 需求(requirement)就是系統（更廣義的說法是項目）必須提供的能力和必須遵從的條件。
UP提出了一系列的最佳實踐，其中之一就是需求管理（manage requirement）。需求管理不主張采用瀑布的觀點，即在編程之前項目的第一個階段就試圖完全定義和固話需求。在變更不可避免，涉眾意愿不明朗的情況下，UP更推崇用“一種系統的方法來尋找、記錄、組織和跟蹤系統不斷變更的需求”
簡而言之，就是通過迭代巧妙地進行需求分析、而非草率和隨意地為之。 需求分析的最大挑戰是尋找、溝通和記住什么是真正需要的，并能夠清楚地講解給客戶和開發團隊的成員。
進化式需求與瀑布式需求 注意，在UP的需求管理定義中使用了“不斷變更”一詞。UP能夠包容需求中的變更，并將其作為項目的基本驅動力。這一點極為重要，也是迭代和進化式思想與瀑布思想的核心差異。
尋找需求可以采用的方法 除“不斷變更”之外，另一個重要的詞是“尋找”。也就是說，UP提倡使用一些有效的技巧以獲得啟示，例如與客戶一同編寫用例、開發者和客戶共同參加需求討論會、請客戶代理參加焦點小組以及向客戶演示每次迭代的成果以求得反饋。 UP歡迎任何能夠帶來價值并提高用戶參與度的需求啟發方法。
需求的類型和種類 在統一過程中，需求按照“FURPS+”模型進行分類，這是一種有效的記憶方法，其含義如下：
》功能性（Functional）：特性、功能、安全性。
》可用性（Usability）：人性化因素、幫助、文檔。
》可靠性（Reliability）：故障頻率、可恢復性、可預測性
》性能（Performance）：響應時間、吞吐量、準確性、有效性、資源利用率。
》可支持性（Supportability）：適應性、可維護性、國際化、可配置性
“FURPS+”中“+”是指一些輔助性的和次要的因素，比如：
》實現（Implementation）：資源限制、語言和工具、硬件等。
》接口（Interface）：強加于外部系統接口之上的約束
》操作（Operation）：對其操作設置的系統管理
》包裝（Packaging）：例如物理的包裝盒
》授權（Legal）：許可證或其他方式
其中某些需求可以統稱為質量屬性（quality attribute）、質量需求(quality requirement)或系統的“某屬性”。這些需求包括：可用性、可靠性、性能和可支持性。在一般使用中，需求按照功能性（行為的）和非功能性（其他所有的行為）來分類，有些人不喜歡這種寬泛的分類方式，但這種方式已被廣泛采用。
UP制品如何組織需求 UP提供了一些需求制品。同所有UP制品一樣，它們都是可選的。其中關鍵的制品包括：
》用例模型：一組使用系統的典型場景。主要用于功能需求
》補充性規格說明：基本上是用例之外的所有內容。主要用于所有非功能需求，例如性能或許可發布。該制品也用來記錄沒有表示為用例的功能特性，例如報表生成
》詞匯表：詞匯表以最簡單的形式定義重要的術語。同時也包含了數據字典（data dictionary）的概念，其中記錄了關于數據的需求，例如有效性規則，容許值等。詞匯表可以詳述任何元素：對象屬性、操作調用的參數、報表布局等。
》設想：概括了高階需求，這些需求在用例模型和補充性規格說明中進行細化。設想也概括了項目的業務案例。設想是簡短的執行概要文檔，用以快速了解項目的主要思想。
》業務規則：業務規則（也稱為領域規則）通常描述了凌駕于某一軟件項目的需求或政策，這些規則是領域或業務所要求的，并且許多應用應該遵從這些規則。政府的稅收法規是一個例子。領域規則的細節可以記錄在補充性規格說明中，但是因為這些規則通常更為持久，并且對不止一個軟件項目適用，所以應將其放入集中的業務規則制品（供公司的所有分析員共享），以便在這方面做出的分析工作能夠被更好的重用。
制品的正確格式 在UP中，所有制品都是信息的抽象，它們可以存儲在Web頁，板報，或各種可以想象到的載體之上。