## 連載：面向對象葵花寶典：思想、技巧與實踐（15） - 需求詳解 很多人像老黃牛一樣辛辛苦苦做了很多年軟件開發，但卻連“需求”到底是什么都不清楚。當然，沒有人自己會承認這點！ **【需求到底是什么】** 凡事都有一個開頭，軟件項目也不例外，對于軟件項目來說，需求就是項目最開始的一個輸入。 參考維基百科，需求定義如下： In?systems?engineering,?a?requirement?can?be?a?description?of?what?a?system?must?do,?referred?to?as?a?Functional?Requirement. 簡單翻譯一下就是：需求即系統需要做什么。 但正是這個簡單的定義，讓很多人陷入了**陷阱**：需求即功能。 單純從字面意思來理解這樣也是沒有問題的：系統需要做什么，當然就是系統要提供什么功能了！ 我們來看一個簡單的例子：ATM自動取款機。 有的人說，ATM的功能是取款、存款、查詢余額，所以針對ATM的需求應該是：取款、存款、查詢余額； 有的人說，ATM的功能有很多：識別卡、密碼認證、點鈔、驗鈔、查詢余額、跨行取款等，所以針對ATM的需求應該是：識別卡、密碼認證、點鈔、驗鈔、查詢余額、跨行取款。 如果你是ATM購買商，你認為哪種才是你的需求？ 如果你是ATM制造者，你認為哪種才是你的需求？ 如果你是ATM使用者，你認為哪種才是你的需求？ 可能大部分人都會支持第二種，原因很簡單：取款也要密碼認證、存款也要密碼認證，所以密碼認證是一個需求，而不是分到兩個需求里面。 而且第二種方式劃分需求有一個好處：系統最后提供的功能和需求基本上是一一對應的。 看起來很美妙，但其實我們忽略了一個問題：采用第二種方式的主要原因是我們對ATM機很熟悉了！ 但如果換一個身份，比如說你是一個只識字的農民工，你對ATM機的要求會是“識別卡、密碼認證。。。。。。”這樣專業的需求么？ 肯定不會，你的需求應該是“取款”、“存款”、“查詢余額”。 我們繼續打破砂鍋問到底：為什么農民工兄弟的需求肯定是“取款”、“存款”、“查詢余額”，而不是“識別卡”、“密碼認證”、“點鈔”。。。。。。？ 我們假設一下，假如農民工兄弟對ATM的需求是“點鈔”，那么就會出現這樣滑稽的場景：他經常拿著卡去ATM機，讓ATM機點一下鈔；又或者他的需求是“密碼認證”，那么他經常拿著卡去ATM機驗證一下密碼。 你當然不會看到這樣的場景，農民工兄弟也不會有這樣的需求，他只管能取到錢即可，因為取到錢他就可以拿錢去花了，至于取錢的過程中管你是密碼認證、點鈔還是驗鈔，說的搞笑一點：他更希望把卡插進去，錢就自動吐出來而且不受限額。 ? 相信到這里，你已經能夠明白需求和功能的差別了，我們總結一下： 需求：對客戶來說有價值的事情； 功能：系統為了實現客戶價值而提供的能力； ? 因此，區別是需求還是功能的方法很簡單了：只要判斷是否對客戶有價值。 我們可以舉更多例子來證明這個方法： POS機：“買單”是需求，“商品掃描”、“金額匯總”、“收銀”等是功能，因為買完單后顧客就能將產品拿走； 汽車：“駕駛”是需求，“發動機”、“剎車”、“加速”等是功能； 打印機：“打印”是需求，“進紙”、“設定”、“與電腦連接”等是功能； 。。。。。。 （有興趣的朋友可以自己多想想） ## 【需求非常重要】 俗話說，萬事開頭難，需求是軟件項目的最開始輸入，肯定是非常重要的，按道理來說也應該是需要重點關注的。 ? 然而現實情況卻恰恰相反：很多項目都不怎么重視需求！ ? 你可以經常看到這樣的場景： 需求分析人員和客戶溝通了一下，然后把客戶的要求簡單整理了一下就交給研發了。。。。。。 項目計劃比較緊，那么就把需求分析階段加快一些吧（實際上就是減少投入時間）。。。。。。 產品給了一個簡單的需求，為了能夠快速交付，沒有怎么分析就開始設計編碼了。。。。。。 ? 雖然看起來時間是節省了，項目是加快了，然而最終的結果卻令人失望：據統計，有將近1/3的項目失敗或者陷入困境時因為需求原因導致的！ ? 這個就是所謂的“垃圾進垃圾出（Garbage?in,?garbage?out）”的效果，即： 如果最開始的輸入是錯誤的，后面的過程再怎么優秀，最終都會輸出垃圾產品。而且可能是后面越優秀，最終輸出越垃圾，就像你朝一個錯誤的方向跑步，跑得越快離正確的終點越遠一樣。 ? 舉一個雖然惡心但很形象的例子：給你一坨屎，你放到餅干生產線上，最后生產出來的不是餅干，而是像餅干的一坨屎！：） ? 你可能會說，錯了我改還不行么？ 當然是可以的，但你要做好心理準備，還有一個更加令人抓狂的事實：修復需求錯誤的問題的成本非常高昂！ ? 我們假設編碼階段發現和修復一個錯誤所耗費的人力是1個單位，那么在測試階段修復需求錯誤的成本是5~10倍，在維護階段（產品正式應用后），修復需求錯誤的成本是20倍，而如果在需求階段修復需求錯誤，成本只需要0.1~0.2即可。 ? 也就是說，需求錯誤的成本存在這樣的比例關系：維護階段修復?=?需求階段修復?*?200?！ 原因顯而易見：如果你的需求錯了，那么你幾乎是要把軟件項目重做一遍！ ? 相信經過前面的分析，你對于需求的重要性已經有了充分的認識了。 請時刻牢記：需求很重要！