閱讀提示：本文作者從項目管理的角度來討論對變化需求管理的策略。首先是討論在構建前需求的質量，然后說明了如何在構建過程中對需求進行跟蹤，最后講述了當真正發(fā)生需求變更的時候，我們應該如何去面對。
需求總是在變化，客戶總會有新的想法，項目好像沒有終結，我們軟件開發(fā)人員應對軟件需求變化時，為了擁有更多的準備，應該做些什么呢？
這個世界唯一不變的就是變化了。月有陰晴圓缺，潮漲潮落，千年前的滄海是現在的良田，這是自然界的變化；人有悲歡離合，生老病死，這是人情世故。變化是并不一定總是給我們帶來驚喜，更多的是帶來意外，使得我們被迫去作一些改變來適應這種變化。
所以，變化也是我們人類得以從簡單生物進化到今天的推動力。
回到我們軟件需求這個論題上來，無疑，變化是需求的一個基本特性。
沒有一成不變的需求，無論我們在正式構建之前對需求進行了多么深入的開發(fā)，和客戶進行了多少回合的反復驗證，而最終卻不得不接受這樣的現實：系統(tǒng)正式上線之后，在客戶提交的試運行報告中，客戶的需求發(fā)生了變化，或者客戶又提出了新的需求等等。
我們的軟件開發(fā)人員陷入了這樣的一個困境：需求總是在變化，客戶總會有新的想法，項目好像沒有終結，即使驗收通過，那也是草草完事，而不是想象中的那么完美。
這是一個殘酷的現實。之所以Fred Brooks敢在1987的《沒有銀彈》這篇論文中強調即使不存在銀彈，也能使得軟件工程的生產力在十年之內提高十倍，這也是基于軟件需求自身復雜性的原因。
在本文中，筆者從項目管理的角度來討論對變化需求管理的策略。首先是討論在構建前需求的質量，然后說明了如何在構建過程中對需求進行跟蹤，最后講述了當真正發(fā)生需求變更的時候，我們應該如何去面對。
我們先來看軟件需求的生命周期，正如軟件項目具有一般的過程，軟件需求也有著一個普遍的生命周期，如圖1所示：
 |
| 圖1：軟件普遍的生命周期 |
圖1中的項目階段反映的是一般的項目過程，不管采用瀑布模型還是迭代開發(fā)或者是其他的軟件開發(fā)生命周期模型，這樣的一個基本過程都是需要遵循的。而需求的生命周期和項目的階段也是一一對應的。
在項目的啟動階段，我們需要對項目進行可行性分析，完成立項報告，在這個階段，也就種下了需求的“種子”，這個“種子”也決定了下面所有階段的努力是否有成果，如果項目根本就是不可行的，那么就別提最后的“結果”了，“種子”是否能“萌芽”也都是個未知之數。
如果通過了可行性分析，完成了項目的啟動過程。接下來我們就要把需求這顆“種子”種下去，通過需求調研和需求分析階段的努力，需求的“種子”開始“萌芽”，并且一直“成長”，直到“成熟”，需求“成熟”之后，我們就可以構建需求基線，進入項目構建階段。
如果對還沒有“成熟”的需求就開始構建，那么后果就是在構建階段需求的反復變化，開發(fā)人員疲于奔命。
對“成熟”的需求進行構建，我們所交付的才是優(yōu)質的“果實”，當然，項目后期也不可避免有需求變更，這時，只要我們按照規(guī)定的流程進行需求變更，將變更控制在一個可以接受的范圍，這是不會影響到我們最終的交付的“果實”。
做好需求變更的管理，最終的目的是為了有優(yōu)質的交付品。從上面的圖中，我們可以得知，首先必須要有良好的“種子”和健康的“果樹”，最后才有可能結出優(yōu)質的“果實”。所以，做好需求開發(fā)是有效需求變更管理的基礎。
重視需求開發(fā)
需求開發(fā)是在問題及其最終解決方案之間架設橋梁的第一步，是軟件需求過程的主體。一個項目的目的就是致力于開發(fā)正確的系統(tǒng)，要做到這一點就要