摘要：
說教性質的需求分析理論，各位看了也白看，所以咱們就來一個真實個案——“訂餐系統(tǒng)”體驗一下。
“訂餐系統(tǒng)”貌似簡單，但陷阱重重，各種需求分析的經典場景將會一一重現(xiàn)，各位做好準備接受這個挑戰(zhàn)沒有？
1.1某IT公司員工的吃飯問題
咱們出來干活的，天天需要吃午飯，所謂“午飯吃不好，工作干不好”。某IT公司深知這個道理，為了讓大家方便吃午飯，由公司統(tǒng)一訂餐，并且費用全包。
這樣的做法，大家當然開心了，不過行政部的同事就要辛苦一點，每天要“服侍”大家吃飯，我們看看怎樣個做法：
文員每天都要向餐廳索取最新菜單，然后拿著菜單找每個人確認今天吃什么。
大家都確認后，文員以電話或者傳真的方式，向餐廳訂餐。
餐廳送來午飯，文員通知大家，然后大家來取餐。
這樣的做法維持了一段時間，但是問題逐漸就來了。
員工A抱怨：我明明點了酸菜魚，干嘛給我送來紅燒魚。
員工B抱怨：我剛才去開會了，沒有點餐，怎么就這樣把我的餐給漏了？
員工C抱怨：我對中午飯要求不高，每天吃麻辣牛肉就可以了，不需要天天來問我吃啥，打斷我的工作。
......
大家都開始來責怪文員了。
文員受了一肚子的委屈，她解釋如下：
有些人寫的字不太清楚，有時會搞錯；
公司這么多人，有人上廁所有人去開會，我哪能保證每次都不漏人。
我按員工C說法做了，沒有再問他了，但有一天取餐的時候，他說上火，不吃麻辣牛肉，要我換！都定了，怎么換??？保險起見，我以后天天都問他了。
嗚嗚......
公司領導覺得問題責任不在于文員，而是這樣的訂餐方式太落后了，導致諸多問題！好歹是一個IT公司嘛，訂餐也需要信息化！于是領導萌生了要做一個訂餐系統(tǒng)的想法。
于是咱們的好戲就開始了......
1.2 需求分析的大道理
你非常光榮地接受了這個任務，領導任命你為訂餐系統(tǒng)的項目經理，你會如何展開需求分析工作呢？
可能你會這樣想：那還不容易，這么簡單的系統(tǒng)，直接編碼就行了，還寫什么需求！
伙計，不要沖動，看到這里請你先停止閱讀，找張紙和筆，用你自以為合適的方式列出這個系統(tǒng)的需求。
請寫完后才繼續(xù)往下看噢！
不聽話了？沒寫完就往下看？
咱們先說說需求分析的一些大道理：
首先我們需要明確項目的背景，我們要回答這些問題：也就是為什么會有這個項目？
客戶為什么想做這樣的一個項目？如果沒有這個項目會怎樣？
了解背景的基礎上，我們需要進一步了解以下內容：
1)本項目解決了客戶的什么問題？
2)本項目涉及到什么人、什么單位？
3)本項目的目標是什么？
4)本項目的范圍是怎樣的？
5)本項目的成功標準是什么？
以上這些內容，我們稱之為客戶的“需要”。
接下來，就可以定詳細的需求規(guī)格說明書了，一般我們會對功能性需求和非功能性需求都列出詳細的要求，我們這里把這些要求定義為“需求規(guī)格”。
對于功能性需求，我們往往會描述成用例圖。
對于非功能性需求，往往會對系統(tǒng)穩(wěn)定性、性能、兼容性等提出要求。
什么是背景？
背景這東西比較籠統(tǒng)，簡單地說就是這個項目的來由，我們需要用說故事的方式講清楚項目的背景。
什么是需要？
需要就是客戶真正想要的東東，是高層次的需求，我們可以把需要解決的問題、關鍵涉眾、項目的目標、范圍、項目成功標準等全部統(tǒng)稱為需要。
什么是需求規(guī)格？
需求規(guī)格是很細級別的但又沒有細到詳細設計程度的需求了，描述出系統(tǒng)與用戶是如何交互的，系統(tǒng)要滿足怎樣的一些非功能要求。
需求分析過程，無非就是由背景到需要到需求規(guī)格的過程，這個過程是螺旋前進的。需求分析中最難解決的問