在軟件項目的開發過程中，需求管理貫穿了軟件項目的整個生命周期，在軟件項目管理中需求工程是軟件開發的第一步，是關鍵的一步，也是最難把握的一步。需求管理做得好壞直接影響到軟件的質量，甚至軟件項目的成敗。從軟件的項目立項、研發、維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業的新動態，都為軟件帶來不斷完善功能、優化性能、提高用戶友好性的要求。
在項目管理過程中，項目經理經常面對用戶的需求變更，如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，項目研發人員的士氣將越來越低落，將直接導致項目成本增加、質量下降及項目交付日期推后。這就決定了項目組必須擁有需求管理策略和有效的落地。
讓我們一起來回顧一下實際研發過程中，通常會面臨到的需求管理挑戰：
1、缺乏需求的集中管理
按照需求工程的說法，在進入開發環節之前，開發團隊和客戶之間需要形成一份完整的需求規格說明書，詳細地說明目標軟件的各種需求，這其中包括功能性需求、非功能性需求和其他各種約束。在典型的瀑布模型中，需求規格說明書是在需求分析階段完成的。然而，由于軟件外部環境的變化，很少有哪個項目在需求分析階段就能將所有可能的需求準確無誤地包含進來，并且在開發階段不需要修改，一句話，需求的變更是不可避免的。需求的變更也需要及時地反應到需求管理中。
除此之外，在實際的敏捷軟件開發中，對開發而言，需求的來源不一定像瀑布模型那樣完善的需求規格說明書，而通常有以下幾種：
1）客戶初始的業務需求：很多客戶可能只會告訴我們，它想做一個系統或者工具平臺，大致是什么樣子，應該具備哪些功能，但這種需求往往比較抽象，缺乏細致的分析。這種需求可能源自于一次交談，或者一封Email，形式上并不正式。
2）客戶對項目快速原型的反饋意見：對于需求，在實際項目開發中，客戶關注的業務功能，項目經理關注的是抽象設計，而開發人員關注的卻是具體實現。在項目初期，客戶往往也不是很清楚他們要什么，或者理想中的產品到底最后會是什么樣的，界面布局，操作流程等等。這一點，在新產品的開發中尤為明顯。
這時候，就需要開發團隊能夠按照現有的理解快速地開發一個原型，作為開發團隊和客戶討論和分析需求的共同基礎，原型能夠幫助用戶更好地發掘和定義需求。客戶對于原型的論證作為反饋意見也可以使開發團隊更加直觀和感性地認識客戶的需求。
3）客戶對每個迭代周期發布的版本的修改建議
如果該企業采用的是敏捷開發，每個迭代周期都要發布一個可用的版本給客戶，該版本盡可能多地實現了當前迭代周期內的需求以及之前迭代周期內遺留下來的需求。客戶要驗證需求的實現是否符合他們的要求，并提出修改意見和建議。
4）客戶在研發周期中的需求變更
需求來源的特殊性決定了軟件開發過程中需求管理的特殊性，尤其是對于一個同時承擔數個小項目的開發團隊而言，不同的項目需求是由不同的開發人員或QA分別進行管理和跟蹤的，缺乏集中的管理，對于需求的跟蹤也比較原始。往往是手工整理需求郵件和需求列表，然后形成簡單的需求文檔，在需求查詢和狀態維護方面存在明顯不足。
2、需求變更頻繁
軟件開發的顯著特點之一就是靈活性、機動性、對變化的快速響應能力。尤其是敏捷開發過程，需求變更更為頻繁。敏捷開發的口號是擁抱需求變化，也就是說，開發團隊對于客戶提出的需求變更通常是抱以歡迎的態度，盡管這些變更可能會給項目計劃和項目進度帶來麻煩，但這種觀念上的轉變更能體現開發團隊和客戶之間合作的誠意。
客戶在迭代周期中的變更大致可以分為五種類型：添加新需求、刪除本次迭代周期內的需求、刪除之前迭代周期內的需求、更改本次迭代周期內的需求、更改之前迭代周期內的需求。這就是說，開發團隊需要實時高效地管理這些變更，并且將需求變更涉及到的迭代周期內項目計劃和人員安排變更的影響最小化。
3、缺乏有針對性的需求管理流程
傳統的需求管理過程，尤其是其中的變更控制過程是針對那些組織機構清晰，只能定義明確的傳統軟件項目，其流程相對比較嚴謹和死板。同時，為了彌補需求變更對項目進程帶來的影響，開發人員常常需要快速的進行功能修改和增加，而沒有遵循統一的流程控制，從而常常使得軟件開發的有序性被破壞，人為地增加了工作量。這就需要有更為高效和精簡的需求管理過程以及相應的工具支持。
4、需求、測試用例、Bug管理脫節
軟件開發中，需求和測試用例是緊密聯系的，通常來說，一條需求只有通過了所有針對該需求的測試之后才能說這條需求的實現真正實現了。而測試的結果是產生Bug報告，如果針對某條需求的一個測試用例沒有通過測試，換句話說，也就是產生了一個Bug，這就說明該需求根本沒有完成。同時，需求的變更直接影響到與該需求相關的測試用例的更新，繼而影響到現有Bug的狀態的更新。然而現實情況卻是，大多數敏捷開發團隊都沒有實現需求、測試用例和Bug的一體化管理。
我們希望在需求、測試用例和Bug之間建立一種動態的聯系，能夠實時地更新三者的狀態，并且實現三者之間狀態的動態聯動，從而減少開發團隊在管理和維護需求、測試用例和Bug時的工作量。
5、缺乏量化的項目管理反饋
企業在項目管理中，需求的頻繁變更對項目管理者評估需求、制定迭代周期內的項目計劃都是個巨大的挑戰。管理者在需求評估經驗和能力上的不足，以及管理者對團隊成員開發能力認識不足容易造成需求評估出現大的誤差，雖然這種誤差是不可避免的、但是我們希望可以通過歷史評估數據的反饋來幫助項目管理者積累經驗，逐步修正和調整自己的判斷和評價體系，從而盡可能減小由于評估誤差引起的項目風險。而沒有工具的支持，歷史的準確數據則很難獲取。
總結以上問題，顯而易見，需求管理是軟件項目中一項十分重要的工作，據調查顯示在眾多失敗的軟件項目中，由于需求原因導致的約占到45%，因此有效的需求管理是企業軟件開發項目順利達成目標的重要支撐條件。如何理解項目開發的目的和用途，梳理用戶需求，監控需求變化，進行需求確認，對需求風險進行防范，并利用工具進行有效的實施需求管理工具，方能推進軟件項目良性發展，達到用戶與軟件開發企業的雙贏。
有效的需求管理方法與工具
方法一：量化需求管理
如前所述，企業研發項目通常規模巨大，涉及部門眾多，需求功能描述文件中包含眾多內容，若僅僅只用整篇的文檔來指導開發和測試工作，很容易引起任務分配的混亂；當發生需求變更時，也很難追溯歷史版本。
TechExcel公司推出的DevSuite產品研發管理軟件，從實踐中提煉出一個行之有效的解決方法——用規范點（Specification，以下簡稱Spec）量化需求，正規表達每一個功能單元。只需打開《需求功能描述書》的WORD文檔，就可以利用插件，將其中的功能單元逐條地復制出來，在需求管理系統 DevSpec中直接生成Spec。相對于需求，Spec是更面向技術人員的語言。
客戶業務需求可以在平臺中進行集中管理，并以需求結構化和條目化的形式管理需求，為需求的評估、追蹤與變更管理提供了基礎。同時，通過系統強大的頁面自定義能力，我們可以管理需求的來源、難度、實現時間、實現成本等，這些信息為需求優先級的評估，提供了量化的指標，幫助項目經理準確的排布需求優先級，讓團隊優先實現最重要、最緊急、客戶價值最高的需求。
此外，需求說明書、分析設計文檔、評審記錄等，均可以以附件形式保存，且能對文檔的版本進行有效的管理。
方法二：有序管理需求變更
在實際項目中，實現需求變更的成本隨著開發進度呈指數級增長。需求變更的流程化管理能保障正常的開發進度，將變更及時反應到開發和測試等部門。
以下描述的是一個典型過程（如圖1）。一項變更請求在需求管理系統中被提交后，與之關聯的各個部門，如市場、項目管理、產品研發、QA、測試等，都會有相關人員接到系統通知而介入。他們將組成評估團隊，根據實施難度、周期、費用、對其他機制的影響等指標，對該變更進行全面考察和評估。
DevSpec提供了專門的變更管理視圖，在這里，我們可以管理各個項目中的需求變更任務，不論是需求增加、減少或是改變，我們都會為之建立一條變更記錄，在這條變更記錄中，記錄了變更的來源、原因、具體描述和變更成本、收益估算，這些信息可以成為變更評估的標準與依據。
每個變更任務均可以和在變更中受影響的需求相關聯，包括增加的、減少的和變更的需求。通過需求變更列表，我們可以清晰的看到項目中當前有多少變更任務，影響了哪些需求，也能夠察看到整個項目周期中總計發生了多少變更，總計影響了多少需求條目。
方法三：標準的需求管理流程
需求管理的整個過程都可以用標準、有效的工作流控制起來，如需求變更流程的設定，通常包括請求、復查、討論、調整、批準和拒絕等狀態，只有具備權限的項目成員才能改變狀態。按照預設的流程，各方審批全部通過后，該變更才能被接受。
DevSuite提供了靈活的工作流程定制和管理能力，圖形化工作流引擎將工作流圖形轉變為工作流腳本，因此項目管理員可以在圖形化界面中，輕松快速的定制項目組項目管理流程。
如上圖中紅色框內為需求的工作流程，用戶可以根據公司的實際業務流程，定制符合需要的需求流程圖，系統可以同時定義多條項目工作流程，以適應不同規模、不同類型的項目。
方法四：需求有效驅動開發與測試
在理想的研發管理平臺中，需求管理與所有規劃、開發、測試管理過程相集成。因此，需求的正規表達Spec，以及圍繞Spec正在或將要進行的開發任務和測試任務，都能被納入綜合考慮的范疇，便于評估團隊估算該變更造成的“牽一發而動全身”的潛在影響。有時，還要結合商業需求進行考量，為了趕上產品的最佳發布時機，有些變更將被拒絕。
變更請求被批準后，與之相關聯的開發、測試任務都會在系統中被一一標記出來，以提醒程序和測試部門的相關負責人，引發這些任務的需求已經變更，請他們做出相應的調整處理。在系統中跟蹤這些任務的進展，可以實時掌握該變更的落實情況。變更完成后，也可以核算它對開發周期和費用的實際影響，與評估時的預測相對比，找出差異的原因，為將來更準確地評估提供參考。
DevSuite提供了變更標識功能，通過變更標識子任務，我們可以選擇受影響的開發、測試任務，建立變更標識子任務，該子任務將以旗幟形式反映到開發、測試任務中。變更標識子任務不但能夠標識變更，還能夠幫助團隊進行變更反饋，通過文字記錄和狀態改變，任務負責人員可以將需求變更對于任務的影響及時回饋給需求管理人員。另外，對于需求實際改變的內容，需求負責人員可以創建變更推送子任務，通過郵件系統，可以將變更信息發送給該需求的干系人。
方法五：需求指導項目規劃與執行
縱使項目最初都有比較全面的計劃，延期仍然會時常發生，即便是在管理機制比較成熟的大型研發企業中，跳票也不可避免。通常情況下，導致跳票主要有以下幾點原因：功能設計規劃過多，很多又無法刪除，如不增加開發時間，產品幾乎不能完成；缺乏有經驗的管理或開發人員，不能準確估計工作量；任務執行缺乏規范，開發人員隨意更改功能設計，影響整體進度；過高的人員流動率，導致知識的流失，任務不能及時跟進。
針對以上問題，只要從量化需求入手， 有序管理需求變更，用正規表達、可量化的Spec來指導項目規劃、編程和測試，就能把風險降到最低。
基于結構化的Spec集合，可以將項目分解為多個子項目，將Spec直接分配到各自對應的子項目中，以此來規劃和估算子項目的工作量。項目管理人員為每個子項目分配資源，安排優先順序，確定項目里程碑。
在項目執行時，可以為每一個Spec產生出一系列開發任務。自定義的工作流機制確保每一個任務從提交到最終解決的生命周期都嚴格符合業務流程，保證任何時刻都有唯一的負責人、狀態和截止日期。這樣，不僅能規范產品研發過程，還能降低人員流動帶來的風險。任務的流轉及相關知識文檔，如源代碼、設計資源等，都得到系統完整的記錄，還能與任務關聯，便于追溯。一旦有人離開項目，接替的人員能夠查看任務和文檔信息，迅速彌補人員空缺。
DevSuite需求管理視圖提供產品版本樹管理，產品經理可以創建新產品和版本，每個需求和功能點可以在多個產品和版本實現。通常一個產品的各個功能可能會分布在不同的項目中實現，項目經理如何在產品發布的時候知道每次發布實現了那些功能，各個功能點的負責人是誰，通過DevSpec視圖提供的產品版本樹功能，項目經理可以輕松的過濾出每個發布版本實現了那些客戶需求。
支持產品的版本規劃，當收集到的需求經過評審等規定流程決策后，將需求與規劃好的產品版本關聯起來，通過產品版本視圖可以直接追蹤到需求與產品版本的關系，未決定開發的需求可以不設定版本，等決定后再關聯相應產品版本。
以上所述的需求管理經驗和系統工具的支持，希望與大家共同分享與探討，探索出一條以有效的需求管理推動項目執行、產品研發整個生命周期的最佳途徑！