軟件不可見性問題
新軟件應用程序概念化的難點因項目的不同而不同。雖然某些項目的需求很直觀 ― 或許就像把一項新技術應用於一個著名的領域 ― 但其它項目需求可能更復雜。當我們不斷的將軟件技術用於未知領域，為軟件系統創建需求的行為成為一種概念上的革新。這種革新不只是一種個體的復雜的腦力勞動，其難處還在於與更大的開發團體進行交流。
Frederick Brooks 把那些難以概念化和描述的新軟件應用程序的屬性稱為 軟件不可見性。雖然其它如硬件之類的領域存在物質表現形式，但軟件領域沒有。我們可以看得見或者評測出軟件應用程序的效果，不過其系統表現形式本質上卻是思維的。這就是我們創建並依賴於軟件模型的許多原因之一。模型賦予軟件物理維度使我們得以更好的了解和表達它的方向。
任何軟件建模工作的中心是需求收集。實現需求收集過程的選擇依賴於開發項目更大的環境。 這個環境可以在需求收集過程自身中找到，也可以在另一個受到好評的模型中找到。在某些情況下，這個環境甚至可以在可交付使用的過程中找到。通過對我們探討的不同需求可能性的地方進行考察，我們總能夠辨別出系統的需求環境駐留在什麼地方。需求環境是我們與軟件不可見性對抗的領域。
恰當工作過程的選擇
為實現所選擇的需求收集過程極大的影響著軟件開發項目的成功。因為需求收集是開發周期的基礎，一個無效或選擇欠妥的需求分析過程極大的增加了項目失敗的可能性。這種可能性導致我們死守著已知的過程，通常與一個單獨的、受偏愛的軟件開發方法有關。
這裡將探討的需求收集過程抽象自三個一流的軟件開發方法：“Rational 統一過程”( Rational UnifIEd Process(RUP))，“功能驅動開發”(Feature-Driven Development(FDD))和“極端編程”( Extreme Programming(XP))。每種方法都提供大量極好的工具以協助需求收集工作。為符合子整體開發方法，我們將更多的著眼於必要的部分 ― 與每種方法相關的需求收集過程 ― 而不是整個方法自身。 除此之外，我們還會看看是否能夠組織起一個更動態更可變的需求收集過程。
四種最常見的需求收集過程是傳統的軟件收集規范(software requirements specification，SRS)、用例(use cases)、功能特性(features)和用戶情景(user storIEs)。在隨後的幾個小節，我們將考慮每個過程，請特別注意需求環境 ― 就是說，每個過程提供的用於將價值最大化的恰當情況和每個過程給開發項目帶來的獨特動力。
軟件需求規范
軟件需求規范(SRS)是最古老的需求收集過程之一。其非正式的名稱是“應該陳述”(shall statements)，傳統的 SRS 有多種形態，而且，今天眾多領域的承包工程仍然需要用到它。SRS 許多年來一直是處於支配地位的需求收集方法。
SRS 背後的思想是創建一個解決方案空間 ― 也就是這樣一個空間，其中開發小組已經設定了目標，但是，實現這些目標的行動的秩序和本質可以非常自由。因此，SRS 通常不試圖指定單個解決方案，而是指定一系列可行的解決方案。然後，開發小組有足夠的靈活性對解決正被創建系統問題的有效方法進行革新。
靈活性對於 SRS 來說，是缺點，也是優點。如果一個軟件開發小組精通他們為之創建系統的這個領域，這個小組就可以輕松使用 SRS 最大限度的對這個領域進行革新。但是，在開發小組在他們不熟悉的領域進行日常工作的時代，傳統的 SRS 作為需求收集過程可能有所欠缺。典型用戶試圖處理給定領域中的正常情況時，他們采取的步驟很可能是小組成員不了解的。因此，小組成員確定並創建的系統對於用戶社區來說，可能不是最優的。
傳統的 SRS 最適用於已被充分了解的領域和非常了解自己所處工作領域的開發小組 ― 或者領域之外的專業知識能夠很輕松就理解的開發環境。SRS 允許幾乎不需任何技術就可以調整解決方案空間以管理系統中的更改。
用例
與傳統 SRS 支持的解決方案空間方法相比，用例描述了用戶與系統交互時執行的動作序列。從某種意義上說，用例基於路線或目的。它傳達一系列用戶在使用系統以解決問題時必須啟動的動作。例如，在一個 “錄像帶出租”用例中，我們對用戶與錄像帶出租系統交互時會出現的情況進行了描述。
用例反應我們試圖使用軟件系統以達到目的時可能出現的所有事件。因為大部分軟件系統支持多個目的，大部分用例模型由多個用例組成。例如，“支付逾期費”(Pay Late Fee)用例描述了錄像帶出租系統的用戶遇到要支付逾期費這種情況時會發生的事。
用例中信息正確的水平是成功建立應用程序的必要條件。它根據環境不同而不同。如果領域的專家參與開發過程，用例就可以只勾畫系統的路線。如果領域專家不參與項目，用例就有必要提供更多信息。用例是交流需求的最佳過程。但是，就像傳統的 SRS，用例更適合已被很好了解的領域。用例可以經受一定程度的更改，但其它過程更能適應更改。
功能特性
功能特性是系統期望功能的簡要表述。功能特性的格式為：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->1 the
2
一個示例功能特性可以是：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->1 Forecast the total of quarterly sales.
2
在每個功能特性保持在最小狀態時，基於功能特性的方法效果最好。一個小組能在兩星期或更少時間內實現的功能特性就是理想的功能特性。
用名為 功能集(feature set)的組將功能特性組織起來。功能集包含描述給定目的或領域的功能特性。功能集和它的功能特性僅對需求進行了概述。作為描述需求的機制，功能特性必需和額外的環境相結合。
在“功能驅動開發”方法中，環境被精心設計成介於功能集和一個被稱為“ 領域中立組件”(domain neutral component)的色彩標記類圖表之間。 領域中立組件是個描述跨領域公共關系的語義模板。領域中立組件由瞬間間隔(moment-interval)、角色(role)、主題(subject)(當事人(party)、地點或事務)以及描述(description)組成。 瞬間間隔是那些領域的短時間要素，如處於訂貨執行系統的一個訂單。 角色是個用戶，系統和他交互並必須能識別出他。 主題是形成領域的要素。 描述是一種抽象，它集合了這些對象的元信息。圖 1 是個錄像帶出租的領域中立組件。
圖 1. 錄像帶出租方案的領域中立組件
作為一種需求收集過程，“功能驅動開發”非常靈活，它有助於在開發周期中更改管理。這一過程讓您在項目進行過程中輕松檢查並記錄新的、更改的和已除去功能特性的數目。因為一般來說功能特性小， 更改現存功能特性或添加新功能特性不大可能要求在項目級上大量的返工。功能特性還有助於挑戰軟件不可見性，因為作為跟蹤領域中立組件中的系統實體間交互結果的新功能特性可能被揭示。
功能特性可以用於熟悉給定領域的個體間的需求交流。以這種方式使用，基於功能特性的方法很可能是最節約的需求收集過程。但是，這些功能特性可能太依賴領域專業知識了，這是許多開發小組都沒有的奢侈品。
用戶情景
用戶情景是寫在索引卡上的簡短描述，如圖 2 所示。
圖 2. 銷售用戶情景的要點
用戶情景包含的信息往往比功能特性包含的信息多，盡管這不是必要條件。“極端編程”方法中，用戶情景要求一個現場的客戶提供部分環境。現場客戶向開發小組描述理想的系統。然後，這個小組一點一點建立系統，給客戶充分的機會定期查看結果。客戶“監督著”這個可交付使用過程，並且在新用戶情景中提出對系統的修改建議。整個環境由現場客戶的反饋和遞增的過程及交付相結合。
用戶情景對於處理軟件不可見性風險最高的項目來說，是最佳的方法。像功能特性一樣，它們都足夠小，能被輕松更改。 因為它們的環境基於運作的系統和客戶，一經實現或不再有效都會被丟棄。但是，並不是每個項目都可以引入現場客戶，因此用戶情景並不適用於每個項目。這種方法因其缺少客戶交互而喪失了它的優勢。
結論
本文討論的每種需求收集過程在恰當的環境中都有其優勢所在。但是，正如這篇討論所示，對於每種環境來說，不是每種需求收集過程都是理想的，它們自身甚至還不是必要的完整。子整體軟件開發的中心在於認識到單個過程或活動本質上的不完整，並且盡可能擴大這些用於減少這種不完整的解決方案的范圍。
模塊性允許兩種目的相同的活動可以互相代替。當用一種需求收集活動代替另一種時，重要的是把需求環境考慮在內。開發周期中途更改活動很可能會引入一組新的動力到項目。如果沒有考慮到環境，這種行動可能會成為災難。但是，仔細的計劃和執行後，引入新活動就能幫助創建新的動力，從而促進了項目的成功。
