本文的作者Capers Jones是Namcook Analytics公司的副總裁和***技術總監。他一直在收集軟件質量和開發效率上的數據。他寫了幾十本關于軟件質量、***實踐方法、評估、測量方面的著作。

在處理軟件需求時，有三個問題一直折磨著我們，并使軟件項目消耗無數資金。其中很大一部分都產生在項目交付并運行后的新需求的收集工作中。

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

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

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

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

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

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

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

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

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

軟件交付之后

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

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

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

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

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

怎么辦…

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

英文原文：Chronic Requirements Problems

譯文鏈接：http://www.aqee.net/chronic-requirements-problems/