以知識為核心的ALM之需求管理篇

1、以知識為核心的ALM之需求管理 篇需求管理是軟件開發(fā)生命周期的初始階段，它對最終提交的軟件產品的質量起著至關重要的作用。一位咨詢師朋友 告訴我，在美國，超過60%的軟件工程失敗都是因為不科學的 需求管理。另外，80%的工程延誤也源于不斷改變的需求。由 此可見，需求管理是整個軟件開發(fā)過程中至關重要的一部 分；尤其是對于大型工程，科學的需求管理在降低風險上的 作用更是無法估量。軟件開發(fā)實踐說明，讓所有工程成員獲得準確的需求， 是進行需求管理的根本；在此基礎上，還應保證所有的需求 變更都是在可控制的情況下進行。除需求分析師外，所有其 他相關人員，如工程經理、開發(fā)組長、QA經理等，如能參與 到需求評審

2、中，不僅有利于管理需求，還能進一步保證需求 與業(yè)務實際更加匹配。對于需求變更，在執(zhí)行之前分析其潛 在影響，進行有針對性的人員和資源配置，都將提高需求變 更的實現(xiàn)效率。需求管理工具現(xiàn)狀對于市面上的需求管理工具，我有以下三點看法。首先， 目前很多需求管理工具與開發(fā)過程脫節(jié)。很多時候，開發(fā)工 具和需求管理工具必須協(xié)同工作，但是開發(fā)人員和需求分析 師不能有效地溝通數(shù)據。此外，需求文檔和知識庫的別離不 利于需求分析師了解每個需求的進展，也限制了高層管理者 對跨部門工作的整體了解。另一方面，有越來越多的企業(yè)，受到諸如塞班斯法等新法規(guī)的影響，不得不開始大范圍使用需求管理工具。這在某 種程度上為市場造就了一批

3、針對特定行業(yè)的需求管理軟件。 這些軟件多數(shù)適用于對需求有嚴格控制的行業(yè)，如航空航天 和軍工行業(yè)等。然而，對于普通行業(yè)市場，企業(yè)更需要的是 實用、集成的需求管理解決方案。Forrester最近的一份報告 指出，大局部企業(yè)都缺乏成熟的需求收集機制和體系；在這 種情況下，即便實施功能強大的工具，企業(yè)也沒有能力來充 分利用各種功能和設置，更不用說有效利用這些工具來管理 需求了。另外，對于傳統(tǒng)的瀑布式開發(fā)，所有的需求都是在開發(fā)開 始前完成的。但對于目前廣泛使用的增量式或迭代式開發(fā)模 式，需求往往是需求者和消費者不斷溝通產生的，也是不斷 變化的。因此，有效的解決方案必須以類似的增量或迭代開 發(fā)模式滿足需求

4、管理。集成的全球需求管理方法基于對一些成功軟件組織的經驗分析，我們認為企業(yè)真正 需要的是一個集成的需求管理解決方案，它可以幫助企業(yè)以 可監(jiān)控、可追蹤和可驗證的方式管理他們的需求。它需要為 創(chuàng)立新的需求、功能和規(guī)范提供一個框架，并與開發(fā)任務和 測試任務相關聯(lián)。需求團隊和開發(fā)團隊可以通過這個集成的 解決方案一起工作。這種集成方案不僅可以提高需求管理工具的性價比，還可 以方便工程團隊的內部溝通。開發(fā)團隊可以及時獲得需求信 息；需求分析師可以通過查看需求的進度來確定可能的需求 變化；管理人員還可以通過查詢、圖表等功能瀏覽開發(fā)工程 的進度。能夠實現(xiàn)上述目標的需求管理工具應該具有以下功 能：集成的需求管理

