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