以知識(shí)為核心的ALM之需求管理篇

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

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

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

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

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

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

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

8、管理上的優(yōu)勢(shì)主要表達(dá)為以下三個(gè)方 面。首先，通過(guò)SpecDD模型可以實(shí)現(xiàn)對(duì)需求的度量和評(píng)估， 包括每個(gè)需求所需要的資源和時(shí)間，將開(kāi)發(fā)所需的時(shí)間和費(fèi) 用與需求相關(guān)聯(lián)，度量和評(píng)估需求是否成功，通過(guò)需求驗(yàn)證 指標(biāo)來(lái)管理開(kāi)發(fā)、測(cè)試活動(dòng)。其次，Spec與工程規(guī)劃、開(kāi)發(fā) 和測(cè)試任務(wù)始終保持關(guān)聯(lián)，這就保證了開(kāi)發(fā)的每一個(gè)環(huán)節(jié)都 是可追溯。另外，SpecDD模型還能評(píng)估需求變更的潛在影 響，例如需求變更對(duì)開(kāi)發(fā)和測(cè)試工作、工程本錢(qián)的影響。通常情況下，Spec包含功能、缺陷和功能增強(qiáng)三個(gè)局部，他們都來(lái)源于相關(guān)的知識(shí)或需求，并與需求條目和知識(shí) 庫(kù)中的知識(shí)條目相關(guān)聯(lián)。圖2以Browser 6.0產(chǎn)品為例，用 圖形化的方

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

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

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

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

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

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