經驗人 1 ：沒有技術背景很難真正成為一個優秀的軟件需求分析師，最多也就是一個業務需求分析師。

經驗人2 ：軟件需求在整個軟件生命周期中的定位來看，其上接業務，下接設計和技術。從這個概念上來講軟件需求人員必須具備業務和技術兩個方面的能力。

菜鳥的軟件需求分析知識體系架構

個人認識：

我以為對於軟件需求來說，我感覺並不需要什麽具體的知識體系，會局限我們的想法（我的意思是不要讓思想拘束起來，解決了本質問題的就是好方法），私以為：需求的目的是做出“符合”的軟件，用戶想要的 和軟件功能的符合。

而問題 是如何將用戶的想法準確的傳達給程序員（或者說下一層人員）。我們只要將用戶想要的表達清楚即可，當然這也需要一定的知識和技術，吸取前人的經驗。

總結：業務理解 + 需求分析技術

基本技術知識體系：

圖：

體系的個人理解：

需求捕獲/調研：

是一個與所有利益相關方積極溝通，收集他們的需要，清楚表達他們的問題，明確並協商潛在的沖突，並建立一個項目的清晰界限。也可以說給用戶一個機會去解釋他們的問題和需求以及他們想要新系統幹什麽的過程。

經驗

1要在他們心目中樹立自己的職業威信

2我們在進行需求調研的時候，什麽部門的需求就應當跟什麽部門談。同時，縱向又可以劃分為多個層次，如高層領導、中層領導與基層人員.

3召開一個項目啟動會議，與各種角色、各個類型的客戶建立了聯系

4需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工作

5集中式的業務研討劃分業務組，可以讓業務人員分別在自己最熟悉的業務範圍內參與討論，可以有效提高業務討論的質量

6需求分析不是一蹴而就的，是一個反復叠代的過程。它將從第一次需求分析開始，一直持續到整個項目生命周期

7。。。。

需求分析：

1每次參加完需求調研回到公司，我們就應當對需求調研的成果進行一次需求分析

2將上次需求分析的結果與客戶進行確認，同時對需求分析中提出的疑問交給客戶予以解答

3需求分析不是一項一蹴而就就可以完成的工作，它需要一個長期的過程，而這個過程是一個由粗到細的過程

4對一個系統進行功能和角色方面的梳理和分析，可以采用的比較主流的方法之一就是繪制用例圖

5細化需求也需要一定的方法與思路。一般來說，我們可以有兩個方向細化需求：業務流程分析與業務領域分析

6編寫用例說明

7.。。。

需求驗證：

1一次簡單的口頭復述不足以滿足需求分析的需要。因此，需求確認是一系列的確認過程，每次確認都可能需要與不同的人，在不同層次的確認。最終應當形成到紙面，形成文檔性的東西，雙方簽字確認。這個過程中可以采用的一個好的方法就是原型法，最終產物應當是需求列表與需求規格說明書，最後結束於一場需求評審會，或者簽字確認會。

2我們都要如實記錄原始的需求，並以此來驗證我們最終的軟件。這個如實記錄原始需求的文檔，就是需求列表。

3一個需求列表的實例

4快速原型法

5需求規格說明書

6評審與簽字確認會

7.。。。

需求規範：

就是寫的正規點

軟件需求與分析 - 認識