摘要：
說教性質的需求分析理論，各位看了也白看，所以咱們就來一個真實個案——“訂餐系統”體驗一下。“訂餐系統”貌似簡單，但陷阱重重，各種需求分析的經典場景將會一一重現，各位做好準備接受這個挑戰沒有？我將分8篇為大家分享，全部內容超過1萬1千字，而且有n多圖片和思考題，請準備好盒飯邊吃邊看吧……

??

大綱：
1.某IT公司員工的吃飯問題
2.需求分析的大道理
3.背景-需要-需求規格
4.沒完沒了的“新需求”
5.領導“突發奇想”
6.榨干人腦汁的需求分析
7.變被動為主動
8.最后的瘋狂

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.本系統應該具備怎樣的功能？
參考答案：

圖4 用例圖

對于“訂餐”這個用例，我們還可以進一步細化用戶與系統的交互：
用戶指示訂餐
系統給出菜單
用戶選擇菜單并 確認選擇
系統保存用戶的選擇，提示訂餐成功。

答案點評：
1)用例圖全面地描述了系統用戶與用例，條理清晰、一目了然。
2)對于每一個用例，還可以進一步描述用戶與系統是如何交互的，為下一步工作做好準備。
3)除了描述功能，還需要考慮系統的非功能需求，如性能要求、安全性要求等。
應該如何描述功能？
1)要根據前面的問題導出系統應具備的功能以及非功能需求。
2)用例圖是描述功能性需求的好工具，但不要拘泥于只用用例圖。
3)對于非功能性需求，客戶往往沒有具體想法，需要我們從客戶的需要出發，定出具體的非功能性需求。

7.本項目成功標準是怎樣的？
參考答案：用簡單的方式達到目標的要求，達致雙贏。
答案點評：
1)“簡單”意味著成本低，符合雙方利益。
2)達到目標要求是真正的客戶所需。
如何考慮項目的成功標準？
我們做一個項目，成功標準并不是為了賺錢，更加不是不惜一切謀取最大利益，雙贏才是最重要的原則！對于客戶來說，首要目標就是要滿足他的需要，然后就是合理的預算，對于 軟件公司來說，首要目標就是為客戶提供高性價比的解決方案，賺取合理利潤。要達致雙贏，客戶的成熟度是很重要的，但更重要的是軟件公司的成熟度，項目組需要以專家、顧問這樣的高度來解決項目中的問題，引導雙方達至雙贏。

以上7個問題，問題1是背景相關的問題，問題2、3、4、5是需要相關的問題，問題6是需求規格相關的問題，而問題7是我們需要認真考慮的問題，考慮清楚項目的成功標準才能更好地指導項目后續工作，提高項目成功概率。

請看下一篇……

作者：張傳波

創新工場創業課堂講師

華為某團隊高級顧問

《火球——UML大戰需求分析》作者

www.umlonline.org 創辦人

總結

以上是生活随笔為你收集整理的需求分析挑战之旅（疯狂的订餐系统）(3)——背景-需要-需求规格的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。