你非常光榮地接受了這個任務，領導任命你為訂餐系統的項目經理，你會如何展開需求分析工作呢？
可能你會這樣想：那還不容易，這么簡單的系統，直接編碼就行了，還寫什么需求！
伙計，不要沖動，看到這里請你先停止閱讀，找張紙和筆，用你自以為合適的方式列出這個系統的需求。請寫完后才繼續往下看噢！
不聽話了？沒寫完就往下看？
咱們先說說需求分析的一些大道理：
首先我們需要明確項目的背景，我們要回答這些問題：也就是為什么會有這個項目？客戶為什么想做這樣的一個項目？如果沒有這個項目會怎樣？
了解背景的基礎上，我們需要進一步了解以下內容： 1)本項目解決了客戶的什么問題？
2)本項目涉及到什么人、什么單位？
3)本項目的目標是什么？
4)本項目的范圍是怎樣的？
5)本項目的成功標準是什么？
以上這些內容，我們稱之為客戶的“需要”。

接下來，就可以定詳細的需求規格說明書了，一般我們會對功能性需求和非功能性需求都列出詳細的要求，我們這里把這些要求定義為“需求規格”。

圖1 背景、需要、需求規格
對于功能性需求，我們往往會描述成用例圖。

圖2 用例圖
對于非功能性需求，往往會對系統穩定性、性能、兼容性等提出要求。
什么是背景？
背景這東西比較籠統，簡單地說就是這個項目的來由，我們需要用說故事的方式講清楚項目的背景。
什么是需要？
需要就是客戶真正想要的東東，是高層次的需求，我們可以把需要解決的問題、關鍵涉眾、項目的目標、范圍、項目成功標準等全部統稱為需要。
什么是需求規格？
需求規格是很細級別的但又沒有細到詳細設計程度的需求了，描述出系統與用戶是如何交互的，系統要滿足怎樣的一些非功能要求。
需求分析過程，無非就是由背景到需要到需求規格的過程，這個過程是螺旋前進的。需求分析中最難解決的問題往往就是搞不清需求之根源，把握不清背景和需要，往往就會被繁瑣的需求規格所困住，被客戶牽著鼻子走。理論是完美的，現實是殘酷的，我們現實的需求分析工作，往往會出現這些問題：
背景啊背景，我該如何寫你呢？
我們公司的需求規格說明書中，第一章節就是“背景”，但往往大部分項目寫出來的背景寫了等于沒寫。有些寫了諸如此類的內容：某年某月某日與某某公司簽訂了某某合同，成立了改項目組，項目人員有誰誰誰，客戶聯絡人是誰誰誰。有些項目更懶，直接復制前期需求文檔的背景，以致項目已經做到第三期了，第三期的背景仍然是抄第一期的。不知道如何分析背景，背景不知道寫啥，這是項目的普遍現象。
目標在哪里？
對于“項目的目標”，項目組普遍的問題有：
1.根本不知道“目標”這回事。
2.目標寫出來了，但被扣上“大而虛”的帽子。
3.沒有用目標來指導下一步工作，后面遇到具體問題時，沒有用目標來思考。
4.目標寫出來就不變了，沒有持續去思考是否需要調整。
需求規格優先
很多需求分析人員喜歡將系統要做的事情，以用例或者功能點的方式記錄下來，但往往沒有記錄為什么需要這樣一個用例或者是功能點，沒有去思考這個用例或者功能點背后隱藏的客戶需要是什么。更甚者進入具體的界面設計，在需求文檔中寫清楚界面上放什么按鈕什么菜單等，一開始就將需求“僵化”，這樣會讓后面的工作陷入“萬劫不復”之地。
本小結開始的時候，要求你先寫下本系統的需求，再繼續往下看。不知道你寫的需求中是否有背景、需要這些內容呢？你寫的需求是不是幾乎全部是“需求規格”呢？
下面，我們將來挑戰“訂餐系統”的背景、需求和需求規格。

圖3 某需求規格說明書目錄

轉：http://www.umlonline.org/school/thread-199-1-1.html

總結

以上是生活随笔為你收集整理的需求分析的大道理的全部內容，希望文章能夠幫你解決所遇到的問題。

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