需求分析的大道理

你非常光榮地接受了這個任務，上司任命你為訂餐系統的項目經理，你會如何展開需求分析工作呢？

可能你會這樣想：那還不容易，這麼簡單的系統，直接編碼就行了，還寫什麼需求！

夥計，不要沖動，看到這裡請你先停止閱讀，找張紙和筆，用你自以為合适的方式列出這個系統的需求。

請寫完後才繼續往下看噢！

不聽話了？沒寫完就往下看？

咱們先說說需求分析的一些大道理：

首先我們需要明确項目的背景，我們要回答這些問題：也就是為什麼會有這個項目？客戶為什麼想做這樣的一個項目？如果沒有這個項目會怎樣？

了解背景的基礎上，我們需要進一步了解以下内容：

1)本項目解決了客戶的什麼問題？ 2)本項目涉及到什麼人、什麼機關？ 3)本項目的目标是什麼？ 4)本項目的範圍是怎樣的？ 5)本項目的成功标準是什麼？ 以上這些内容，我們稱之為客戶的“需要”。

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

圖1 背景、需要、需求規格

對于功能性需求，我們往往會描述成用例圖。

圖2 用例圖

對于非功能性需求，往往會對系統穩定性、性能、相容性等提出要求。

什麼是背景？

背景這東西比較籠統，簡單地說就是這個項目的來由，我們需要用說故事的方式講清楚項目的背景。

什麼是需要？

需要就是客戶真正想要的東東，是高層次的需求，我們可以把需要解決的問題、關鍵涉衆、項目的目标、範圍、項目成功标準等全部統稱為需要。

什麼是需求規格？

需求規格是很細級别的但又沒有細到詳細設計程度的需求了，描述出系統與使用者是如何互動的，系統要滿足怎樣的一些非功能要求。

需求分析過程，無非就是由背景到需要到需求規格的過程，這個過程是螺旋前進的。需求分析中最難解決的問題往往就是搞不清需求之根源，把握不清背景和需要，往往就會被繁瑣的需求規格所困住，被客戶牽着鼻子走。理論是完美的，現實是殘酷的，我們現實的需求分析工作，往往會出現這些問題：

背景啊背景，我該如何寫你呢？

我們公司的需求規格說明書中，第一章節就是“背景”，但往往大部分項目寫出來的背景寫了等于沒寫。有些寫了諸如此類的内容：某年某月某日與某某公司簽訂了某某合同，成立了改項目組，項目人員有誰誰誰，客戶聯絡人是誰誰誰。有些項目更懶，直接複制前期需求文檔的背景，以緻項目已經做到第三期了，第三期的背景仍然是抄第一期的。不知道如何分析背景，背景不知道寫啥，這是項目的普遍現象。

目标在哪裡？

對于“項目的目标”，項目組普遍的問題有：

1.根本不知道“目标”這回事。

2.目标寫出來了，但被扣上“大而虛”的帽子。

3.沒有用目标來指導下一步工作，後面遇到具體問題時，沒有用目标來思考。

4.目标寫出來就不變了，沒有持續去思考是否需要調整。

需求規格優先

很多需求分析人員喜歡将系統要做的事情，以用例或者功能點的方式記錄下來，但往往沒有記錄為什麼需要這樣一個用例或者是功能點，沒有去思考這個用例或者功能點背後隐藏的客戶需要是什麼。更甚者進入具體的界面設計，在需求文檔中寫清楚界面上放什麼按鈕什麼菜單等，一開始就将需求“僵化”，這樣會讓後面的工作陷入“萬劫不複”之地。

本小結開始的時候，要求你先寫下本系統的需求，再繼續往下看。不知道你寫的需求中是否有背景、需要這些内容呢？你寫的需求是不是幾乎全部是“需求規格”呢？

下面，我們将來挑戰“訂餐系統”的背景、需求和需求規格。

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

本文轉自左正部落格園部落格，原文連結：http://www.cnblogs.com/soundcode/archive/2011/07/20/2111659.html，如需轉載請自行聯系原作者