需求管理是軟件開發(fā)生命周期的初始階段，它對最終提交的軟件產(chǎn)品的質(zhì)量起著至關重要的作用。一位咨詢師朋友告訴我，在美國，超過60%的軟件項目失敗都是因為不科學的需求管理。另外，80%的項目延誤也源于不斷改變的需求。由此可見，需求管理是整個軟件開發(fā)過程中至關重要的一部分；尤其是對于大型項目，科學的需求管理在降低風險上的作用更是無法估量。

　　軟件開發(fā)實踐表明，讓所有項目成員獲得準確的需求，是進行需求管理的根本；在此基礎上，還應保證所有的需求變更都是在可控制的情況下進行。除需求分析師外，所有其他相關人員，如項目經(jīng)理、開發(fā)組長、QA經(jīng)理等，如能參與到需求評審中，不僅有利于管理需求，還能進一步保證需求與業(yè)務實際更加匹配。對于需求變更，在執(zhí)行之前分析其潛在影響，進行有針對性的人員和資源配置，都將提高需求變更的實現(xiàn)效率。

　　需求管理工具現(xiàn)狀

　　對于市面上的需求管理工具，我主要有以下三方面的看法。首先，目前很多需求管理工具都與開發(fā)過程脫節(jié)。許多時候，開發(fā)工具與需求管理工具必須協(xié)同工作，然而，開發(fā)人員與需求分析師卻不能進行有效的數(shù)據(jù)交流。另外，需求文檔和知識庫的分離，也不利于需求分析師了解各個需求的進展情況，而且限制了高層管理人員對跨部門工作的全局了解。

　　另一方面，有越來越多的企業(yè)，受到諸如塞班斯法等新法規(guī)的影響，不得不開始大范圍使用需求管理工具。這在某種程度上為市場造就了一批針對特定行業(yè)的需求管理軟件。這些軟件多數(shù)適用于對需求有嚴格控制的行業(yè)，如航空航天和軍工行業(yè)等。然而，對于普通行業(yè)市場，企業(yè)更需要的是實用、集成的需求管理解決方案。Forrester最近的一份報告指出，大部分企業(yè)都缺乏成熟的需求收集機制和體系；在這種情況下，即便實施功能強大的工具，企業(yè)也沒有能力來充分利用各種功能和設置，更不用說有效利用這些工具來管理需求了。

　　另外，針對傳統(tǒng)的瀑布式開發(fā)，所有的需求都在開發(fā)開始之前完成。然而，對于目前被廣泛采用的增量或迭代開發(fā)模式，需求常常是由需求制造者和消費者不斷交流所產(chǎn)生的，也是不斷變化的。因此，有效的解決方案必須滿足在類似增量或迭代開發(fā)模式下的需求管理。
集成的、全局的需求管理方法

　　基于對一些成功軟件組織的經(jīng)驗分析，我們認為企業(yè)真正需要的是一款集成的需求管理解決方案，幫助企業(yè)進行可監(jiān)控、可跟蹤、可驗證的需求管理。它需要提供一個框架以供創(chuàng)建新的需求、功能和規(guī)格，并與開發(fā)任務和測試任務相關聯(lián)。需求分析團隊和開發(fā)團隊才能通過這個集成的解決方案協(xié)同工作。

　　這種集成的方案不僅能提高需求管理工具的性價比，也有利于項目團隊的內(nèi)部交流。開發(fā)團隊可以及時獲得需求信息；需求分析師能通過查看需求的進展情況來確定可能會發(fā)生的需求變更；高層管理者也能夠通過查詢和圖表等功能瀏覽開發(fā)項目的進展情況。一款能夠?qū)崿F(xiàn)以上目標的需求管理工具應該具備以下幾點功能：

　　•集成的需求管理：創(chuàng)建、管理、討論并關聯(lián)項目需求和功能;

　　•變更控制：當特定的變更發(fā)生時自動進行需求版本管理，并通過工作流引擎來控制需求變更；

　　•數(shù)字資產(chǎn)管理：需求、功能以及其他重要的數(shù)字資產(chǎn)都需要存儲在一個可靠、可擴展、安全的中央資料庫中；

　　•集成事件跟蹤和測試：需求管理與事件跟蹤和測試管理工具集成，以便于項目經(jīng)理查看與需求相關的開發(fā)和測試工作；

　　•Windows客戶端和Web客戶端：提供Windows客戶端和Web客戶端訪問方式，保證在固定和移動辦公的情況下都能登錄到系統(tǒng)中；

　　•定制化的用戶界面：提供定制選擇，以便于系統(tǒng)管理員創(chuàng)建自定義的需求和功能界面，如字段標簽、字段類型、下拉菜單選項和客戶報告等；

