需求面面觀
互聯(lián)網(wǎng)上很流行這張圖：
每次看到這張圖，我都覺得十分形象，也十分貼切。
對于軟件需求，不同角色會有不同的詮釋和理解，上圖的第一行非常經(jīng)典地展示了各類角色的特點：
客戶：他想要的東西并不能準(zhǔn)確全面地表達出來。
項目經(jīng)理：項目經(jīng)理對需求的理解，往往是在客戶表達出來的基礎(chǔ)上，再打個折扣。
分析員：分析員往往喜歡追求技術(shù)上的標(biāo)新立異，而不能需求驅(qū)動地做設(shè)計。
程序員：漂亮的設(shè)計到了程序員手上，往往變成了面條式代碼。
商業(yè)顧問：Sales的特點就是“哄你無商量”！
上圖第二行，展示了項目的普遍問題：
項目文檔：無
安裝程序：“簡潔”
客戶投資：巨大
技術(shù)支持：能按時交貨就萬事大吉了，做完最好拍屁股走人，管你什么技術(shù)支持！
解密：項目失敗的大部分原因就是沒有把握住真正的需求！
或許你會覺得此圖有點夸張，下面我們看看一些具體例子吧。
手機訂餐系統(tǒng)的故事
話說某公司中午統(tǒng)一為員工訂餐，訂餐辦法如下：
1)每個人在網(wǎng)站上提交今天想吃什么。
2)前臺匯總后傳真給餐廳。
3)餐廳送餐。
但有這樣的問題：
1)有人請假或者外出工作，無法在網(wǎng)站上提交。
2)導(dǎo)致一些辛勤工作的員工沒有飯吃。
老板就產(chǎn)生了這樣的想法：
要做一個手機短訊訂餐系統(tǒng)，讓外出工作的員工可以通過手機訂餐。
于是成立了手機訂餐項目組，購買了手機短訊收發(fā)的硬件，解決了選餐單、定餐、取消訂餐等技術(shù)問題。
但，這個系統(tǒng)還時靈時不靈，問題是出在軟件、硬件、還是中國移動都難以搞清楚。
老板大法雷霆，這樣的小事情，怎么搞成這樣？！
有人提出來：不在公司的員工，打電話回公司告訴前臺吃什么，不就搞定了？
于是全世界都恍然大悟，天?。。。?/P>
對于上面這個故事，不知道同學(xué)們有什么感想呢？
你引導(dǎo)客戶還是客戶在引導(dǎo)你？
我做的第一個大型分布式系統(tǒng)，是某房地產(chǎn)公司的成本管理系統(tǒng)。我的自我感覺還是相當(dāng)不錯的，不過其中一個客戶認(rèn)為他在本項目中發(fā)揮了很大的作用，基本上是他指導(dǎo)我們將軟件做出來的。當(dāng)時我覺得不是很爽，也沒有仔細思考這是怎么回事。
我們公司為中國移動做的一個項目，整體來說客戶還是滿意的，不過客戶提出了這樣的一個建議：希望我們能為他們提供更多的創(chuàng)造性意見，將系統(tǒng)做得更好。而我們覺得必須非常熟悉客戶的業(yè)務(wù)，這樣才有可能提出好的建議，而要熟悉客戶的業(yè)務(wù)，不到客戶那工作一年半載，恐怕是熟悉不了。
我最開始做項目的基本思想是：客戶“告訴”我們做什么，我們適當(dāng)加以引導(dǎo)。這樣的思想應(yīng)該相當(dāng)普遍，我們要做不同類型的項目，不太可能每個項目都能深入去研究業(yè)務(wù)，很多情況下只能“點到為止”。這樣我們很容易會犯下“手機訂餐系統(tǒng)”的錯誤，而最理想情況下也只能讓客戶基本滿意，而沒能超出客戶的期望，給客戶帶來更大更高的價值。不能給客戶帶來更高的價值，項目也更難獲得更高的利潤，公司的競爭力也難以進一步提高。
需求分析說到底要解決的最根本問題就是：客戶到底要什么！
客戶通常只會有朦朧的大概的想法，他們提出來的需求，只是表面的，不全面的，甚至是互相矛盾的，我們需要透視它的本質(zhì)。
如果我們能說出客戶內(nèi)心深處真正想要的，而客戶又不能表達出來的東西，我們才能真正做到“為客戶帶來價值” ！
找到需求根源，解決的辦法可能很簡單，而不需要來個“手機訂餐系統(tǒng)”來解決，勞師動眾，又不能解決問題。
解決了客戶的最基本需要基礎(chǔ)上，我們還需要為客戶提供更強的服務(wù)，發(fā)掘客戶更高價值的需求！
UML能幫助我們實現(xiàn)以上目標(biāo)。
UML與需求分析
UML能幫助我們分析問題，發(fā)掘問題之根源：