：沒有技術背景很難真正成為乙個優秀的軟體需求分析師，最多也就是乙個業務需求分析師。
：
菜鳥的軟體需求分析知識體系架構
個人認識：
我以為對於軟體需求來說，我感覺並不需要什麼具體的知識體系，會侷限我們的想法（我的意思是不要讓思想拘束起來，解決了本質問題的就是好方法），私以為：需求的目的是做出「符合」的軟體，使用者想要的和軟體功能的符合。
而問題是如何將使用者的想法準確的傳達給程式設計師（或者說下一層人員）。我們只要將使用者想要的表達清楚即可，當然這也需要一定的知識和技術，吸取前人的經驗。
總結：業務理解+需求分析技術
基本技術知識體系：
圖：
體系的個人理解：
需求捕獲/調研：
是乙個與所有利益相關方積極溝通，收集他們的需要，清楚表達他們的問題，明確並協商潛在的衝突，並建立乙個專案的清晰界限。也可以說給使用者乙個機會去解釋他們的問題和需求以及他們想要新系統幹什麼的過程。
經驗
1要在他們心目中樹立自己的職業威信
2我們在進行需求調研的時候，什麼部門的需求就應當跟什麼部門談。同時，縱向又可以劃分為多個層次，如高層領導、中層領導與基層人員.
3召開乙個專案啟動會議，與各種角色、各個型別的客戶建立了聯絡
4需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工作
5集中式的業務研討劃分業務組，可以讓業務人員分別在自己最熟悉的業務範圍內參與討論，可以有效提高業務討論的質量
6需求分析不是一蹴而就的，是乙個反覆迭代的過程。它將從第一次需求分析開始，一直持續到整個專案生命週期
7。。。。
需求分析：
1每次參加完需求調研回到公司，我們就應當對需求調研的成果進行一次需求分析
2將上次需求分析的結果與客戶進行確認，同時對需求分析中提出的疑問交給客戶予以解答
3需求分析不是一項一蹴而就就可以完成的工作，它需要乙個長期的過程，而這個過程是乙個由粗到細的過程
4對乙個系統進行功能和角色方面的梳理和分析，可以採用的比較主流的方法之一就是繪製用例圖
5細化需求也需要一定的方法與思路。一般來說，我們可以有兩個方向細化需求：業務流程分析與業務領域分析
6編寫用例說明
7.。。。
需求驗證：
1一次簡單的口頭複述不足以滿足需求分析的需要。因此，需求確認是一系列的確認過程，每次確認都可能需要與不同的人，在不同層次的確認。最終應當形成到紙面，形成文件性的東西，雙方簽字確認。這個過程中可以採用的乙個好的方法就是原型法，最終產物應當是需求列表與需求規格說明書，最後結束於一場需求評審會，或者簽字確認會。
2我們都要如實記錄原始的需求，並以此來驗證我們最終的軟體。這個如實記錄原始需求的文件，就是需求列表。
3乙個需求列表的例項
4快速原型法
5需求規格說明書
6評審與簽字確認會
7.。。。
需求規範：
就是寫的正規點
《軟體需求與分析》
在我看來，軟體需求與分析，說的就是我們這些程式設計人員要理解客戶的需求，分析客戶想要的究竟是什麼，來做出使客戶滿意的作品。專案經理在和客戶溝通的時候要清晰地理解客戶的需求，這將為後續的軟體設計打下良好的 基礎。需求調研 需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點 既是乙份體力活兒...
軟體需求與分析 問題賬戶需求分析
案例 某大銀行的一位銀行卡辦公室的收賬經理liz遇到了乙個問題。她每週都收到乙份過期未付款的賬戶名單。這份報告已經從兩年前的250個賬戶增加到現在的1250個賬戶。為了確定那些嚴重拖欠債務的賬戶，liz需要通讀這份報告。嚴重拖欠債務的賬戶由幾個不同的規則確定，每個規則都要求liz檢查客戶的一項或幾項...
軟體需求分析
本章共分為四個部分，一軟體需求的任務和過程 二結構化分析方法 三，原型化方法四，動態分析方法。本章學習的要點是 1。了解軟體需求分析的目標和任務 2.了解軟體需求的獲得方法 3.掌握結構化的分析方法 4.了解需求規格說明和需求評審的主要內容。軟體需求分析的主要任務 深入描述軟體的功能和效能 確定軟體...