　　•開放的工作流設置：通過定義工作流來創(chuàng)建和管理需求和功能；

　　•嵌入式報表和分析：直接產(chǎn)生需求功能數(shù)據(jù)報表，如變更控制、變更效應、實施和測試數(shù)據(jù)等；

　　•自動獲取需求：在系統(tǒng)中，用戶可以直接輸入需求信息，或者通過文檔形式獲得需求并附加到系統(tǒng)中。

　　在獨立實現(xiàn)以上功能的基礎上，需求管理工具還需與ALM中的開發(fā)過程進行無縫集成，其中包含事件跟蹤、測試管理、以及中央知識庫（如圖1所示）。

　　規(guī)范點驅(qū)動的需求管理

　　誠然，需求管理對整個軟件項目的成敗發(fā)揮著舉足輕重的作用。然而，需求在最初只是客戶或管理人員對產(chǎn)品功能的一種愿望，需求分析師要將這種非結(jié)構化、粗線條、不明確的愿望歸納總結(jié)為具體的規(guī)范點（Specification，簡稱Spec）。產(chǎn)品管理團隊再把各種Spec根據(jù)開發(fā)時間、成本和效益進行優(yōu)先排序，確定Spec單，再由開發(fā)團隊照單實施。

　　SpecDD（Specification Driven Development）是TechExcel根據(jù)多年經(jīng)驗，總結(jié)眾多客戶關于軟件開發(fā)管理的需求而提出的一個概念性框架。SpecDD模型用Spec來表述/定義產(chǎn)品或版本功能，并通過中央知識庫與整個團隊有效共享，使Spec成為貫穿軟件應用生命周期各階段的要素，從而驅(qū)動整個開發(fā)流程。將知識和需求轉(zhuǎn)換為結(jié)構化的、正規(guī)表達的Spec，是將整個開發(fā)過程從宏觀戰(zhàn)略落實到具體實施戰(zhàn)術的過程。

　　SpecDD模型在需求管理上的優(yōu)勢主要體現(xiàn)為以下三個方面。首先，通過SpecDD模型可以實現(xiàn)對需求的度量和評估，包括每個需求所需要的資源和時間，將開發(fā)所需的時間和費用與需求相關聯(lián)，度量和評估需求是否成功，通過需求驗證指標來管理開發(fā)、測試活動。其次，Spec與項目規(guī)劃、開發(fā)和測試任務始終保持關聯(lián)，這就保證了開發(fā)的每一個環(huán)節(jié)都是可追溯。另外，SpecDD模型還能評估需求變更的潛在影響，例如需求變更對開發(fā)和測試工作、項目成本的影響。

　　通常情況下，Spec包含功能、缺陷和功能增強三個部分，他們都來源于相關的知識或需求，并與需求條目和知識庫中的知識條目相關聯(lián)。圖2以Browser 6.0產(chǎn)品為例，用圖形化的方式顯示了Spec與知識、需求的關系。針對Browser產(chǎn)品的最新版本6.0，有安全和用戶界面兩大類需求，通過需求分析師將其分解為新的功能，如支持SSL v.3.0、Tabbed Browsing等；除新功能以外，Spec還包括對之前版本的功能增強，如保存已標記的文件；以及上一版本的缺陷，如保存時響應緩慢。這些Spec通過規(guī)劃、編碼、測試等工作，構成最終交付的產(chǎn)品。

　　同時，Spec也是高度結(jié)構化的，表現(xiàn)為其樹形結(jié)構準確對應產(chǎn)品/版本功能樹，以保證開發(fā)人員不丟失任何需求（如圖3所示）。產(chǎn)品管理團隊通過創(chuàng)建Spec樹，使每個功能/缺陷/功能增強都能對應分支上的樹葉。同時，Spec與知識項目相關聯(lián)，這些知識項目描述了形成此Spec的構思，以及其他相關的文檔、標準、附件和參考項目。

　　需求變更的管理

　　理解需求變更可能產(chǎn)生的效應，并有效的進行控制，對于軟件的最后提交都是至關重要的。無論是變更已有需求，還是增加新的需求，都對項目最終交付的日程造成不同程度的影響。例如，需求變更可能會影響到與之相關的功能、任務和測試工作；編碼延期會延誤與該功能相關的其他開發(fā)任務和測試工作。因此，有效的需求管理工具，必須保證項目團隊能夠很容易的評估這些變更可能帶來的影響。

　　如何在變更發(fā)生之前對其進行評估呢？這就需要將需求管理與所有開發(fā)、測試行為進行集成，用戶就可以通過跟蹤編碼、測試等行為對變更帶來的潛在影響進行評估。這在SpecDD模型中得以實現(xiàn)。

　　將有效的變更轉(zhuǎn)變?yōu)樾枨?/p>

