摘要:有很強有力的證據(jù)顯示，對于開發(fā)人員改善項目成果，以及對我們的目標-- 按照時間和預(yù)算交付高質(zhì)量的軟件 --有幫助的方面，需求管理是一個最有效的手段。本文給出了一些實際的證據(jù)，表明在有效的需求管理方面的投資可以產(chǎn)生實際的回報。

　　軟件危機依然持續(xù)

　　在1996年6月的Fortune雜志的題為： " The Trouble with Software Is ... It Sucks" 的文章中，業(yè)界評論家Stewart Alsop在他的評論中指責我們的工業(yè)界仍然處在軟件質(zhì)量和可靠性低下的狀態(tài)。在業(yè)界多數(shù)人正在旁邊憤怒的時候，最近由Standish Group，一個著名的市場研究機構(gòu)，提供的報告中，給出了甚至更加清醒的看法。按照Standish Group的調(diào)查（超過352家公司報告的超過8,000個軟件項目），得出了以下結(jié)論：

　　31% 的軟件項目在完成之前就被取消（$810億的浪費）。

　　53% 的項目花費預(yù)算的189%。

　　9% 的項目按照時間和預(yù)算完成（大公司）。

　　16% 的項目按照時間和預(yù)算完成（小公司）。

　　為了更進一步幫助理解問題， Standish Group的調(diào)查也詢問被調(diào)查者項目失敗的原因。按照他們的回答，最前面的三個項目失敗的原因列在表1中：

　　表 1: Standish Group 損害項目的因素

　　從表中可以看出，沒有能夠更有效地與用戶一起工作以更好地理解他們的需求，加上在管理需求方面缺乏工程訓(xùn)練，是軟件失敗的主要的原因。

　　需求錯誤的高費用

　　在GTE, TRW和IBM完成的研究測量和分配了項目生命周期不同階段發(fā)現(xiàn)錯誤的費用開銷。這些統(tǒng)計被以后的研究進一步證實。盡管這些研究都是獨立進行的，他們都得出了基本相同的結(jié)論：如果在代碼階段檢測和修復(fù)一個錯誤的費用為1個單位，那么在需求階段發(fā)現(xiàn)和修正一個錯誤的費用只有1/5到1/10。而在維護解階段的發(fā)現(xiàn)和修正一個錯誤的費用為20單位。圖1顯示的主要的結(jié)果。

　　這么大的差距的原因在于，在產(chǎn)品完成前很多錯誤不能被檢測出來。延遲發(fā)現(xiàn)錯誤意味著：修復(fù)錯誤的費用包括直接修復(fù)錯誤的費用加上修復(fù)錯誤引起的一系列投入的費用。這些投入包括重新設(shè)計代碼、重新編寫文檔、使軟件重新工作或者重新替換部署的軟件。

　　需求錯誤和最常見的錯誤

　　研究表明需求階段的錯誤修復(fù)起來代價極其昂貴。如果這類錯誤不經(jīng)常發(fā)生，則項目總成本就沒有那么多。然而在復(fù)雜的軟件項目中，需求錯誤確實是發(fā)現(xiàn)的錯誤中最大類別的一種錯誤。在Sheldon對美國空軍項目的研究中，錯誤按照來源進行了分類。這個研究發(fā)現(xiàn)需求錯誤占發(fā)現(xiàn)總錯誤的41%，邏輯設(shè)計錯誤僅僅占總錯誤數(shù)的28%。其它的研究也支持這個結(jié)果。例如，Tavolato 和 Vincena, 引用了Tom DeMarco的報告，指出所有Bug的56%可以歸結(jié)于需求階段產(chǎn)生的錯誤。

　　需求錯誤和返工費用

　　Raytheon, Dion報告返工的費用大約占項目總預(yù)算的40% 。Boehm報告對于大型軟件項目返工費用大約占到50%。由于需求錯誤的數(shù)量多，影響大， 發(fā)現(xiàn)和修正需求錯誤的費用占項目總返工費用的70% - 85% 。

　　減少需求錯誤

　　這里沒有能夠讓你遠離需求錯誤的銀彈。然而一些機構(gòu)給出了下面的能夠有效地減少需求錯誤的技術(shù)：

　　更有效地需求導(dǎo)出

　　與客戶和最終用戶回顧需

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html