根據我們的經驗，需求變更越多，造成的軟體修改越多，bug也就會越多，事實是否如此呢？需要我們根據歷史的資料進行檢驗。某企業採集了歷史上多個專案的的需求變更次數、交付**的規模、軟體測試發現的缺陷個數，參見下表，基於這些歷史資料我們分析一下，看看我們的經驗結論是否成立。
表一：需求變更的歷史資料
id需求變更數
**規模loc
總缺陷數
測試缺陷密度bugs/kloc
需求變更密度(個/mloc）10
221#div/0!
#div/0!20
18383
42523.119186203
03141
3310.5062082104
040250
0501000
666606
0200
2713507
0501020008
055041
340.61772133509
025072
48219.22463306010
09970300
011014037
1138.050153167012
1441243
200.045326498
2.266324905131
10011
11010000141
144907
2761.904669892
6.900977869151
1500
2818.66666667
666.6666667162
4664
8418.0102916
428.8164666172
122968
980.796955305
16.26439399182
355699
420.118077363
5.622731579192
77344
6047.809267687
25.85850228202
87163
3303.786010119
22.94551587213
13899
29020.86481042
215.8428664223
44000
952.159090909
68.18181818234
68700
1562.270742358
58.22416303244
118126
4223.572456529
33.8621472255
30299
66421.91491468
165.0219479265
62323
4457.140221106
80.22720344275
72808
5677.787605758
68.67377211286
131#div/0!
#div/0!297
33300
90827.26726727
210.2102102309
77691
2423.114903914
115.843534
3110
35000
1053
30.08571429
285.7142857
3210
177138
6983.940430625
56.45316081
3311
188964
7553.995470037
58.21214623
3413
40626
73918.19032147
319.9921233
3515
127150
8716.850176956
117.9709005
3639
341860
2015
5.894225706
114.0817879
3745
210000
1642
7.819047619
214.2857143
38130
244000
1599
6.553278689
532.7868852
首先我們來看看總缺陷數與需求變更數的關係：
圖1 需求變更數與測試發現的總缺陷圖之間的散點圖（未刪除離群點）
在圖1中，我們發現存在顯著離群點，該點游離於總體的趨勢之外，刪除之，重新畫圖：
圖2需求變更數與缺陷總數的散點圖
此時，可以清楚的發現隨著需求變更數的增加，總缺陷數是在增加的，二者是正相關的！最右側存在兩個點離群，對總缺陷數做正態分佈分析，發現不服從正態分佈，於是對總缺陷數做開方變換，變換後的資料服從正態分佈，並刪除離群點後得擬合線圖如下：
圖3 需求變更數與測試缺陷數的平方根的擬合線圖
通過以上的分析我們可以發現需求變更數與測試缺陷數之間存在強相關。
我們也可以試著分析單位**行的需求變更次數與單位**行的缺陷個數之間的關係，即**中最後兩列的相關性。排除離群點後，可以發現每百萬行**的需求變更次數與每千行**測試發現的缺陷數是弱相關的：
綜上所述，在這家公司裡，通過38個專案的歷史資料，可以初步得到這樣結論：需求變更越多，系統中的缺陷越多。
對需求變更的看法
專案做到這個程度了，突然要改需求，改邏輯，這無疑是給程式設計師們最狠的一擊，但是沒有辦法，只能照做，因為你是程式設計師。前期的專案要求其實本身就不明確，但是上峰一聲令下，我就揹負著使命深扎客戶陣營，開始了操蛋的開發 從開始的動畫實現，到最後整個ui的成型，再到後來的資料模擬，網路請求資料，ui互動 ...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
需求變更的煩惱
客戶今天要求變更需求，加某某功能，這個應該不難吧，某某公司的產品都有這個功能的。客戶的需求一直在變，煩惱。開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的。客戶方和開發方在一起 workshop 還好，如果分開在兩地就更糟糕。永...