5、：創(chuàng)立、管理、討論并關聯(lián)工程需求 和功能；變更控制：當特定的變更發(fā)生時自動進行需求版本管 理，并通過工作流引擎來控制需求變更；數(shù)字資產管理：需求、功能以及其他重要的數(shù)字資產 都需要存儲在一個可靠、可擴展、平安的中央資料庫中；集成事件跟蹤和測試：需求管理與事件跟蹤和測試管 理工具集成，以便于工程經理查看與需求相關的開發(fā)和測試 工作；Windows客戶端和Web客戶端：提供Windows客戶端和 Web客戶端訪問方式，保證在固定和移動辦公的情況下都能登 錄到系統(tǒng)中；定制化的用戶界面：提供定制選擇，以便于系統(tǒng)管理 員創(chuàng)立自定義的需求和功能界面，如字段標簽、字段類型、 下拉菜單項選擇項和客戶報告等；開

6、放的工作流設置：通過定義工作流來創(chuàng)立和管理需 求和功能；嵌入式報表和分析：直接產生需求功能數(shù)據報表，如變更控制、變更效應、實施和測試數(shù)據等;自動獲取需求：在系統(tǒng)中，用戶可以直接輸入需求信息，或者通過文檔形式獲得需求并附加到系統(tǒng)中。在獨立實現(xiàn)以上功能的基礎上，需求管理工具還需與ALM 中的開發(fā)過程進行無縫集成，其中包含事件跟蹤、測試管 理、以及中央知識庫（如圖1所示）。規(guī)范點驅動的需求管理誠然，需求管理對整個軟件工程的成敗發(fā)揮著舉足輕重 的作用。然而，需求在最初只是客戶或管理人員對產品功能的一種愿望，需求分析師要將這種非結構化、粗線條、不明 確的愿望歸納總結為具體的規(guī)范點(Specificati

7、on,簡稱Spec) o產品管理團隊再把各種Spec根據開發(fā)時間、本錢和 效益進行優(yōu)先排序，確定Spec單，再由開發(fā)團隊照單實施。SpecDD (Specification Driven Development)是 TechExcel根據多年經驗，總結眾多客戶關于軟件開發(fā)管理的 需求而提出的一個概念性框架。SpecDD模型用Spec來表述/ 定義產品或版本功能，并通過中央知識庫與整個團隊有效共 享，使Spec成為貫穿軟件應用生命周期各階段的要素，從而 驅動整個開發(fā)流程。將知識和需求轉換為結構化的、正規(guī)表 達的Spec,是將整個開發(fā)過程從宏觀戰(zhàn)略落實到具體實施戰(zhàn) 術的過程。SpecDD模型在需求

8、管理上的優(yōu)勢主要表達為以下三個方 面。首先，通過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產品為例，用 圖形化的方

9、式顯示了 Spec與知識、需求的關系。針對 Browser產品的最新版本6. 0,有平安和用戶界面兩大類需 求，通過需求分析師將其分解為新的功能，如支持SSL v. 3. 0 Tabbed Browsing等;除新功能以外，Spec還包括對 之前版本的功能增強，如保存已標記的文件；以及上一版本的缺陷，如保存時響應緩慢。這些Spec通過規(guī)劃、編碼、測 試等工作，構成最終交付的產品。同時，Spec也是高度結構化的，表現(xiàn)為其樹形結構準確 對應產品/版本功能樹，以保證開發(fā)人員不喪失任何需求（如 圖3所示）。產品管理團隊通過創(chuàng)立Spec樹，使每個功能/ 缺陷/功能增強都能對應分支上的樹葉。同時，Spec

10、與知識項 目相關聯(lián)，這些知識工程描述了形成此Spec的構思，以及其 他相關的文檔、標準、附件和參考工程。需求變更的管理理解需求變更的可能影響，并有效地控制它們，對于軟件 的最終提交至關重要。無論是改變現(xiàn)有的需求還是增加新的 需求，都會不同程度地影響工程最終交付的進度。例如，需 求的變化可能會影響相關的功能、任務和測試工作；編碼的 延遲會延遲與該功能相關的其他開發(fā)任務和測試工作。因 此，一個有效的需求管理工具必須確保工程團隊能夠容易地 評估這些變更的可能影響。如何在變更發(fā)生之前對其進行評估呢？這就需要將需求 管理與所有開發(fā)、測試行為進行集成，用戶就可以通過跟蹤 編碼、測試等行為對變更帶來的潛在影

