需求收集真正的體現了需求的市場和用戶驅動。訪談，調查表，頭腦風暴，競爭對手和產品分析都是需求收集的方法。需求收集我們需要搞清楚用戶真正的需求，問題背后的深層次問題，這樣才可能為挖掘需求提供數據。需求收集的過程應該流程化，收集的需求應該分類入庫的歸檔化。必須將需求收集活動看做為一個結構化的流程或過程，以真正的促進收集的過程和采集的數據的有效性。
收集的需求在論證分析中應該確定優先級，而優先級的確認應該引入價值工程，即我們應該認識到一個需求的重要性應該體現到它對產品價值的短期和長期的增值上面。要理解這個，就必須要考慮收集的需求是普遍需求還是特殊需求，是核心業務對應需求還是輔助業務對應需求，是使用頻率高的需求還是偶爾使用的功能點需求。我們必須有清晰的頭腦來分析用戶急的是否就一定是優先級高的需求。
用戶往往習慣了給我們提希望系統實現什么功能，這些需求往往是用戶已經轉換后的需求而不是原始需求。當用戶遇到業務上的問題的時候他們往往假設了一種實現方式，如果在需求收集過程中錯誤的把問題的解當做需求，則我們就忽略掉了真正的原始需求。需求收集的重點應該在用戶真正面臨的問題域和問題場景的收集。
需求收集人員的業務背景和經驗往往對需求收集有效性有很大的影響。需求收集的訪談過程不是簡單的聽用戶如何講，而是需求我們去引導用戶講出他們真正面臨的問題。通過我們積極的溝通讓用戶把他們真實的想法真正的表達出來。
需求收集是整個軟件產品開發的源頭，是確定產品方向和定位的重要活動。需求收集活動出現大的誤差將是方向性的重大錯誤。如果我們開發出來的產品不能真正滿足用戶的需要和得到用戶的認可，那產品本身就不可能創造價值，及時這個產品有很好的質量，易用性和功能等，這個產品仍然是失敗的。
需求分析和開發
需求分析工作需要意識到是包含了業務分析和系統分析兩部分內容。對于業務分析包括了業務流程分析，組織結構和崗位角色分析，以外的對象分析，數據流分析，重點是描述現在。系統分析的內容重點是將需求轉換為系統可實現的軟件需求，因此必須要考慮到需求的可實現性，如果對于面向對象分析則重點在用例分析，業務對象建模，業務規則分析。系統分析最好是有軟件開發經驗的人和業務背景的人進行，這里的一個重點就是要把軟件開發中已經成熟的分析模式和模型和實際的業務進行匹配。
軟件產品要能夠適應需求的變化，不僅僅是軟件架構上的可擴展性考慮，更重要的是在需求分析階段就需要考慮軟件需求如何適應用戶需求的變化。對應用戶經常可能變動的需求點進行抽象，引入一些標準的可配置的模型，如權限模型，工作流模型等。軟件需求對業務需求和用戶需求的一個處理要點就是會考慮到哪些經常變化的需求需要轉換為靈活的可配置的需求。
用戶都不清楚自己要什么或者說用戶的需求經常變動更應該促進我們去改進需求分析和開發的過程。在這個時候系統分析員的開發經驗和業務背景將起到很重要的作用。需求的一種變更對于軟件開發往往是一種必然的情況，只是如何把它變更的范圍控制住，如何實現需求的變更不是要修改設計和編碼，而是通過靈活的配置來實現的。
收集來的用戶需求如何轉換為需求規格說明書，中間的一個重要過程就是需求分析和開發。這樣正好體系一些需求分析工作的重點內容，通過識別需求的優先級以更好的安排項目資源和進度，有的放矢。通過對原始需求的分類，合并，抽象以提取通用的需求模型。通過識別非功能性需求以增加整個系統的健壯性，性能和易用性。通過對需求模塊單元的劃分，流程和規則的描述，功能點分析為項目進度計劃安排和進度跟蹤創造條件。因此我們將需求分析是一種業務和系統的模式匹配，如果才能夠匹配好就是需求分析的責任。
需求管理
應該首先看到需求管理的目的首先為項目管理服務，結構化的需求管理使項目管理真正做到可視化，另外需求管理為用戶服務，通過有效的需求管理能夠更好的滿足用戶的需求，提升用戶滿意度。最后需求管理為后續項目提供支持數據和依據，因為需求管理的內容是結構化和文檔化的，這些是內容是項目重要的過程資產。
要管理需求，則我們的需求必須是結構化和文檔化的，否則就談不上需求管理。因此需求管理必然會涉及到配置管理相關工作。同時為了量化的說明需求管理的有效性，我們的需求本身又必須是可度量的，需求功能點的粒度應該在一定范圍內。需求規格說明書是需求管理的重要對象，必須文檔化，而且會在整個軟件開發生命周期中被多次使用到。
需求全生命周期的管理的一個重點就是需求的狀態管理，用戶提出來的需求就是是否實現了，現在處在哪個環節都需要依靠需求的狀態管理和跟蹤來實現。因此需求分析階段需求功能點的條目化就是需求狀態管理的一個重點，而需求狀態跟蹤的過程正好就是我們對項目進度和狀態的跟蹤過程。如果項目管理的狀態監控的好，則需求狀態管理也可以做好，同時拆分后的需求狀態管理為我們增量和迭代開發提供了基礎，有了這個才可能真正做好項目掙值管理，才可以更好的應用掙值中的0-100原則。
需求的變更控制重要性體現在真正的使甲乙雙方對范圍的承諾有共同的重視。當有了共同基準依據的時候才能夠真正的體現用戶滿意度上面，同時需求變更真正的體現出項目計劃的嚴肅性，保證項目計劃的受控和嚴格執行。需求老發生變動，項目老延期都是需求變更沒有做好的一種表現形式。對于已經開發完成的軟件產品，我們更需要有結構化的需求變更流程，將變更的影響分析影響植入到流程中，這樣才可以保證整個軟件產品的穩定性。
