UML大戰需求分析

上個月，我們公司組織去聽了張傳波老師需求分析之瘋狂的訂餐系統s的課，呵呵果然受益匪淺哦。

下面總結一下收穫吧：

　　首先剛開始的時候，老師叫我們大家分組選出組長，通過這些小事情來活躍會議的氣氛。

然後，張老師給我們出了一個畫，

第一幅圖是客戶是如此描述想要的需求的，第二幅是專案經理是那樣理解的，而設計人員的理是是上述第三幅圖

然後呢，編碼人員是第四幅圖那樣做的，第五幅圖是業務人員是那樣的給客戶描述。第六幅圖是我們項目文檔是

一片空白，然後第七幅圖是實施人員如何實施的，我們的客戶投資是八那樣巨大，圖九是支援人員如此簡單

那倒底客戶的真正需求是什麼呢？圖十！

　　張老師通過這個圖給我們講解了一下需求分析的重要性。

　　講完這個時候，張老師給我們出了一個案例，瘋狂的訂餐系統。先談一下簡單的需求，就是一家IT軟體公司向其員工提供了免費午餐

，平常都是由前台收集大家點餐，然後報餐廳。

　　現在遇到一些問題，前台覺得每天問大家吃啥飯比較麻煩，人少還好說，人多了效率太低。而員工又覺得正在工作的時候問他點餐

又影響了他進行中的工作。這

　　這時候，boss提出來，是否可以做一個訂餐系統呢，大家想吃什麼通過系統提交然後前台直接列印出來報表，交遞餐廳。

　　好了講到這裡，張老師要求我們每個小組抽出一名組員作為客戶出需求，其他小組成員根據他提出的需求來設計方案。

簡單討論一番後。大家各小組發言，有些小組設計人員認為客戶太刁鑽，認為客戶太霸道，提出的需求太過份，有些小組客戶認為設計人員水平太次，

總是說這也實現不了，那也實現不了。雙方就訂餐系統意見達不成一致。

　　一個很簡單的訂餐系統怎麼會如此麻煩呢，在這裡就要求我們技術人員深度挖掘客戶背景，項目涉眾，以前沒有系統前訂餐存在哪些問題，

期待使用系統可以解決哪些問題，系統成功的標準是什麼。

　　在這裡講，在跟客戶洽談需求的時候，不要一上來就讓客戶牽著我們的鼻子走，客戶往往都是精明的，不要認為客戶是不可理喻的

那是因為我們還沒有挖掘到客戶背後真正想要什麼，客戶往往提出的是解決方案。所以我們要首先瞭解客戶的項目背景，比如員工訂餐標準8塊，員工人數20人左右

很少有員工出差，中午休息1個半小時，使用本系統都有哪些人，系統帶給他們的又是什麼，老闆希望解決的是什麼問題，員工需要解決的是什麼問題

　　當我們瞭解了這些東西後，我們再結合客戶給我們談的所謂需求，給客戶出一個完整的解決方案。在這裡我要說的是所有的系統都是有一套完整的管理方法

當我們給客戶上了系統後，接著麻煩事又來了

1，某員工點餐了，結果餐廳今天恰好沒有這個菜了

2，訂餐標準8塊，能不能10塊呢

3，有些員工出去了，不能上網，不能通過該系統訂餐

4，能不能多提供幾家餐廳的菜譜

5，能不能顯示菜的圖片呢

6，是否可以一次提交多天的訂餐資訊，每天都登入太麻煩

7，能否做一個串連呢，一下就可以提交定餐，不然要點很多頁面才能提交定餐資訊

8，是不是還有一個營養分析功能呢？

　　客戶用我們的系統後提出了一些問題希望我們可以更改一下，這時候估計我們頭大了，這客戶也太霸道了，這簡直做成啥了，還營養分析分析

我們該怎麼辦呢？是不是跟客戶大吵一架，然後跟客戶決絕，不再有生意往來呢