軟體開發最獨特的難點在於其「不可見性」。Fredrick Brooks 指出，與硬體等具體領域不同，軟體系統本質上是思維的產物，缺乏物質表現形式。我們只能觀察軟體運行的效果，無法直接看到系統結構本身。這正是我們依賴軟體模型的原因——模型賦予軟體物理維度，使團隊能理解並溝通系統的架構與行為。
需求收集是所有軟體建模工作的核心。所謂「需求環境」，是指專案所處的具體脈絡：業務領域知識、團隊經驗、技術限制等。這個環境決定了哪種需求收集流程最有效。準確識別需求環境，是應對軟體不可見性的關鍵第一步。
需求收集流程的選擇深遠影響專案成敗。作為開發週期的基石，無效的流程會大幅增加失敗風險。本文分析三大主流方法論中的需求收集精華：
SRS 採用「解決方案空間」思維：定義系統「應該」做什麼，而非「如何」做。優點是給予開發團隊極大實現彈性；缺點是高度依賴團隊的領域專業知識。最適用於：領域成熟、團隊資深、變更較少的專案。
用例描述用戶與系統互動的動作序列，本質上是「路徑導向」。它捕捉達成特定目標的所有可能路徑（含例外流程）。優勢在於溝通清晰，但同樣適合領域已被充分理解的情境。變更適應力較弱。
FDD 將需求分解為「功能特性」，格式為：「動詞 + 結果 + 物件」（如：預測季度銷售總額）。每個特性在 2 週內可完成。配合「功能集」與「領域中立組件」建模，極利於變更管理與進度追蹤。適合：團隊具備領域知識、需頻繁交付增量的專案。
XP 的用戶故事寫在索引卡上，極其精簡。其真正威力來自「現場客戶」與「遞增交付」形成的反饋閉環。這是應對高不可見性、高風險專案的最佳選擇，但前提是能獲得真實用戶的持續參與。
沒有銀彈。每種流程在特定環境下都有優勢。成熟的開發組織應具備：
需求收集的本質，是在不可見的思維構建與可見的業務價值之間，搭建最適配的溝通橋樑。
