513
連載：麵向對象葵花寶典：思想、技巧與實踐（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 ！
原因顯而易見：如果你的需求錯了，那麼你幾乎是要把軟件項目重做一遍！
相信經過前麵的分析，你對於需求的重要性已經有了充分的認識了。
請時刻牢記：需求很重要！
================================================
轉載請注明出處：https://blog.csdn.net/yunhua_lee/article/details/20472985
================================================
最後更新：2017-04-03 12:55:24