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