一. 制定需求管理計劃
需求管理計劃對于需求管理工作的成功實施，起著重要作用。因此在項目啟動后，我通過如下步驟，完成制定需求管理計劃工作。
1. 與相關人溝通，梳理并明確需求管理工作內容。包括如何組織項目組人員獲取用戶需求的方式、需求變更控制流程、需求跟蹤頻度及觸發時機等。
2. 明確需求管理涉及的干系人、角色及職責。因需求管理涉及到干系人較多，為避免需求缺乏一個統一的入口及出口。在本項目中，在需求基線建立后,我們要求客戶方安排一名的需求接口人，我方也安排一名需求接口人。后期的客戶需求均由客戶接口人收集并整理后發給我方需求接口人.
3. 明確需求管理采用的平臺，如需求管理工具等。在本項目中，我們在用需求跟蹤矩陣表實現需求雙向跟蹤管理。采用svn作為需求變更管理工具。理
4. 編寫需求管理計劃。在本項目里，采用公司CMMI體系的需求管理計劃模板，進行計劃的編寫。重點描述了上述內容。完成了需求管理計劃編寫后，由項目經理、各小組組長、QA共同對該需求管理計劃進行評審.
在本項目中對需求獲取的活動過程做以下描述:我與2010年3月下旬組建了需求調研分析小組，包括我在內共8人，其中客戶方業務人員3人，本項目組5人，我起草了訪談人員列表計劃，需求調研問卷。通過早組內談論將客戶方的用戶類型分為主管業務的領導，業務精通的用戶、以及普通用戶三類。對業務領導我們采取個別約談的方式，調研重點是調研項目的總體要求和非功能性要求，對重點核心的業務需求也進行了調研。對業務精通的重點用戶采取了座談會的形式，以討論的形式誘導用戶提出需求。對普通用戶采取調研問卷的形式進行調研。對收集到的用戶需求記錄進行匯總。將匯總資料通過svn版本控制軟件分發給需求分析組的組員，讓組員做進一步的分析和整理。根據用戶的原始需求和公司指定的SRS模板編寫了需求規格說明書的初稿，經過反復的與客戶方的用戶進行需求調研，整理分析，對需求規格說明書內容做必要的修改和增加。與2010年4月底形成了正式的需求規格說明書。2010年5月初我組織了分析人員，設計人員、和測試人員、客戶方參與的用戶評審和同行需求評審。評審通過后，最后應ppt文件的形式和客戶進行需求確認并簽字。通過配置管理員發布需求基線。
二.需求變更管理
隨著軟件技術的復雜化，架構的多樣化，業務的靈活化，以及隨著客戶對所需系統目標及需求的清晰化，變更時不可避免的。會對項目的質量，成本、進度等產生影響,因此需求變更管理在整個項目的需求管理工作中顯得尤其重要.一旦項目的需求基線建立，對需求版本控制管理及極為重要。
在本項目中我們采用如下需求變更管理流程。
1. 首先是客戶需求接口人提出需求變更申請清單（記錄需求變更項），我方需求接口人接收到該需求變更，并將需求變更申請單轉發給項目技術負責人
2. 項目技術負責人接收到需求變更，對該變更進行技術評估，如果技術上可行，進入下一節點；否則給出相關的技術解答，也同樣進入下一節點。
3. 項目經理接收到技術分析通過的需求變更，進行資源分析、進度分析等，分析通過的需求變更項，進入CCB審核環節。對于技術負責人分析不通過的需求變更，項目經理經過確認后，結束來流程，處于駁回關閉狀態。針對這部分需求變更，需求接口人將給客戶予以答復。
4. 對于項目經理審核通過的需求變更，CCB安排人員進行復核，復核通過后，該需求變更將由后續的實施人員（如開發修改代碼、需求人員修改需求文檔等）進行實施，并安排相關人進行驗證。因實施及驗證不屬于需求變更管理流程，故這里不贅述。
通過上述手段，本項目保證了所有的需求變更都有據可依，同時，也通過該完整的需求管理過程，為后續的需求跟蹤及相關的測試提供了信息保障。
三.需求跟蹤
在實際項目開展中，經常會發生這樣的情況。測試人員在進行測試時，發現某些需求未實現，或者客戶UAT（用戶接收測試）時，發現某些功能點未測試全。諸如此類的問題，很大一部分原因是由于需求雙向跟蹤未做好。
本項目需求雙向跟蹤，包括從用戶原始需求到系統需求、設計、編碼、測試用例等之間的雙向跟蹤。如下圖所示：
| 用戶需求 | 系統需求 | 概設 | 詳設 | 源碼 | 測試用例 | …… | 最終產品 |
| 1.1 | 1.1.1 | P3 1.1.1 | P4 1.1.1 | XX.java | TC01 | …… | 功能點1 |
雙向跟蹤包括：
l 正向跟蹤：從需求到設計、源碼、測試用例的過程，用于明確是否所有需求都被設計了、被編碼了，被測試了等。一旦某個需求需要變更，就可以快速找到所有影響的范圍。
l 反向跟蹤：從缺陷到測試用例、源碼、設計、需求的過程，用于明確所有的工作成果都是有對應的需求，避免測試多余、設計多余的情況發生。同時，一旦某項設計因多種原因發現需要變更，也可快速找到對應的需求，以便快速確認相應的需求是否需要變更。