淺談軟體專案上的長期慢性需求問題

　　本文的作者Capers Jones是Namcook Analytics公司的副總裁和首席技術總監。他一直在收集軟體質量和開發效率上的資料。他寫了幾十本關於軟體質量、最佳實踐方法、評估、測量方面的著作。

　　在處理軟體需求時，有三個問題一直折磨著我們，並使軟體專案消耗無數資金。其中很大一部分都產生在專案交付並執行後的新需求的收集工作中。

　　下面是在軟體需求處理中三個廣泛存在的問題，需要我們去尋找比當前普遍的常規做法更有效的解決方案：

• 很多需求是非常危險或是有毒的，需要堅決抵制。
• 很多客戶堅持要在軟體中強加入一些額外的、多餘的功能。
• 需求永遠提不完，並以每月1%的速率增加。

　　軟體開發者道德上有義務、職業上有責任在這些問題上提醒客戶，並儘可能的幫助他們解決這些問題。換句話說，軟體開發者需要充當的角色類似於一個醫生。我們有責任幫助客戶診斷目前已知的需求，並開出有效的處方。

　　當然，一旦使用者需求收集完成，分析整理完成，承諾的軟體規格就應該如實的交付給客戶。然而，為了保證軟體能安全有效的交付，危險的或有毒的需求必須被除去，多餘的和不必要的需求需要讓使用者知道，潛在的能導致需求滋生的不清晰的地方需要被明確、量化。使用者應該從軟體開發技術團隊那裡獲得專業的幫助，而不應該在需求收集和分析上被動的扮演旁觀者角色。

　　不幸的是，需求上的缺陷並不能通過普通的測試來消除。如果需求上的錯誤未能預防而出現，或沒有能夠通過常規的檢查或其它方法消除，那麼，從需求上構造出來的測試用例只能再次證實需求的正確，而不是發現其中的錯誤。(這就是為什麼多少年的軟體測試都不曾發現並消除”2000年”問題)

　　另一類需求上的問題，對於一些全新的創造性的軟體應用，很可能最初使用者只有原創者，沒有第二人。參考一些成功的軟體的歷史，如APL程式語言，第一個電子製表軟體，早期的Web搜尋引擎(之後成為谷歌)。

　　這些具有革命性的應用軟體全是發明人自己用來解決他們自己的問題的。他們並不是按照常規概念上的“使用者需求”開發出來的。除非演示程式被開發完成，其他人基本無法認識到這些軟體發明的價值所在。因此，“使用者需求”對於一些全新的革命性的軟體來說不是能完全適用的，除非它們已經公開發布。

　　軟體需求會不斷的發展、繁殖、變化，在其隨後的設計和編碼階段統計出的資料，每月增加的量大概是1%到4%，基於這種現狀，很顯然，要想達到對需求的完全理解是十分困難的。

　　需求是軟體開發的重要一環節，但由於摻雜著有毒的需求，缺失的需求和多餘的需求，使得簡單的諸如“品質的標準就是照需求完成”這樣的定義成為了軟體工業的毒藥。

　軟體交付之後

　　“增長的需求”這個問題經常不受重視。一旦軟體應用交付給客戶或使用者，需求並不是終止或不變了。對於大多數的應用，需求的增長的延續會一直伴隨著應用的使用期間。它們增長的速率最高能達到每年15%。

　　因為需求在增長，軟體應用的體量也會變大——不論從功能點，邏輯程式碼量或其它尺度測量。

　　為了說明這種持續性增長，下面的表格顯示了一個我研究的大型Java應用的變化。

測量週期	功能點	邏輯程式碼量
1 需求階段結束時	10,000	530,000
2 需求補充	2,000	106,000
3 計劃交付量	12,000	636,000
4 延期的功能量	- 4,800	- 254,400
5 首次提交給客戶的量	7,200	381,600
6 一年使用後	12,000	636,000
7 2年使用後	13,000	689,000
8 3年使用後	14,000	742,000
9 4年使用後 (中期提升)	17,000	901,000
10 5年使用後	18,000	954,000
11 6年使用後	19,000	1,007,000
12 7年使用後	20,000	1,060,000
13 8年使用後 (中期提升)	23,000	1,219,000
14 9年使用後	24,000	1,272,000
15 10年使用後	25,000	1,325,000

　　這些數字在第4年和第8年有一個超出平均值的增加。對於商業軟體，為了跟最新的其它軟體競爭，有必要增加一些重大的新功能。這叫做“中期提升”。

　　正如你看到的，需求增加在軟體應用使用期間永不會停止，除非開發者開發出相同型別的新產品而放棄對老產品的支援。當然，一些軟體會很好的執行10幾年。例如，美國空中交通管制系統已經使用了超過30年了。

　　怎麼辦…

　　軟體需求是軟體工程技術中最薄弱的一個環節。因為需求總是不完備的，總是含有錯誤的，這就要求軟體開發者一定要使用最先進的軟體需求方法。使用者並沒有培訓過這些需求收集/分析技術，在沒有經過受訓的需求專家的幫助下無法提供完整無誤的需求，更重要的，軟體開發者應該理解——甚至擁抱——這樣的事實：在軟體交付執行之後，跟使用者關於需求的對話將不會停止。

　　原文連結：Chronic Requirements Problems