11、響進行評估。這在 SpecDD模型中得以實現(xiàn)。將有效的變更轉變?yōu)樾枨笕缜拔乃v，SpecDD模型表現(xiàn)為用Spec來表述/定義產 品或版本功能，并和整個團隊有效共享，從而驅動開發(fā)。因 此，要保證交付的產品完全符合最終版本的Spec,需求分析 部門就要和開發(fā)部門協(xié)同工作，并對變更做出嚴格的控制。 對開發(fā)工作有潛在影響的變更都將會被慎重管理，并嚴格檢 驗是否影響到需求的依賴關系。所有因需求變更而產生的影響，都必須檢驗變更后的完整性。因此，要實現(xiàn)有效的需求 變更，管理工具需要實現(xiàn)以下幾種功能：變更控制對變更進行嚴格的流程控制，包括請求、復查、討論、 調整和批準等；變更請求由一個獨立的工作流所控制；變更

12、不能對需求造成不良影響，因此在變更被批準之前，需求不能被改變。實用性 接近實際的需求管理實踐； 易于被客戶理解；易于對重要的變更進行跟蹤。各部門協(xié)同工作 需求、功能和開發(fā)等各方面 的人員都在各個階段參與變更請求，將不同部門的人員都納 入變更管理體系；讓開發(fā)團隊參與到變更請求的批準過程中，這樣會比被動的接受或拒絕變更要更科學、更有 效；在變更得到批準或拒絕之前，分析針對該變更在資源和時間上的分配。科學的需求管理是軟件工程成功的保證。在更新需求的過 程中，工程的所有相關人員都應該從各自的角色參與其中， 這將促進軟件產品最終實現(xiàn)業(yè)務目標。當需求發(fā)生變化時， 準確的分析和評估也將有助于確保工程按時提交

13、。除需求管理工具獨立工作以外，將它與應用生命周期管 理（ALM）中的其他過程管理工具集成，才能最終提供一個完 整的貫穿需求和開發(fā)過程的解決方案。需求分析人員和開發(fā) 團隊通過一個平臺實現(xiàn)協(xié)同工作，統(tǒng)一接口和共用流程。這 就能促進需求數(shù)據在需求制造者和實施者之間無縫、實時的 傳遞，并保證在開發(fā)的每一個環(huán)節(jié)都可追溯需求。如前文所講，SpecDD模型表現(xiàn)為用Spec來表述/定義產 品或版本功能，并和整個團隊有效共享，從而驅動開發(fā)。因此，要保證交付的產品完全符合最終版本的Spec,需求分析 部門就要和開發(fā)部門協(xié)同工作，并對變更做出嚴格的控制。 對開發(fā)工作有潛在影響的變更都將會被慎重管理，并嚴格檢 驗是否

14、影響到需求的依賴關系。所有因需求變更而產生的影 響，都必須檢驗變更后的完整性。因此，要實現(xiàn)有效的需求 變更，管理工具需要實現(xiàn)以下幾種功能：變更控制 對變更進行嚴格的流程控制，包括 請求、復查、討論、調整和批準等；變更請求由一個獨立的工作流所控制；變更不能對需求造成不良影響，因此在變更被批準之前，需求不能被改變。 實用性 接近實際的需 求管理實踐； 易于被客戶理解； 易于對重 要的變更進行跟蹤。各部門協(xié)同工作需求、功能和開發(fā)等各方面的人員都在各個階段參與變更請求，將不同部門的人員都納 準過程中，這樣會比被動的接受或拒絕變更要更科學、更有入變更管理體系;讓開發(fā)團隊參與到變更請求的批在變更得到批準或拒絕之前，分析針對該變更在資源和時間上的分配?？茖W的需求管理是軟件工程成功的保證。在更新需求的過 程中，工程的所有