首先，最重要的一個問題就是，爲什麼要做需求分析，或者說需求分析的意義是什麼?每個人對這個問題可能都會有不同的體會。我的看法是，需求分析的意義在於準確無歧義地表達項目需要交付的產品，並且獲得需求方的認可，從而爲整個項目建立一個基準。指望需求不變化是幾乎不可能的，不管是開發者還是需求方都有可能隨着項目的進展提出變更的需求，所以需求分析(及變更管理)的目標不是定義一個不會再改變的需求，而是從開發開始到項目結束，雙方對於需求(包括變更後的)的認知都是一致的。
這樣說可能有點抽象，我們可以來拿一個例子進行說明。
比如項目初期形成的需求分析中有這樣一段描述：“應用系統能夠根據預先定義的個性化模板，定期自動對每條用戶的數據生成對應的pdf報告文件，併發送到在用戶信息中預先設定好的電子郵箱中。”針對這條需求，開發人員找到了一個自動生成pdf文件的插件，這個插件會讀取一個xml模板，然後根據傳入的數據生成pdf文件。一段時間後，功能做好了，用戶的項目經理看了生成的pdf覺得不錯，項目進展順利。可是，到了階段驗收的時候，用戶組織了一段時間的試用，對這個功能大家都覺得不滿意，因爲普通用戶根本不會編輯xml模板，覺得很麻煩，而且容易出現格式錯誤。這時，用戶提出應該提供一個編輯界面，讓用戶以所見即所得的方式來編輯模板，這也是很自然的。問題就來了：開發人員認爲這是對需求的變更，需求裏沒有提到要做這麼個界面嘛!這樣會導致項目的進度、預算都需要調整，也許有人還會要求用戶增加開發費用。而用戶會認爲這是開發的工作沒做好，怎麼能做個功能出來讓用戶自己編輯xml呢?一百個用戶裏也難找出一個用戶知道xml是啥東西，更別說編輯它了。所以雙方就會在這個問題上糾纏不清。而這只是整個項目中很小的一塊需求，一葉而知秋，其他部分的問題也肯定少不了。這裏面到底是用戶不講理，還是開發人員偷懶?其實都不是，我覺得問題出在需求定義得不嚴謹。如果開發人員在需求分析過程中和用戶交流過模板的格式問題，用戶會在第一時間明確模板編輯的需求，這樣寫出來的需求可能會是這樣的：“應用系統能夠提供pdf模板編輯功能，讓用戶以所見即所得的方式自行定義個性化模板，根據該模板定期自動對每條用戶的數據生成對應的pdf報告文件，併發送到在用戶信息中預先設定好的電子郵箱中。”這樣的需求就更嚴謹，事後出現爭議的問題就減少了。當然，你還可以在裏面找出一些不夠嚴謹的地方，比如“定期”是什麼概念，固定一週一次還是一月一次，還是用戶可以自定義，或者是提供幾個標準選項讓用戶自選?所有這些不明確的定義，都是需求分析過程中要重視的。除非你對於它的不確定性及其可能帶來的最壞結果有充分的把握，否則忽略它就會在未來給項目帶來麻煩。
小結一下我的想法：在項目中，用戶的字典裏是單證、收入、報表、審覈等，而開發人員的字典裏則是鍵值、索引、按鈕、事件這些，而需求分析就像是一位翻譯，把用戶的語言和開發人員的語言融合到一起，讓雙方準確理解對方的意思，從而在開始開發工作之前讓雙方都真正明白對方的思路。
對於需求分析中關鍵的因素，我自己的體會主要有如下三點：
一、深刻理解業務
需求分析人員需要對用戶的業務有非常深刻的理解。所謂非常深刻的理解，就是說你能和用戶的管理層就他們的業務問題談笑風生。如果做金融產品不懂風險管控，做論壇不懂SEO，做人事系統不懂組織行爲，如何能對業務有深刻的理解呢?
有人看到這裏要說了，用戶給我講明白需要做什麼功能就行了，我對他的行業瞭解那麼深有什麼必要呢?我想說的是，做需求分析也是分很多層次的，層次越高，需要對業務的理解越深。
我再舉一個例子吧。某個項目要開發一套企業管理系統，客戶是一個企業集團，下屬很多分公司，都在做多條產品線業務，集團對分公司的業務管理一盤散沙的問題很頭疼。之前的做法是每個分公司每個月底將每條產品線的業務報表傳真到集團，然後集團進行業務統計。現在客戶提出的需求是，在每個分公司都部署一套和集團一樣的業務管理系統，並在集團的平臺中做一個數據上報模塊，讓各個分公司都可以從自己系統中導出電子版數據並上傳給集團，從而提高接收和統計的效率。“還可以”的需求分析能夠把這個需求準確描述，嚴謹定義，讓開發人員開發出用戶滿意的功能。
“比較好”的需求分析則可以更進一步，和用戶探討是否可以做成一套大集中的系統，分公司無須上報就可以讓集團隨時看到各個分公司的業務狀況，從而杜絕虛報瞞報數據的問題。“更好的”需求分析也許可以和用戶探討通過信息系統的支持實現矩陣化的業務管理，在不改變組織結構(因爲組織結構問題已經超出需求分析的範疇，甚至超過了項目範圍了)的情況下，提高集團對各條業務線的宏觀管理能力，從而更好地落實集團對於各條產品線的戰略。也許有人還有“更更好的”業務分析，但你可以看到，越深入業務的分析結果對於用戶的價值越大，用戶對整個開發團隊的認可程度也會更高。這對於項目的成功是非常重要的。如果客戶很感謝你提出了讓他能加強業務管控能力的方案，他還會和你糾纏菜單的顏色夠不夠好看麼?
二、充分和用戶溝通
首先要搞清楚你有哪些用戶，他們之間的關係是怎樣的。有句老話叫衆口難調，用戶之間的觀點也會有衝突。比如高管希望採集的數據越多越好，現在用不上將來可能弄個數據挖掘工具就突然有奇效了也說不定;負責採集數據的一線用戶當然希望數據越少越好，只要自己夠用就行了。有些業務部門不希望自己的業務數據被太多人知道，有些項目甚至會讓一些部門失去權力，一些領導丟掉職位。所以在一個項目裏，需求討論會上往往會有各種各樣的聲音。聲音後面是立場，立場後面是利益。缺乏經驗的需求分析人員很容易迷失在這些聲音裏，最後做出來的需求成了四不像，而這正是某些用戶希望看到的結果。這時候怎麼辦呢?老碼農俺有一個祖傳祕方：找用戶最大的領導討論項目的整體思路，然後按大領導的意見把用戶需求篩選一遍，凡是和大領導思路明顯衝突的一律扔到一邊，把符合大領導思路的那些需求充分細化。啥叫大領導?不是什麼IT部經理、信息處處長、客戶項目經理之類的，而是能拍板決定和這個項目相關的業務問題的人，比如做人事系統，大領導至少是人力總監，做財務系統至少是財務總監，當然能再往上讓一把手積極參與進來就更好了。和大領導討論的過程，既是瞭解大領導思路的過程，也是篩選需求的過程，更重要的是，獲取大領導支持的過程。有了大領導的支持，再開會的時候，底下吵吵嚷嚷，你也能氣定神閒，胸有成竹。
有人可能又要嘀咕了：大領導你想見就見，你以爲自己是誰啊?這就又聯繫到我剛纔談的第一個問題，對業務理解的深度。項目啓動的時候，大領導一般例行是要接見一下項目組的，你也會給大領導留下一個印象。如果你張口閉口就是數據庫、表單、Java框架什麼的，大領導和你沒有交集，自然懶得見你，要是你能聊到們最大的競爭對手在這個項目相關的業務領域有哪些優勢劣勢，國外的業務管控經驗等等，你也許能經常成爲大領導的座上賓。所以說，對業務理解的深度是項目成功非常關鍵的。
和用戶的溝通有多種形式，比如需求討論會、高層訪談、用戶討論什麼的。我覺得應該先做很多的一線用戶討論，問很多問題，把所有的業務環節都徹底摸清，順便收集一些表單和數據作爲需求分析的依據。然後再去做高層訪談，瞭解整體思路、戰略、目標一類的宏觀問題。需求討論會一般在後期開，主要是針對某些爭議比較大或者定義不清晰的問題，集思廣益，實際上就是一種頭腦風暴方法。在這些討論中，需求分析人員都不應該只是做一個記錄者，而應該多提問題和建議，用自己的思路去啓發用戶，大膽設想小心求證。但也要注意尊重用戶的意見，不能覺得用戶不懂技術所以我隨便聽聽就行了，怎麼實現是技術的事情，和用戶沒多少關係，這樣往往在後期會出問題。
三、具備深厚的技術背景和嚴謹的思維
需求分析是業務和技術之間的橋樑，需求文檔是一種對用戶的承諾。在寫需求文檔的時候，就需要需求分析人員有相當的技術背景，瞭解每個需求對應的實現途徑、難度、和大致工作量，並且能夠把它以一種業務和技術人員都能無歧義理解的嚴謹表達方式進行描述。當然，這是建立在前面與用戶(包括技術人員)充分溝通的基礎之上的。
有的需求分析人員技術背景不是很強，是不是就做不好需求分析了呢?我覺得倒也未必，這時候就需要團隊的力量了。如果有一個技術很強的開發人員作爲後盾，能夠和你搭檔一起去討論需求，併爲你提供技術方面的意見，讓你能充分發揮自己對業務的理解和溝通的能力，也會是不錯的組合。
寫文檔就考驗需求人員的文字功底了，有時候一句話、一個字都需要反覆推敲，一不小心就有可能給自己挖坑，有點做律師的感覺是不是?要讓業務和技術都看明白的確不容易，這裏俺建議多畫圖，一張圖有時候能抵幾千字。什麼流程圖啊、數據流圖啊、組織結構圖啊、用戶界面示意圖啊什麼的，能畫圖的地方就多畫圖，圖加上文字，讀者的理解就不容易跑偏。
最後，需求文檔寫完了，記得打印出來，核心用戶一人給一本，告知幾天內可以提出一次修改意見，只修改一次就會形成初始需求的定稿，以後再改要走變更控制流程。再印幾本存檔的，最後多一頁簽字確認頁，讓所有收到需求文檔的用戶最後都要簽字確認，最後再給用戶方的項目經理簽字。有簽字確認的存檔就可以作爲將來需求變更的依據了。
有人說，對方項目經理簽字不就行了，爲啥非要所有核心用戶簽字呢?因爲領導們簽字都是很慎重的。如果不需要簽字，他拿着需求隨便翻兩下往抽屜裏一扔，壓根不會仔細看。但是如果三天後需要他一次性提出修改意見，沒有修改意見就簽字認可，這就不一樣了。他就會仔細看，認真提出意見，因爲很少有人會在自己沒仔細看過的東西上簽字的，對不?這樣也是提前幫你檢查了定義不夠嚴謹、將來有可能產生爭議的內容。所以通過這個過程，可以讓核心用戶對需求的理解和開發團隊進行一次同步，真正形成需求的一個基準。
關於需求分析的體會，俺就說這麼多吧。自己水平有限，嘮叨了這麼半天，也不知道有多少有用的東西，還請讀者多多指正。最後其實俺還有一個想法，需求分析是項目經理義不容辭的工作，如果需求很複雜需要一個團隊，項目經理也必須是這個團隊的核心人員。關於項目管理俺也有一些體會，有時間再寫一點東西，博讀者一笑而已。各位看官，預知後事如何，且聽下回分解