閱讀提示：本文作者從項(xiàng)目管理的角度來討論對變化需求管理的策略。首先是討論在構(gòu)建前需求的質(zhì)量，然后說明了如何在構(gòu)建過程中對需求進(jìn)行跟蹤，最后講述了當(dāng)真正發(fā)生需求變更的時候，我們應(yīng)該如何去面對。
需求總是在變化，客戶總會有新的想法，項(xiàng)目好像沒有終結(jié)，我們軟件開發(fā)人員應(yīng)對軟件需求變化時，為了擁有更多的準(zhǔn)備，應(yīng)該做些什么呢？
這個世界唯一不變的就是變化了。月有陰晴圓缺，潮漲潮落，千年前的滄海是現(xiàn)在的良田，這是自然界的變化；人有悲歡離合，生老病死，這是人情世故。變化是并不一定總是給我們帶來驚喜，更多的是帶來意外，使得我們被迫去作一些改變來適應(yīng)這種變化。
所以，變化也是我們?nèi)祟惖靡詮暮唵紊镞M(jìn)化到今天的推動力。
回到我們軟件需求這個論題上來，無疑，變化是需求的一個基本特性。
沒有一成不變的需求，無論我們在正式構(gòu)建之前對需求進(jìn)行了多么深入的開發(fā)，和客戶進(jìn)行了多少回合的反復(fù)驗(yàn)證，而最終卻不得不接受這樣的現(xiàn)實(shí)：系統(tǒng)正式上線之后，在客戶提交的試運(yùn)行報告中，客戶的需求發(fā)生了變化，或者客戶又提出了新的需求等等。
我們的軟件開發(fā)人員陷入了這樣的一個困境：需求總是在變化，客戶總會有新的想法，項(xiàng)目好像沒有終結(jié)，即使驗(yàn)收通過，那也是草草完事，而不是想象中的那么完美。
這是一個殘酷的現(xiàn)實(shí)。之所以Fred Brooks敢在1987的《沒有銀彈》這篇論文中強(qiáng)調(diào)即使不存在銀彈，也能使得軟件工程的生產(chǎn)力在十年之內(nèi)提高十倍，這也是基于軟件需求自身復(fù)雜性的原因。
在本文中，筆者從項(xiàng)目管理的角度來討論對變化需求管理的策略。首先是討論在構(gòu)建前需求的質(zhì)量，然后說明了如何在構(gòu)建過程中對需求進(jìn)行跟蹤，最后講述了當(dāng)真正發(fā)生需求變更的時候，我們應(yīng)該如何去面對。
我們先來看軟件需求的生命周期，正如軟件項(xiàng)目具有一般的過程，軟件需求也有著一個普遍的生命周期，如圖1所示：
圖1：軟件普遍的生命周期
圖1中的項(xiàng)目階段反映的是一般的項(xiàng)目過程，不管采用瀑布模型還是迭代開發(fā)或者是其他的軟件開發(fā)生命周期模型，這樣的一個基本過程都是需要遵循的。而需求的生命周期和項(xiàng)目的階段也是一一對應(yīng)的。
在項(xiàng)目的啟動階段，我們需要對項(xiàng)目進(jìn)行可行性分析，完成立項(xiàng)報告，在這個階段，也就種下了需求的“種子”，這個“種子”也決定了下面所有階段的努力是否有成果，如果項(xiàng)目根本就是不可行的，那么就別提最后的“結(jié)果”了，“種子”是否能“萌芽”也都是個未知之?dāng)?shù)。
如果通過了可行性分析，完成了項(xiàng)目的啟動過程。接下來我們就要把需求這顆“種子”種下去，通過需求調(diào)研和需求分析階段的努力，需求的“種子”開始“萌芽”，并且一直“成長”，直到“成熟”，需求“成熟”之后，我們就可以構(gòu)建需求基線，進(jìn)入項(xiàng)目構(gòu)建階段。
如果對還沒有“成熟”的需求就開始構(gòu)建，那么后果就是在構(gòu)建階段需求的反復(fù)變化，開發(fā)人員疲于奔命。
對“成熟”的需求進(jìn)行構(gòu)建，我們所交付的才是優(yōu)質(zhì)的“果實(shí)”，當(dāng)然，項(xiàng)目后期也不可避免有需求變更，這時，只要我們按照規(guī)定的流程進(jìn)行需求變更，將變更控制在一個可以接受的范圍，這是不會影響到我們最終的交付的“果實(shí)”。
做好需求變更的管理，最終的目的是為了有優(yōu)質(zhì)的交付品。從上面的圖中，我們可以得知，首先必須要有良好的“種子”和健康的“果樹”，最后才有可能結(jié)出優(yōu)質(zhì)的“果實(shí)”。所以，做好需求開發(fā)是有效需求變更管理的基礎(chǔ)。
重視需求開發(fā)
需求開發(fā)是在問題及其最終解決方案之間架設(shè)橋梁的第一步，是軟件需求過程的主體。一個項(xiàng)目的目的就是致力于開發(fā)正確的系統(tǒng)，要做到這一點(diǎn)就要足夠詳細(xì)地描述需求，也就是系統(tǒng)必須達(dá)到的條件或能力，使用戶和開發(fā)人員在系統(tǒng)應(yīng)該做什么，不應(yīng)該做什么方面達(dá)成共識。
我們都知道開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么，最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。
需求開發(fā)就是為了解決這些問題，它必不可少的成果就是對項(xiàng)目中描述的用戶需求的普遍理解，一旦理解了需求，分析者、開發(fā)者和用戶就能探索出描述這些需求的多種解決方案。
這一階段的工作一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，由于需求獲取事物造成的對需求定義的任何改動，都將導(dǎo)致設(shè)計、實(shí)現(xiàn)和測試上的大量返工，而這時花費(fèi)的資源和時間將大大超過仔細(xì)精確獲取需求的時間和資源。
首先，軟件需求不能如實(shí)反映用戶的真正需要。比較常見的一種誤解是需求的簡單和復(fù)雜程度決定了用戶是否能夠真正理解相應(yīng)的內(nèi)容：誤認(rèn)為客戶只能看懂簡單的需求，但是對開發(fā)沒有直接幫助；只有復(fù)雜的需求才有用，但是大多用戶又不可能看得懂。事實(shí)上，造成這類問題的主要原因是捕獲的需求不能反映用戶的視角，因而，用戶站在自己的立場上很難判斷需求是否完備和正確，特別是在開發(fā)活動的早期。
其次，軟件需求不能被開發(fā)團(tuán)隊(duì)的不同工種直接共用。理論上，開發(fā)團(tuán)隊(duì)所有成員的工作內(nèi)容都受軟件需求制約；現(xiàn)實(shí)中，如果不采用理想的需求捕獲方式，只有分析人員的工作看起來和軟件需求的內(nèi)容直接關(guān)聯(lián)，其它人的工作內(nèi)容和軟件需求的關(guān)聯(lián)并不直觀，形式上的差異或轉(zhuǎn)述往往不易察覺地造成了諸多歧義、冗余或者缺失。
本文并不會就此開始探討需求開發(fā)的問題，只是強(qiáng)調(diào)需求開發(fā)過程的重要，以及需求開發(fā)過程對需求變更的影響。就拿筆者親身參與的一個項(xiàng)目來說：我們遵循一般的軟件開發(fā)過程，通過前期一段時間的調(diào)研，做需求分析，客戶基本確認(rèn)之后，開發(fā)人員就投入到緊張的開發(fā)工作中，由于項(xiàng)目時間要求緊迫，在經(jīng)過測試人員的簡單確認(rèn)之后，進(jìn)入到試運(yùn)行階段。
結(jié)果是，在客戶的試運(yùn)行報告中，提出了很多問題，其中就有一條，關(guān)于一個數(shù)據(jù)查詢條件的設(shè)置，客戶要求的是模糊匹配查詢，而實(shí)現(xiàn)的卻是精確匹配查詢。在相關(guān)的需求文檔中，卻找不到任何相關(guān)的需求說明。
需求開發(fā)完成之后，進(jìn)入系統(tǒng)構(gòu)建階段，下面我們來談構(gòu)建過程中如何做好需求跟蹤，以便于后期需求變更的管理。
構(gòu)建過程中的需求跟蹤
跟蹤需求是高質(zhì)量軟件開發(fā)過程中必需的一個特性。用以保證開發(fā)過程中每一個步驟的正確性，以及該步驟與上一步的一致性。經(jīng)驗(yàn)表明，在需求規(guī)格、架構(gòu)、設(shè)計、開發(fā)和測試階段，對需求的跟蹤能力是確保實(shí)現(xiàn)高質(zhì)量軟件的重要因素，同時也為需求變更管理提供有力的支持。
跟蹤這些需求在每個階段的變化，并且分析變更帶來的影響，是現(xiàn)代軟件過程的一個主線，尤其是在一些事關(guān)重大的軟件工程項(xiàng)目中，需求跟蹤的影響更加突出。
歷史數(shù)據(jù)表明，如果需求沒有被完整的跟蹤，那么總會有遺失的需求或者是沒有解決的需求，或者是需求的變更沒有徹底進(jìn)行，導(dǎo)致部分影響被忽略了，而往往是這樣的失誤導(dǎo)致很嚴(yán)重的安全問題和可靠性問題，給客戶帶來不可估量的損失。
這樣的教訓(xùn)往往是非常慘痛而且印象深刻，筆者至今尤對這樣的一次“事故”記憶猶新。那是參加的一個預(yù)算項(xiàng)目，在我們開發(fā)即將結(jié)束的時候，客戶由于業(yè)務(wù)情況發(fā)生變化，提出了一條業(yè)務(wù)數(shù)據(jù)修改規(guī)則的變更。
對于這個這個業(yè)務(wù)數(shù)據(jù)的寫規(guī)則，雖然我們在需求文檔中有記錄，但是沒有將其與設(shè)計、開發(fā)構(gòu)件一一對應(yīng)，建立它們之間的關(guān)聯(lián)，導(dǎo)致在處理這條變更的時候，開發(fā)人員遺漏了一種情況的處理。
而這樣的問題直到在客戶的應(yīng)用系統(tǒng)運(yùn)行半年之后才由客戶發(fā)現(xiàn)，雖然事情最后通過升級軟件、人工加工數(shù)據(jù)處理了這次意外，但是，事故給企業(yè)帶來的不僅是金錢上的損失，也給企業(yè)的聲譽(yù)帶來非常不利的影響。
圖2：需求跟蹤模型
在圖2跟蹤模型中，箭頭代表的是跟蹤的方向，模型表明，不僅在需求定義的領(lǐng)域跟蹤需求，而且我們也在實(shí)現(xiàn)領(lǐng)域和測試領(lǐng)域跟蹤需求。
在系統(tǒng)定義領(lǐng)域，包括有三個方向的跟蹤：從業(yè)務(wù)需求到產(chǎn)品特性的跟蹤；從用例到產(chǎn)品特性的跟蹤；從變更的需求到產(chǎn)品新特性的跟蹤。對于每一種跟蹤，我們都可以使用類似于如下的一個表格來管理。在實(shí)際項(xiàng)目中，要做好需求的跟蹤管理并非易事，也許我們可以使用電子表格，辦公軟件來協(xié)助處理，確實(shí)，它們對于項(xiàng)目的管理非常有用。
但是，表格的問題在于難于維護(hù)，特別是當(dāng)項(xiàng)目較大，存在復(fù)雜的關(guān)聯(lián)關(guān)系的情況，改變一個鏈接可能涉及到很多相關(guān)的鏈接，在這種情況下，維護(hù)就成了一場噩夢。
在這種情況下，我們要么簡化需求跟蹤處理，對大的模塊進(jìn)行跟蹤；要么使用專門的需求管理工具。如果是大型項(xiàng)目，最好使用工具來進(jìn)行管理。這樣，在我們面臨需求變更的時候，才能有備無患。
因時而變，做好需求變更控制
就如前文所述，變化總是避免不了的。變更天生就是軟件過程的一部分。在這種情況下，我們需要建立一個管理變更的過程，使得變更的工作得到控制，并能高效的發(fā)現(xiàn)變更，進(jìn)行影響分析，將變更有效的集成到現(xiàn)有系統(tǒng)中。
產(chǎn)生需求變更的因素包括內(nèi)部因素和外部因素，不管需求變更來自哪里，都需要遵循一個既定的流程來提出變更請求。
這樣的渠道根據(jù)實(shí)際的企業(yè)情況有各自的方案。一般說來，如果是來自客戶的變更，都需要遵照一個固定流程，通過一種正式的方式提交。即使客戶口頭的提出，那么也需要通過會議記錄、文件交由客戶簽字確認(rèn)后才正式進(jìn)入變更流程。
否則，如果在沒有正式依據(jù)下就進(jìn)行需求變更，這樣的項(xiàng)目將進(jìn)入無休止的修改和維護(hù)狀態(tài)。
對于提出的變更請求，首先可以通過項(xiàng)目小組指派專人負(fù)責(zé)進(jìn)行分析，包括該變更的可行性分析，對其他需求的影響分析，對項(xiàng)目進(jìn)度的影響分析等。在這個過程中，就需要利用前文中所述的各種需求跟蹤表格。
通過需求跟蹤表格，列舉出該變更所涉及需要修改的其他需求，影響的其他用例、測試用例、用例實(shí)現(xiàn)等。然后才可以對工作量進(jìn)行估算，評估該變更的可行性以及對項(xiàng)目進(jìn)度影響等。
變更開發(fā)結(jié)束之后，也需要組織相關(guān)人員對變更進(jìn)行評審，這樣的評審?fù)馨l(fā)現(xiàn)不少潛在的問題，比如有遺漏的需求沒有修改等。只有評審?fù)ㄟ^后，才能進(jìn)入下一階段，對變更相關(guān)的文檔、產(chǎn)品進(jìn)行維護(hù)，使得需求文檔、設(shè)計文檔、產(chǎn)品保持一致性。至此，整個需求變更過程結(jié)束。
需求變更管理是需求管理中的一個重要部分，只有有效的需求變更管理提才能高產(chǎn)品的可能性，并使最終產(chǎn)品更接近于解決需求，提高了用戶對產(chǎn)品的滿意度，從而使產(chǎn)品成為真正優(yōu)質(zhì)合格的產(chǎn)品。從這層意義上說，需求變更管理是產(chǎn)品質(zhì)量的基礎(chǔ)。
筆者通過對需求開發(fā)、需求跟蹤和需求變更過程三個方面對需求的變更管理進(jìn)行討論。一方面希望能引起業(yè)界對需求管理的關(guān)注，另外也希望能借此拋磚引玉，引發(fā)各位方家對需求管理方面的討論。
管理變更步驟：
● 提出變更請求
● 變更分析
● 變更評審
● 制定變更計劃
● 變更需求的開發(fā)
● 變更結(jié)果評審
● 維護(hù)變更
跟蹤需求變更的問題：
● 誰提出變更；
● 什么時候提出變更；
● 變更的內(nèi)容是什么；
● 為什么變更；
● 變更處理意見；
● 變更執(zhí)行結(jié)果。