閱讀提示：本文作者從項目管理的角度來討論對變化需求管理的策略。首先是討論在構(gòu)建前需求的質(zhì)量，然后說明了如何在構(gòu)建過程中對需求進(jìn)行跟蹤，最后講述了當(dāng)真正發(fā)生需求變更的時候，我們應(yī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ù)驗證，而最終卻不得不接受這樣的現(xiàn)實：系統(tǒng)正式上線之后，在客戶提交的試運(yùn)行報告中，客戶的需求發(fā)生了變化，或者客戶又提出了新的需求等等。
我們的軟件開發(fā)人員陷入了這樣的一個困境：需求總是在變化，客戶總會有新的想法，項目好像沒有終結(jié)，即使驗收通過，那也是草草完事，而不是想象中的那么完美。
這是一個殘酷的現(xiàn)實。之所以Fred Brooks敢在1987的《沒有銀彈》這篇論文中強(qiáng)調(diào)即使不存在銀彈，也能使得軟件工程的生產(chǎn)力在十年之內(nèi)提高十倍，這也是基于軟件需求自身復(fù)雜性的原因。
在本文中，筆者從項目管理的角度來討論對變化需求管理的策略。首先是討論在構(gòu)建前需求的質(zhì)量，然后說明了如何在構(gòu)建過程中對需求進(jìn)行跟蹤，最后講述了當(dāng)真正發(fā)生需求變更的時候，我們應(yīng)該如何去面對。
我們先來看軟件需求的生命周期，正如軟件項目具有一般的過程，軟件需求也有著一個普遍的生命周期，如圖1所示：
 |
| 圖1：軟件普遍的生命周期 |
圖1中的項目階段反映的是一般的項目過程，不管采用瀑布模型還是迭代開發(fā)或者是其他的軟件開發(fā)生命周期模型，這樣的一個基本過程都是需要遵循的。而需求的生命周期和項目的階段也是一一對應(yīng)的。
在項目的啟動階段，我們需要對項目進(jìn)行可行性分析，完成立項報告，在這個階段，也就種下了需求的“種子”，這個“種子”也決定了下面所有階段的努力是否有成果，如果項目根本就是不可行的，那么就別提最后的“結(jié)果”了，“種子”是否能“萌芽”也都是個未知之?dāng)?shù)。
如果通過了可行性分析，完成了項目的啟動過程。接下來我們就要把需求這顆“種子”種下去，通過需求調(diào)研和需求分析階段的努力，需求的“種子”開始“萌芽”，并且一直“成長”，直到“成熟”，需求“成熟”之后，我們就可以構(gòu)建需求基線，進(jìn)入項目構(gòu)建階段。
如果對還沒有“成熟”的需求就開始構(gòu)建，那么后果就是在構(gòu)建階段需求的反復(fù)變化，開發(fā)人員疲于奔命。
對“成熟”的需求進(jìn)行構(gòu)建，我們所交付的才是優(yōu)質(zhì)的“果實”，當(dāng)然，項目后期也不可避免有需求變更，這時，只要我們按照規(guī)定的流程進(jìn)行需求變更，將變更控制在一個可以接受的范圍，這是不會影響到我們最終的交付的“果實”。
做好需求變更的管理，最終的目的是為了有優(yōu)質(zhì)的交付品。從上面的圖中，我們可以得知，首先必須要有良好的“種子”和健康的“果樹”，最后才有可能結(jié)出優(yōu)質(zhì)的“果實”。所以，做好需求開發(fā)是有效需求變更管理的基礎(chǔ)。
重視需求開發(fā)
需求開發(fā)是在問題及其最終解決方案之間架設(shè)橋梁的第一步，是軟件需求過程的主體。一個項目的目的就是致力于開發(fā)正確的系統(tǒng)，要做到這一點(diǎn)就要