需求分析挑战之旅——疯狂的订餐系统
摘要：
說教性質的需求分析理論，各位看了也白看，所以咱們就來一個真實個案——“訂餐系統”體驗一下。“訂餐系統”貌似簡單，但陷阱重重，各種需求分析的經典場景將會一一重現，各位做好準備接受這個挑戰沒有？本文文字超過1萬1千字，而且有n多圖片和思考題，請準備好盒飯邊吃邊看吧……
作者：
張傳波
www.umlonline.org
大綱：
1.某IT公司員工的吃飯問題
2.需求分析的大道理
3.背景-需要-需求規格
4.沒完沒了的“新需求”
5.領導“突發奇想”
6.榨干人腦汁的需求分析
7.變被動為主動
視頻課程：
如果覺得看文章麻煩，可看本文對應的視頻課程：http://www.cnblogs.com/umlonline/archive/2011/07/20/2111430.html
正文：
1. 某IT公司員工的吃飯問題
咱們出來干活的，天天需要吃午飯，所謂“午飯吃不好，工作干不好”。某IT公司深知這個道理，為了讓大家方便吃午飯，由公司統一訂餐，并且費用全包。
這樣的做法，大家當然開心了，不過行政部的同事就要辛苦一點，每天要“服侍”大家吃飯，我們看看怎樣個做法：
文員每天都要向餐廳索取最新菜單，然后拿著菜單找每個人確認今天吃什么。
大家都確認后，文員以電話或者傳真的方式，向餐廳訂餐。
餐廳送來午飯，文員通知大家，然后大家來取餐。
這樣的做法維持了一段時間，但是問題逐漸就來了。
員工A抱怨：我明明點了酸菜魚，干嘛給我送來紅燒魚。
員工B抱怨：我剛才去開會了，沒有點餐，怎么就這樣把我的餐給漏了？
員工C抱怨：我對中午飯要求不高，每天吃麻辣牛肉就可以了，不需要天天來問我吃啥，打斷我的工作。
......
大家都開始來責怪文員了。
文員受了一肚子的委屈，她解釋如下：
有些人寫的字不太清楚，有時會搞錯；
公司這么多人，有人上廁所有人去開會，我哪能保證每次都不漏人。
我按員工C說法做了，沒有再問他了，但有一天取餐的時候，他說上火，不吃麻辣牛肉，要我換！都定了，怎么換啊？保險起見，我以后天天都問他了。
嗚嗚......
公司領導覺得問題責任不在于文員，而是這樣的訂餐方式太落后了，導致諸多問題！好歹是一個IT公司嘛，訂餐也需要信息化！于是領導萌生了要做一個訂餐系統的想法。
于是咱們的好戲就開始了......
2. 需求分析的大道理
你非常光榮地接受了這個任務，領導任命你為訂餐系統的項目經理，你會如何展開需求分析工作呢？
可能你會這樣想：那還不容易，這么簡單的系統，直接編碼就行了，還寫什么需求！
伙計，不要沖動，看到這里請你先停止閱讀，找張紙和筆，用你自以為合適的方式列出這個系統的需求。
請寫完后才繼續往下看噢！
不聽話了？沒寫完就往下看？
咱們先說說需求分析的一些大道理：
首先我們需要明確項目的背景，我們要回答這些問題：也就是為什么會有這個項目？客戶為什么想做這樣的一個項目？如果沒有這個項目會怎樣？
了解背景的基礎上，我們需要進一步了解以下內容：
2)本項目涉及到什么人、什么單位？
3)本項目的目標是什么？
4)本項目的范圍是怎樣的？
5)本項目的成功標準是什么？
以上這些內容，我們稱之為客戶的“需要”。
接下來，就可以定詳細的需求規格說明書了，一般我們會對功能性需求和非功能性需求都列出詳細的要求，我們這里把這些要求定義為“需求規格”。
圖1 背景、需要、需求規格
對于功能性需求，我們往往會描述成用例圖。
圖2 用例圖
對于非功能性需求，往往會對系統穩定性、性能、兼容性等提出要求。
什么是背景？
背景這東西比較籠統，簡單地說就是這個項目的來由，我們需要用說故事的方式講清楚項目的背景。
什么是需要？
需要就是客戶真正想要的東東，是高層次的需求，我們可以把需要解決的問題、關鍵涉眾、項目的目標、范圍、項目成功標準等全部統稱為需要。
什么是需求規格？
需求規格是很細級別的但又沒有細到詳細設計程度的需求了，描述出系統與用戶是如何交互的，系統要滿足怎樣的一些非功能要求。
需求分析過程，無非就是由背景到需要到需求規格的過程，這個過程是螺旋前進的。需求分析中最難解決的問題往往就是搞不清需求之根源，把握不清背景和需要，往往就會被繁瑣的需求規格所困住，被客戶牽著鼻子走。理論是完美的，現實是殘酷的，我們現實的需求分析工作，往往會出現這些問題：
背景啊背景，我該如何寫你呢？
我們公司的需求規格說明書中，第一章節就是“背景”，但往往大部分項目寫出來的背景寫了等于沒寫。有些寫了諸如此類的內容：某年某月某日與某某公司簽訂了某某合同，成立了改項目組，項目人員有誰誰誰，客戶聯絡人是誰誰誰。有些項目更懶，直接復制前期需求文檔的背景，以致項目已經做到第三期了，第三期的背景仍然是抄第一期的。不知道如何分析背景，背景不知道寫啥，這是項目的普遍現象。
目標在哪里？
對于“項目的目標”，項目組普遍的問題有：
1.根本不知道“目標”這回事。
2.目標寫出來了，但被扣上“大而虛”的帽子。
3.沒有用目標來指導下一步工作，后面遇到具體問題時，沒有用目標來思考。
4.目標寫出來就不變了，沒有持續去思考是否需要調整。
需求規格優先
很多需求分析人員喜歡將系統要做的事情，以用例或者功能點的方式記錄下來，但往往沒有記錄為什么需要這樣一個用例或者是功能點，沒有去思考這個用例或者功能點背后隱藏的客戶需要是什么。更甚者進入具體的界面設計，在需求文檔中寫清楚界面上放什么按鈕什么菜單等，一開始就將需求“僵化”，這樣會讓后面的工作陷入“萬劫不復”之地。
本小結開始的時候，要求你先寫下本系統的需求，再繼續往下看。不知道你寫的需求中是否有背景、需要這些內容呢？你寫的需求是不是幾乎全部是“需求規格”呢？
下面，我們將來挑戰“訂餐系統”的背景、需求和需求規格。
圖3 某需求規格說明書目錄
3. 背景-需要-需求規格
請按順序回答以下問題：
1.本項目的背景是怎樣的？
2.本項目能解決什么問題？
3.本項目的關鍵涉眾有哪些？（說明：涉眾是指系統會影響到的人、角色、單位等，或者說什么人、角色、單位會影響到本系統。）
4.本系統要達到怎樣的目標？
5.本系統的范圍是怎樣的？
6.本系統應該具備怎樣的功能？
7.本項目成功標準是怎樣的？
在往下閱讀之前，請先獨立思考，寫出以上問題的答案。
1.本項目的背景是怎樣的？
參考答案：員工中午飯要吃好是很重要的事情，但手工訂餐存在一些問題，領導試圖通過訂餐系統來改善。
答案點評：
1)本系統的用戶是“員工”，而客戶是“領導”。（說明：用戶是指使用系統的人員，而客戶是可以拍板付錢給公司的那個人，是項目組的米飯班主。）
2)領導的目的不是為了做這個系統，而是希望通過這個系統解決問題。
3)領導應該不太可能投入大的投資來解決這個問題，例如：不太可能將員工的午飯標準提高到每人每餐50元，也不太可能為這個項目投入100萬的經費。
背景應該怎樣描述？
背景應描述出系統的用戶和客戶是誰、項目的來源，并且可以由此推斷客戶可能的投資預算，本項目對于客戶的重要程度等。
2.本項目能解決什么問題？
參考答案：
1)手工訂餐本身工作效率低，有時會影響員工的正常工作。
2)手工訂餐容易出錯，導致員工吃不到飯或者是吃不到自己想吃的飯。
答案點評：：
1)問題描述得很具體，并且問題產生的根源似乎都是因為“手工訂餐”導致的。
2)手工訂餐并不會讓大家吃不到飯，只是有時會出一些小問題。
3)手工訂餐的最大優勢就是靈活，不好的地方就是容易出錯，這個訂餐系統如何才能保持手工訂餐的“靈活”優勢呢？
問題應該怎樣描述？
需要清楚明確地描述清楚項目解決的問題，同時要分析好當前的工作方法的優點。系統除了要解決當前的問題，還應該保持原來工作方法的優點。很多系統解決了問題，但丟失了原來工作方法的優勢，往往是得不償失。
3.本項目的關鍵涉眾有哪些？
參考答案：員工、前臺、領導、財務、餐廳。
答案點評：
1)全面考慮了各種涉眾。
2)員工是使用本系統的主體，他們最關鍵的需求應該是能方便準確地訂餐。
3)前臺通過本系統來統計訂餐、和餐廳溝通、下訂單等，前臺可能是本系統使用功能最多、操作最復雜的角色。
4)領導有時也會通過本系統來訂餐，但對本系統的主要要求就是大家要用得舒服。
5)財務可能需要根據本系統的訂餐記錄和餐廳結帳。
6)餐廳需要提供菜單給前臺，餐廳可能以傳真或電話的方式獲知我們的訂餐，不同的方式將會影響本系統的某些功能。
如果找出關鍵涉眾？
1)應廣度優先地盡量多地列出可能的涉眾。
2)列出每種涉眾在本系統的關鍵需求。
3)每一種涉眾都應該清楚說明本系統是如何影響她的，以及她是如何影響本系統的。
4.本系統要達到怎樣的目標？
參考答案：達到“吃飯易”的效果，保證員工不會因為吃飯問題影響正常工作。
答案點評：
1)目標描述應簡單容易記憶，以便項目組隨時記住。
2)本項目的目標并不是讓員工吃飯吃得開心，也不是用來保證員工正常工作（光靠這個系統，是不能保證員工正常工作的），而是希望通過本系統來消除手工訂餐的問題。
應該如何描述目標？
應該用簡單、明確、恰如其分的語言來描述。簡單、明確是方便項目組記憶，以便在工作中隨時可以用目標檢驗工作。恰如其分則要求目標描述不要夸大系統的作用，也不要縮小系統的作用。很多項目描述目標的時候，往往會夸大系統的作用，如提高工作效率、提高生產力等，這些目標往往不是單純靠系統就可以做得到的，更多是靠企業的管理，系統只是起到配合和支持的作用。
5.本系統的范圍是怎樣的？
參考答案：
1)這是一個訂餐系統，只考慮與訂餐相關的功能。
2)這是一個單獨的系統，不考慮與其它系統集成或交互。
3)使用本系統的是**的全體員工，不考慮分公司的員工。
答案點評：
從功能、與其它系統的關系、用戶三方面描述了本系統的范圍。
應該如何描述范圍？
范圍往往客戶并不會直接給出的，我們需要從項目解決的問題、目標等入手，從功能、與其它系統的關系、用戶等來思考系統的范圍。
由前面的資料，我們可以知道，客戶應該不會投入很多錢，客戶目標只是希望解決手工訂餐帶來的麻煩，所以我們定范圍時，應該盡量讓系統簡單，能滿足目標便可。本系統其實可以做得很復雜的，訂餐這事情其實與請假外出相關的，訂餐也會與財務結帳有關系，如果將系統邊界擴大，很可能將問題復雜化。
6.本系統應該具備怎樣的功能？
參考答案：
2009-11-30 11:52
圖4 用例圖
對于“訂餐”這個用例，我們還可以進一步細化用戶與系統的交互：
? ? 用戶指示訂餐
? ?? ???系統給出菜單
? ? 用戶選擇菜單并確認選擇
? ?? ???系統保存用戶的選擇，提示訂餐成功。
答案點評：
1)用例圖全面地描述了系統用戶與用例，條理清晰、一目了然。
2)對于每一個用例，還可以進一步描述用戶與系統是如何交互的，為下一步工作做好準備。
3)除了描述功能，還需要考慮系統的非功能需求，如性能要求、安全性要求等。
應該如何描述功能？
1)要根據前面的問題導出系統應具備的功能以及非功能需求。
2)用例圖是描述功能性需求的好工具，但不要拘泥于只用用例圖。
3)對于非功能性需求，客戶往往沒有具體想法，需要我們從客戶的需要出發，定出具體的非功能性需求。
7.本項目成功標準是怎樣的？
參考答案：用簡單的方式達到目標的要求，達致雙贏。
答案點評：
1)“簡單”意味著成本低，符合雙方利益。
2)達到目標要求是真正的客戶所需。
如何考慮項目的成功標準？
我們做一個項目，成功標準并不是為了賺錢，更加不是不惜一切謀取最大利益，雙贏才是最重要的原則！對于客戶來說，首要目標就是要滿足他的需要，然后就是合理的預算，對于軟件公司來說，首要目標就是為客戶提供高性價比的解決方案，賺取合理利潤。要達致雙贏，客戶的成熟度是很重要的，但更重要的是軟件公司的成熟度，項目組需要以專家、顧問這樣的高度來解決項目中的問題，引導雙方達至雙贏。
以上7個問題，問題1是背景相關的問題，問題2、3、4、5是需要相關的問題，問題6是需求規格相關的問題，而問題7是我們需要認真考慮的問題，考慮清楚項目的成功標準才能更好地指導項目后續工作，提高項目成功概率。
4. 沒完沒了的“新需求”
由于你的徹底而深入的需求分析工作，訂餐系統進展非常順利，很快就上線運行了！但問題也就來了，客戶陸陸續續提出了以下問題：
1)要經過好幾個頁面才能進入訂餐頁面，不太方便，希望能在首頁直接進入訂餐頁面。
2)一次只能定一天的餐，不太方便，希望一次能定多天的。
3)我有時選了一個菜，前臺卻說這個菜沒有了！
4)能不能提供多家餐館選擇？
5)訂餐標準才8元，現在物價都漲了，能不能提高一下標準？
6)能不能直接連到餐館的網頁上去看菜式？
7)能不能做口味分析和營養分析？
系統能用起來，問題肯定多多，沒問題反而說明沒有人用這個系統，所以有問題是好事，但問題多了又會讓人很煩躁，改來改去沒完沒了啊，項目的成本也會持續上升。
你準備如何招架呢？在繼續閱讀之前，請你逐一分析上述問題并提出解決方案，要寫下來奧！
下面我們來逐一分析上述問題。
1)要經過好幾個頁面才能進入訂餐頁面，不太方便，希望能在首頁直接進入訂餐頁面。
2)一次只能定一天的餐，不太方便，希望一次能定多天的。
我們首先要思考，這兩個要求背后的需要是什么呢？這兩個問題都是在實際使用訂餐系統中產生的，用戶提出這樣的要求無非是希望系統更加好用更加方便，訂餐系統無非是要方便大家訂餐、減少訂餐時間，故這兩個要求應該予以滿足。
系統上線后，用戶往往會提出很具體的修改要求，這些要求往往是易用性方面的問題，如：界面布局、操作方式、文字表達、排序條件等細節問題，這些問題不解決的話會降低用戶體驗，此類問題一般應盡量解決。
前期對項目的需要把握得比較好的話，軟件基本上是能符合用戶的需要的，哪怕用戶提出了一些易用性方面的要求，一般也是很容易修改的。不過誰也不能保證對需要的理解沒有偏差，有可能系統上線后才發現理解錯了客戶的真正需要，這時修改系統的話一般來說工作量會比較大，但原則上應該給予修改，雙贏是項目的目標，客戶關鍵需要沒有滿足，項目不能算成功。
3)我有時選了一個菜，前臺卻說這個菜沒有了！
5)訂餐標準才8元，現在物價都漲了，能不能提高一下標準？
會什么會有選了菜但沒有這個菜的問題呢？是軟件的bug嗎？
原來餐廳的菜單會定期更換，前臺會及時更新訂餐系統的菜單，但問題是餐廳修改菜單并不是很準時，而且修改后又不一定能及時通知前臺，導致有時會出現員工按照老菜單訂餐，但實際上餐廳已經修改了菜單的情況。
第二個問題是午餐標準的問題，明顯不是系統的問題，但用戶還是提出來了，他們難道不知道不是系統的問題嗎？為什么還要對我們提出來？是不是希望我們向公司領導反應問題？
軟件有些問題，并不是軟件本身的問題，而是管理的問題。要用好一套系統，必須配套相應的管理辦法，很多管理的問題軟件是不能解決的。第一個問題，要改善的話則需要加強對餐廳的管理，讓他們及時送上更新后的菜單；而對于第二個問題，則需要公司檢討訂餐標準是否合適了。
項目組遇到客戶提出這類問題時，不要因為不是軟件問題就事不關己，應主動分析問題并提供適當的解決方案，很多問題只需要在管理上稍微改善一下，問題就可以立馬解決。
4)能不能提供多家餐館選擇？
為什么用戶希望選擇多家餐廳呢？有人喜歡吃辣菜，有人喜歡吃粵菜，有人想吃粥粉面，就算是同一個人也會今天喜歡這個明天喜歡那個，如果能有多家餐廳可供選擇，則更能滿足大家的口味了。大家能吃到自己喜歡的午餐，更有利于大家做好工作，從這點看似乎這個要求是滿足需要的，我們應該予以滿足。
要實現這點，軟件自然要費點周折去修改，但問題遠遠沒有這樣簡單，管理上會變得麻煩很多：前臺需要從多家餐館獲取菜單，要管理多家餐館；財務要對多家餐館進行結帳；更麻煩的是，有些餐館要訂餐數量多才會送餐，如果哪天某餐館點的餐不夠多，還需要選擇了這個餐館的員工重新訂餐。這樣復雜的管理，軟件應該如何來適應呢？
看來如果寄望通過修改軟件來滿足這個要求，就會陷入一個“無底洞”，似乎無論怎樣做都難以滿足要求。實際項目中，經常會遇到這類問題，這時一定要認真地分析：
- 深入思考修改要求背后的需要是什么。
- 如果要滿足該要求，在軟件和管理辦法上需要做什么改變，代價有多大。
- 如果不滿足這個要求，影響會很大嗎？
中午飯是工作餐，主要目標是方便快捷，員工哪怕吃不到最想吃的，也可以選擇吃第二、第三想吃的，中午餐的預算也不可能很大，沒有必要將午餐搞得很復雜很豐富，故這個要求可以不滿足。
如果我們再動動腦筋，還是有簡單易行的辦法來解決這個問題的：員工可選擇在公司統一訂餐，也可以選擇自己解決，無論哪種方式都享受公司的午餐補貼，如果在公司統一訂餐，則只能選擇一家餐廳。這樣員工如果圖方便，又覺得統一訂餐的那個餐廳合適，就可以選擇使用訂餐系統來訂餐；如果覺得想吃點別的，甚至是自己帶飯，那就自己解決唄，反正午餐補貼是照樣享受的。
6)能不能直接連到餐館的網頁上去看菜式？
為什么有這樣新奇的要求呢？訂餐標準才8元，這樣的餐廳會有網頁嗎？
有時候用戶會突發奇想，提出一些新奇怪異的要求，這時候要思考他的動機是啥了。由于客觀條件限制，或者技術上做不到的，要予以拒絕。
為什么會有人想去看餐館的網頁呢？有可能是某些員工想了解一下餐館的信息，好方便他和家人平時去撮一頓，如果是這樣的原因，那只需要告訴他一些餐廳的網址就可以了。
7)能不能做口味分析和營養分析？
口味分析的意思就是希望系統能根據平時你的訂餐情況，自動推薦你下次點什么菜。營養分析則是根據你訂餐偏好，分析你的餐飲是否合理。這兩個功能實在是太高級了，如果真的要做，那么系統需要增加數據挖掘的功能，這可是高技術含量的噢！
那到底要不要滿足這個要求？這個要求其實已經超出了本系統的需要了，可以認為是對之前需要的升華，目前就算不滿足也不會影響客戶當前的使用，但如果要實現的話會導致項目成本上漲，對于這樣的情況，可建議客戶考慮項目的“二期”。
系統上線了，客戶給你的挑戰就會陸續而來，上述幾個問題是實際工作中常見的幾類問題：
對于符合需要的易用性方面的要求，應盡量滿足。
- 有些問題可通過改善管理辦法來解決。
- 有些問題需要同時在軟件和管理辦法上做工作來改善。
- 客戶一時沖動的要求，可另辟蹊徑解決。
- 客觀條件做不到的、技術上做不到的，應予以拒絕。
- 超出范圍的要求，可引導客戶做第二期。
?
5. 領導“突發奇想”
你好容易滿足了大家提出來的各類要求，這回到領導“突發奇想”了！
事情是這樣的，領導發現盡管有了訂餐系統，但有時候某些員工因為請假或者外出工作，不能及時在網住上訂餐，中午回到公司時沒有飯吃。領導就萌生一個想法，不在公司的員工能通過手機短訊來訂餐就好了！
于是領導對你下達了要求，讓你帶領訂餐系統項目組完成這個新功能。
請你先思考這些問題：
1)領導這個要求的需要是什么？
2)如果要做這個功能，人機是應該如何交互？
3)要實現這個功能，要增加什么設備？軟件要怎樣修改？
你開始揮汗如雨地干起來了，這個要求可不簡單啊！
1)要購買發短信的設備，要研究這些設備的開發接口。
2)手機屏幕這么小，而且只能通過短信來交互，如何選菜單、定餐、取消訂餐等細節都需要想清楚。
手機訂餐功能終于做出來了，但這個系統還時靈時不靈，問題是出在軟件、硬件，還是中國移動都搞不清楚，領導大發雷霆，這樣的小事情，怎么搞成這樣？！
后來有人提出來，不在公司的員工，打電話回公司告訴前臺吃什么，不久搞定了？
頓時全世界一片哇然，你一屁股栽倒到地上！
領導要解決的問題其實只是要方便不在公司的員工能及時訂餐，而領導提出來的通過手機來訂餐是領導自己提出來的一個解決方案而已。我們的客戶往往就會直接將他們想像中的解決方案提出來，從而讓你忽略掉他的真正意圖，當按照客戶的解決方案去做的時候，往往不能命中真正的需要，費時費力又不討好。當提出具體修改要求的人是領導級人物時，項目組更加是手足無措，唯領導命令是從。
作為項目組，任務時候都必須比客戶更加清醒，不要埋怨客戶的變來變去，絕大部分客戶是理性和聰明的，只是我們不夠厲害，不能分析出客戶真正之需要。客戶其實不是出錢讓你按照他的要求去做，而是讓你處于他的角度，提出高性價比的解決方案，滿足他的真正需要。
6. 榨干人腦汁的需求分析
需求分析最核心的問題就是搞清楚客戶到底想要什么！客戶通常只會有朦朧的大概的想法，他們提出來的需求，往往只是表面的、不全面的，甚至是匪夷所思、互相矛盾的，我們需要透視它的本質。如果我們能說出客戶內心深處真正想要的，而客戶又不能直接表達出來的東西，我們才能真正做到“為客戶帶來價值”！
有很多方法能幫助我們搞清楚客戶真正之需要，如問卷調查、訪談、用例圖、用戶故事等，還有前文介紹的“需求分析大道理”，事實上這些都不是提高需求分析能力的根本方法。需求分析的大道理、方法論這些最多讓你開闊了研究，但基本上難以幫助你解決項目中需求分析的實際問題。上文的訂餐系統，看上去簡單，但也足夠讓你抓狂！沒有深厚的功底，是難以做好需求分析工作的。
要具備怎樣的技能才能成為需求分析高手呢？
圖5 需求分析高手
需求分析能力的提高，依靠長期的積累，長期的實踐！以下是一些建議：
1)不要以為學過了一些需求分析知識，就以為自己很厲害，也不要用這些大道理來指導項目組工作，不僅對項目組毫無實際幫助，還會幫倒忙。
2)不要一畢業就直接投身需求分析的工作，最好還是從編碼開始，另外也可以考慮做測試、實施。
3)要不斷地積累業務知識、技術知識。
4)學習面向對象分析、面向對象設計，并在實際工作中運用，面向對象分析與設計的方法，會從本質上提高你發現問題、分析問題、提煉問題、解決問題的能力。從這點上說，從開發開始是最好的選擇。
5)把握一切能提高你表達能力與理解能力的機會，和別人溝通要及時表達出你對別人說話的理解，平時多寫文章、博客之類的，提高你的書面表達能力。
6)為什么強調要有豐富的管理和被管理的經驗呢？訂餐系統中其實我們看到很多跟管理相關的問題，很多問題是需要管理辦法去解決的，缺乏管理和被管理的經驗，就會難以理解客戶的問題，更加是無從從管理上提出具體的解決辦法。
需求分析是榨干人腦汁的活，超具挑戰性的工作！要站在比客戶更高的角度把握住客戶的需要，然后將客戶的這些需求轉化為軟件可實現的需求規格，與此同時還需要為客戶提供與軟件相匹配的管理意見。你做好準備迎接這樣的挑戰了嗎？
7. 變被動為主動
大部分情況下，需求分析的工作總是比較被動的，總會有點被客戶牽著鼻子走的感覺，為什么會這樣呢？看看下圖：
這個圖表示了隨著項目的開展，客戶與項目組對本項目的需要的認知程度是怎樣變化的，橫軸是時間，豎軸是對需要的認知程度。這個圖說明了這些問題：
1)項目最開始時，客戶對需要認知程度比較高，而項目組只是有朦朧的認識。
2)隨項目的開展，客戶和項目組都逐步提高了認識。
3)整個項目開展過程中，客戶對需要的理解程度總是比項目組要高。
以上該圖反應了絕大部分項目的情況，這樣的項目客戶對需要的理解永遠領先于項目組，這樣項目就不可避免地會陷入被動的境地。項目組做出來的東西往往不是客戶真正想要的，要反復多次，但做出來后，客戶又會繼續有新的要求，周而復始，沒完沒了，客戶和項目組都相互不滿對方的表現，最終項目很可能是“雙輸”。
如果是下面這個圖呢？
在項目初期，客戶對需要的理解程度是比項目組要高的，但項目組的學習能力比較強，對需要的理解很快就超越了客戶，并且在后面持續領先于客戶。
按照這樣的曲線，項目成功的機會是很高的，只要項目組對需要的理解領先于客戶，就能化被動為主動，最終達到雙贏！
很多公司會接手很多新項目，這些項目之前是沒有什么積累的，保證這類項目成功的關鍵，就是要提高項目組的整體水平，人的水平是決定因素，不要指望什么用過程大框框能改善項目情況，更加不要指望那些半桶水的QA來監督項目組。
下面這個圖呢？
什么情況下會是這樣？
產品化的項目！
產品化的項目才是公司持續盈利之道，所有公司都需要積累自己的業務與技術知識，將項目產品化。但凡產品化的項目，項目組對需要的理解要比客戶深刻很多的，客戶會很崇拜你、認可你，在項目開展過程中，項目組要不斷地去提高客戶的業務水平，同時學習項目中特有的產品中沒有的東西，將這些新內容提煉到產品中來，為下一個項目服務。
變被動為主動的奧妙就在此！提高需求分析能力沒有捷徑，努力提高水平吧！
8. 最后的瘋狂
訂餐系統的故事還沒有結束，過了一段時間，大家的抱怨陸續又來了！
來自員工的抱怨：
有些員工覺得A餐廳好吃，有些又覺得B餐廳好吃。
有些喜歡吃辣，有些喜歡吃湯粉湯面之類的。
有些一會喜歡這個，一會喜歡那個。
很多員工強烈要求支持多家餐廳！
有些員工想自己帶飯回來吃，但公司不會給予午餐補助。
前臺的抱怨：
員工有時向她抱怨餐廳送餐慢，她也沒辦法，已經催了n次，換了幾家餐廳了。
不太同意要支持多家餐廳，她的管理工作會麻煩很多，而且有些餐廳訂餐少的話不會送餐的。
多家餐廳時，需要維護多家餐廳的菜單，而且每家餐廳的菜單更新時間不一樣。
財務的抱怨：
不太同意支持多家餐廳，因為財務需要每家餐廳都提供發票，而不是每家餐廳都能提供發票的，除非我們愿意出更多的錢。
開發人員的抱怨：
不是吧，這班人這么難服侍，還有需求變更啊…
支持定多天的餐和支持多家餐廳其實是有矛盾的，而且也很難實現！
領導的抱怨：
這么簡單的訂餐系統，怎么搞得這么復雜！
我的這么美好的想法，居然惹下這么大的麻煩?
另外一個領導的抱怨：
員工在辦公室內吃飯，搞得辦公室氣味怪怪的。
有些員工還不講究衛生，把桌子、地面弄臟又不搞干凈！
你準備如何應對呢？
往下閱讀之前，請你運用前面所學的知識認真全面深入地思考，以上問題的根源是什么呢？為什么訂餐系統的問題會沒完沒了呢？
或許本不該上這樣的系統，每一種解決方案都不會解決全部的問題，而且都會帶來新的問題，投入這么多到底值不值？
下面這個解決方案又如何呢？
1.所有員工的午餐標準提升到每日10元，無論是否在公司，每月都按22.5工作日提供補貼。
2.公司中午休息時間由1小時延長到1.5小時，調整上午下班與下午上班時間，與其它公司“錯峰”。
3.公司不再統一訂餐，也不允許員工在自己座位上吃午飯，公司指定吃午飯場所，讓專人負責清潔。
第一點措施提高了員工的福利，這措施應該是很受員工歡迎的，也可以抵消員工因為不能公司統一訂餐帶來不便而引發不滿情緒，當然如果補貼標準更高員工會更高興。
第二點措施，中午上下班時間盡量與別的公司“錯峰”，這樣可減少擠電梯還有在餐館排隊等候的時間，這也是很實在的措施。
至于第三點是用來解決衛生問題的，本來如果所有人都非常高尚，是不會有這樣的問題的，但至少短期內不可能讓所有人都高尚，指定場所和專人負責清潔是當前最有效的解決衛生問題的辦法了。
其實很多大企業不會統一訂餐的，也不會讓員工在辦公區內吃東西，好像有點不人性化，其實也是有道理的。
折騰了這么久，結局原來是這樣？真是不勝唏噓啊！需求分析過程是一個很考驗人很折騰人的過程，好好總結本文所列舉的各種情況，做好準備繼續接受來自工作中的挑戰吧！
版權所有，轉載請注明以下信息：
作者：張傳波
www.umlonline.org
------全文完------
本文對應的視頻課程：http://www.cnblogs.com/umlonline/archive/2011/07/20/2111430.html
如果你覺得本文對你有幫助，麻煩點擊一下“推薦”，謝謝！
轉載于:https://www.cnblogs.com/umlonline/archive/2011/08/01/2123656.html
總結
以上是生活随笔為你收集整理的需求分析挑战之旅——疯狂的订餐系统的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 对象化下的编程——字段
- 下一篇： 也议GetLastKnownLocati