需求收集真正的體現了需求的市場和使用者驅動。訪談，調查表，頭腦風暴，競爭對手和產品分析都是需求收集的方法。需求收集我們需要搞清楚使用者真正的需求，問題背後的深層次問題，這樣才可能為挖掘需求提供資料。需求收集的過程應該流程化，收集的需求應該分類入庫的歸檔化。必須將需求收集活動看做為一個結構化的流程或過程，以真正的促進收集的過程和採集的資料的有效性。

收集的需求在論證分析中應該確定優先順序，而優先順序的確認應該引入價值工程，即我們應該認識到一個需求的重要性應該體現到它對產品價值的短期和長期的增值上面。要理解這個，就必須要考慮收集的需求是普遍需求還是特殊需求，是核心業務對應需求還是輔助業務對應需求，是使用頻率高的需求還是偶爾使用的功能點需求。我們必須有清晰的頭腦來分析使用者急的是否就一定是優先順序高的需求。

使用者往往習慣了給我們提希望系統實現什麼功能，這些需求往往是使用者已經轉換後的需求而不是原始需求。當用戶遇到業務上的問題的時候他們往往假設了一種實現方式，如果在需求收集過程中錯誤的把問題的解當做需求，則我們就忽略掉了真正的原始需求。需求收集的重點應該在使用者真正面臨的問題域和問題場景的收集。

需求收集人員的業務背景和經驗往往對需求收集有效性有很大的影響。需求收集的訪談過程不是簡單的聽使用者如何講，而是需求我們去引導使用者講出他們真正面臨的問題。通過我們積極的溝通讓使用者把他們真實的想法真正的表達出來。

需求收集是整個軟體產品開發的源頭，是確定產品方向和定位的重要活動。需求收集活動出現大的誤差將是方向性的重大錯誤。如果我們開發出來的產品不能真正滿足使用者的需要和得到使用者的認可，那產品本身就不可能創造價值，及時這個產品有很好的質量，易用性和功能等，這個產品仍然是失敗的。

需求分析和開發

需求分析工作需要意識到是包含了業務分析和系統分析兩部分內容。對於業務分析包括了業務流程分析，組織結構和崗位角色分析，以外的物件分析，資料流分析，重點是描述現在。系統分析的內容重點是將需求轉換為系統可實現的軟體需求，因此必須要考慮到需求的可實現性，如果對於面向物件分析則重點在用例分析，業務物件建模，業務規則分析。系統分析最好是有軟體開發經驗的人和業務背景的人進行，這裡的一個重點就是要把軟體開發中已經成熟的分析模式和模型和實際的業務進行匹配。

軟體產品要能夠適應需求的變化，不僅僅是軟體架構上的可擴充套件性考慮，更重要的是在需求分析階段就需要考慮軟體需求如何適應使用者需求的變化。對應使用者經常可能變動的需求點進行抽象，引入一些標準的可配置的模型，如許可權模型，工作流模型等。軟體需求對業務需求和使用者需求的一個處理要點就是會考慮到哪些經常變化的需求需要轉換為靈活的可配置的需求。

使用者都不清楚自己要什麼或者說使用者的需求經常變動更應該促進我們去改進需求分析和開發的過程。在這個時候系統分析員的開發經驗和業務背景將起到很重要的作用。需求的一種變更對於軟體開發往往是一種必然的情況，只是如何把它變更的範圍控制住，如何實現需求的變更不是要修改設計和編碼，而是通過靈活的配置來實現的。

收集來的使用者需求如何轉換為需求規格說明書，中間的一個重要過程就是需求分析和開發。這樣正好體系一些需求分析工作的重點內容，通過識別需求的優先順序以更好的安排專案資源和進度，有的放矢。通過對原始需求的分類，合併，抽象以提取通用的需求模型。通過識別非功能性需求以增加整個系統的健壯性，效能和易用性。通過對需求模組單元的劃分，流程和規則的描述，功能點分析為專案進度計劃安排和進度跟蹤創造條件。因此我們將需求分析是一種業務和系統的模式匹配，如果才能夠匹配好就是需求分析的責任。

需求管理

應該首先看到需求管理的目的首先為專案管理服務，結構化的需求管理使專案管理真正做到視覺化，另外需求管理為使用者服務，通過有效的需求管理能夠更好的滿足使用者的需求，提升使用者滿意度。最後需求管理為後續專案提供支援資料和依據，因為需求管理的內容是結構化和文件化的，這些是內容是專案重要的過程資產。

要管理需求，則我們的需求必須是結構化和文件化的，否則就談不上需求管理。因此需求管理必然會涉及到配置管理相關工作。同時為了量化的說明需求管理的有效性，我們的需求本身又必須是可度量的，需求功能點的粒度應該在一定範圍內。需求規格說明書是需求管理的重要物件，必須文件化，而且會在整個軟體開發生命週期中被多次使用到。

需求全生命週期的管理的一個重點就是需求的狀態管理，使用者提出來的需求就是是否實現了，現在處在哪個環節都需要依靠需求的狀態管理和跟蹤來實現。因此需求分析階段需求功能點的條目化就是需求狀態管理的一個重點，而需求狀態跟蹤的過程正好就是我們對專案進度和狀態的跟蹤過程。如果專案管理的狀態監控的好，則需求狀態管理也可以做好，同時拆分後的需求狀態管理為我們增量和迭代開發提供了基礎，有了這個才可能真正做好專案掙值管理，才可以更好的應用掙值中的0-100原則。

需求的變更控制重要性體現在真正的使甲乙雙方對範圍的承諾有共同的重視。當有了共同基準依據的時候才能夠真正的體現使用者滿意度上面，同時需求變更真正的體現出專案計劃的嚴肅性，保證專案計劃的受控和嚴格執行。需求老發生變動，專案老延期都是需求變更沒有做好的一種表現形式。對於已經開發完成的軟體產品，我們更需要有結構化的需求變更流程，將變更的影響分析影響植入到流程中，這樣才可以保證整個軟體產品的穩定性。

本文摘自PM圈子網—專案管理牛人聚集地 轉載請註明原文連結http://www.pmleader.cn/index.php?m=content&c=index&a=show&catid=6&id=500358