　　如前文所講，SpecDD模型表現(xiàn)為用Spec來表述/定義產(chǎn)品或版本功能，并和整個團隊有效共享，從而驅(qū)動開發(fā)。因此，要保證交付的產(chǎn)品完全符合最終版本的Spec，需求分析部門就要和開發(fā)部門協(xié)同工作，并對變更做出嚴格的控制。對開發(fā)工作有潛在影響的變更都將會被慎重管理，并嚴格檢驗是否影響到需求的依賴關系。所有因需求變更而產(chǎn)生的影響，都必須檢驗變更后的完整性。因此，要實現(xiàn)有效的需求變更，管理工具需要實現(xiàn)以下幾種功能：

　　•變更控制

　　對變更進行嚴格的流程控制，包括請求、復查、討論、調(diào)整和批準等；
?   
　　變更請求由一個獨立的工作流所控制；
?   
　　變更不能對需求造成不良影響，因此在變更被批準之前，需求不能被改變。

　　•實用性
?   
　　接近實際的需求管理實踐；
?   
　　易于被客戶理解；
?   
　　易于對重要的變更進行跟蹤。

　　•各部門協(xié)同工作
?   
　　需求、功能和開發(fā)等各方面的人員都在各個階段參與變更請求，將不同部門的人員都納入變更管理體系；
?   
　　讓開發(fā)團隊參與到變更請求的批準過程中，這樣會比被動的接受或拒絕變更要更科學、更有效；
?   
　　在變更得到批準或拒絕之前，分析針對該變更在資源和時間上的分配。

　　科學有效的需求管理是軟件項目成功的保證。在更新需求的過程中，讓項目的所有相關人員從各自的角色出發(fā)，都參與其中，將促進軟件產(chǎn)品最終達到業(yè)務目標。需求變更時，對其進行準確的分析和評估，也有助于確保項目按時提交。

　　除需求管理工具獨立工作以外，將它與應用生命周期管理（ALM）中的其他過程管理工具集成，才能最終提供一個完整的貫穿需求和開發(fā)過程的解決方案。需求分析人員和開發(fā)團隊通過一個平臺實現(xiàn)協(xié)同工作，統(tǒng)一接口和共用流程。這就能促進需求數(shù)據(jù)在需求制造者和實施者之間無縫、實時的傳遞，并保證在開發(fā)的每一個環(huán)節(jié)都可追溯需求。

　　如前文所講，SpecDD模型表現(xiàn)為用Spec來表述/定義產(chǎn)品或版本功能，并和整個團隊有效共享，從而驅(qū)動開發(fā)。因此，要保證交付的產(chǎn)品完全符合最終版本的Spec，需求分析部門就要和開發(fā)部門協(xié)同工作，并對變更做出嚴格的控制。對開發(fā)工作有潛在影響的變更都將會被慎重管理，并嚴格檢驗是否影響到需求的依賴關系。所有因需求變更而產(chǎn)生的影響，都必須檢驗變更后的完整性。因此，要實現(xiàn)有效的需求變更，管理工具需要實現(xiàn)以下幾種功能：

　　•變更控制
?   
　　對變更進行嚴格的流程控制，包括請求、復查、討論、調(diào)整和批準等；
?   
　　變更請求由一個獨立的工作流所控制；

　　變更不能對需求造成不良影響，因此在變更被批準之前，需求不能被改變。
　　•實用性
?   
　　接近實際的需求管理實踐；
?   
　　易于被客戶理解；
?   
　　易于對重要的變更進行跟蹤。

　　•各部門協(xié)同工作
?   
　　需求、功能和開發(fā)等各方面的人員都在各個階段參與變更請求，將不同部門的人員都納入變更管理體系；
?   
　　讓開發(fā)團隊參與到變更請求的批準過程中，這樣會比被動的接受或拒絕變更要更科學、更有效；
?   
　　在變更得到批準或拒絕之前，分析針對該變更在資源和時間上的分配。

　　科學有效的需求管理是軟件項目成功的保證。在更新需求的過程中，讓項目的所有相關人員從各自的角色出發(fā)，都參與其中，將促進軟件產(chǎn)品最終達到業(yè)務目標。需求變更時，對其進行準確的分析和評估，也有助于確保項目按時提交。

　　除需求管理工具獨立工作以外，將它與應用生命周期管理（ALM）中的其他過程管理工具集成，才能最終提供一個完整的貫穿需求和開發(fā)過程的解決方案。需求分析人員和開發(fā)團隊通過一個平臺實現(xiàn)協(xié)同工作，統(tǒng)一接口和共用流程。這就能促進需求數(shù)據(jù)在需求制造者和實施者之間無縫、實時的傳遞，并保證在開發(fā)的每一個環(huán)節(jié)都可追溯需求。