需求分析的大道理

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

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

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

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

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

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

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

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

1)本專案解決了客戶的什麼問題？

2)本專案涉及到什麼人、什麼單位？

3)本專案的目標是什麼？

4)本專案的範圍是怎樣的？

5)本專案的成功標準是什麼？

以上這些內容，我們稱之為客戶的「需要」。

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

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

圖2 用例圖

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

什麼是背景？

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

什麼是需要？

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

什麼是需求規格？

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

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

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

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

目標在**？

對於「專案的目標」，專案組普遍的問題有：

1.根本不知道「目標」這回事。

2.目標寫出來了，但被扣上「大而虛」的帽子。

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

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

需求規格優先

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

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

下面，我們將來挑戰「訂餐系統」的背景、需求和需求規格。

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

**

小故事 大道理

小故事 大道理 1.父子二人經過五星級飯店門口，看到一輛十分豪華的進口轎車。兒子不屑地對他的父親說 坐這種車的人，肚子裡一定沒有學問！父親則輕描淡寫地回答 說這種話的人，口袋裡一定沒有錢！你對事情的看法，是不是也反映出你內心真正的態度？2 晚飯後，母親和女兒一塊兒洗碗盤，父親和兒子在客廳看電視。突然...

小故事,大道理

休息的時候看一些小故事,學會一下道理,還是很不錯的.1 斷箭 不相信自己的意志，永遠也做不成將軍。春秋戰國時代，一位父親和他的兒子出征打仗。父親已做了將軍，兒子還只是馬前卒。又一陣號角吹響，戰鼓雷鳴了，父親莊嚴地托起乙個箭囊，其中插著乙隻箭。父親鄭重對兒子說 這是家襲寶箭，配帶身邊，力量無窮，但千萬...

小故事大道理

一 關於壓力 各位認為這杯水有多重？說著，講師拿起一杯水。有人說二百克，也有人說三百克。是的，它只有二百克。那麼，你們可以將這杯水端在手中多久？講師又問。很多人都笑了 二百克而已，拿多久又會怎麼樣！講師沒有笑，他接著說 拿一分鐘，各位一定覺得沒問題 拿乙個小時，可能覺得手痠 拿一天呢？乙個星期呢？那...