來源于計算機大學生

需求分析師從事的是一個類似技術翻譯的工作，是業務和技術、外部用戶和内部工程師的橋梁。

對外，他能夠與不懂技術的其他行業用戶迅速溝通，了解用戶的想法、要求和目的，整理用戶原始需求的業務規則、業務範圍、業務流程等。對内，他能基于用戶的需求提出技術系統的描述和要求，輸出為開發工程師等内部人員看得懂的文檔（比如流程、方案、界面、UML圖、需求規格說明書等），讓内部的開發、測試、項目經理等人員理解用戶想要的東西，然後在遵守項目流程要求的基礎上實現滿足用戶需求的東西。

實際上，軟件工程曆史上的很長一段時間内，需求分析一直被認為是整個軟件工程中最簡單的一個步驟。近些年，越來越多的人意識到，需求分析在整個過程中是至關重要的——如果需求分析師沒能正确地理解用戶的需求，最終結果往往是差強人意的：最終産品可能達不到用戶的要求，或者根本無法在規定的時間裡完工。

崗位職責

需求分析師的工作就是分析用戶的要求，是開發設計系統（産品、項目）的起點，其結果是否準确地反映了用戶的實際要求，将直接影響到後面各個階段的完成，最終影響到實現的系統是否合理和實用。

需求分析師一般是由具有業務知識背景和技術背景的人員擔任，具有相關行業技術産品開發經驗的人員肯定是更好的。在不同的企業，這個角色的名稱可能不一樣，工作内容也各有側重，有的企業叫做 BA（業務分析師），側重業務分析；有的企業叫做SA（系統分析師），更側重系統分析。真正的需求分析師的工作往往包括這兩部分内容，既有業務分析，也有系統分析。

下面是一個需求分析師招聘信息的崗位職責描述。

崗位職責：

1、根據概要需求（客戶及内部需求）編寫詳細需求規格說明書。

2、 系統規劃，與産品人員進行前期調研和産品設計工作，編寫調研報告和項目解決方案。

3、 參與系統功能驗收工作及用戶手冊、産品功能培訓資料的編寫。

4、 負責客戶需求調研及需求反饋的分析。

5、 配合測試人員編寫測試計劃、測試用例、測試報告等測試文檔，編寫産品用戶手冊，發現及跟蹤問題缺陷等。

6、協助系統架構師、系統分析師對需求進行理解。

從崗位職責描述來看，需求分析師和前面章節介紹的産品經理（特别是初級産品經理）的職責有很多相同之處。實際上，在産品經理的産品規劃和産品設計階段，他們所做的工作基本和需求分析師是相同的，也可能，這些階段本身就是需求分析師協助産品經理來完成的。

但是，需求分析師和産品經理這兩個角色以及他們的崗位職責還是有很大不同的。需求分析師主要負責分析和細化用戶的需求，并把用戶需求用技術的語言“翻譯”出來。産品經理則是負責産品的整個生命周期——從産品的定義、需求分析、開發進度跟蹤、産品發布推廣、運營、市場反饋收集、運營狀況追蹤等，簡單來說，也就是一個産品在市場上從無到有，從有到熱銷甚至退出市場，整個過程都由産品經理來負責。

總體來說，需求分析師和産品經理這兩個工作崗位的區别主要在于：需求分析師的職責範圍隻是産品經理的小部分，工作權限也比産品經理要小；産品經理在工作中一般要包括全部或部分需求分析師職能的，但是産品經理還有更多的事情要做，比如跟蹤産品開發、執行産品更新叠代、産品推廣戰略及商業模式等等，也就是說，産品經理可以取代需求分析師，反之則不然；需求分析師偏重業務和技術，着眼于微觀的需求細節，産品經理則偏重管理和整體把控，更着眼于宏觀的産品生命周期。

所以，産品經理的工作内容鍊條比較長，需求分析師的工作内容可能和初級産品經理有較大重合。從職業發展路徑來看，産品經理也是需求分析師的未來職業晉升方向之一。

具體來說，需求分析師主要面對的是用戶的需求，其核心工作職責包括： 需求調研、需求分析、需求确認、需求變更。

需求分析師的工作是從需求調研開始的，其目的是盡可能地收集到用戶的原始需求，比如前期通過對用戶的拜訪、反複的需求研讨（不限于形式，可以是會議、電話、面談）來調研需求。需求分析師完成背景調查和相關資料準備，再結合其他項目調研工作經驗梳理出要明确的問題，帶着這些問題去調研——這一點至關重要。需求調研前要做好準備工作，做足功課，準備工作越充足，調研效果越好；反之，提不出問題，就得不到結果。

常用的需求調研方法包括現場參觀和當面訪談、電話訪談、在線聊天、線上或線下調查問卷等。一般來說，現場參觀和當面訪談應該是最常用、最有效的需求調研方式。需求分析師參觀用戶工作場所、工作流程、設備等，通過與用戶各層級人員及時交談提問的方式來獲取原始需求。

依項目類型的不同，需求調研要收集的内容會有些不同。下面以一個軟件系統為例，軟件系統的需求調研一般要盡可能地調研了解如下内容：

1、業務場景：充分了解系統有哪些業務場景；具體了解每個業務場景要解決的業務問題、業務工作方式等；

2、業務流程：每個業務場景的業務流程；每個業務流程有哪些步驟環節、路徑、異常情況處理方式等；

3、用戶：系統有哪些用戶；每個業務環節有哪些用戶；用戶有什麼權限等；

4、系統功能：系統要具備哪些功能；每個業務環節要實現哪些功能；每個業務環節的用戶要進行哪些操作等；

5、數據：系統數據、用戶數據等；每個功能、業務環節要操作哪些數據；數據從哪裡來，到哪裡去；數據産生的時間段、時間粒度是怎樣；數據的類型和範圍；數據接口等；

6、規則：系統規則、業務規則等；數據生成規則，指标計算規則，操作處理規則等規則類需求；

7、非功能需求：系統界面風格、版式、顔色的界面需求；開發語言、軟件架構等特殊技術要求等；系統部署使用的硬件、操作系統、網絡、中間件等環境需求；業務處理量對系統性能影響的性能需求；系統安全、數據隐私等的安全需求；

8、其他約束：如系統上線等時間進度約束；建設場地、大型設備等資源約束；法律法規、技術标準、社會文化等其他約束

需求調研完成之後，需求分析師要把調研内容進行統一整理，然後輸出需求調研報告，一般包含調研對象、需求描述、業務流程、非功能性需求、需求優先級等内容的描述。需求調研報告也是後續需求規格說明書的主要内容來源。

需求分析就是把需求調研收集的原始需求進行業務分析，理清業務模型，然後進行系統分析，确定系統需求，最終形成需求規格說明書。這一過程中需求分析師可能還要與客戶溝通交流，不斷重複之前的需求調研過程，不斷充實和具體化需求内容。如果有必要，需求分析師還要為用戶設計方案、制作産品原型，有利于用戶更直觀地理解和感受系統的真實需求。

業務分析就是需求分析師要對用戶的業務情況進行調查分析，充分理解業務，在此基礎上定義需要系統支持的業務需求。業務分析的目标是讓需求分析師深刻理解業務，然後提出具有商業價值的業務需求。所以，需求分析師需要盡可能地建立業務模型，它是深入理解業務和描述業務分析結果的重要工具。簡單的業務可以采用業務流程圖來描述；複雜業務得依賴于包含業務目标、業務場景、業務流程、業務對象等内容的業務模型來表達。

系統分析的重點任務就是定義能夠有效支持業務的系統需求，也就是從系統角度來理解和确定所開發系統的綜合需求，并提出這些需求的實現條件以及應達到的标準。這些需求包括：功能需求(要做哪些功能)、性能需求(各項功能要達到什麼指标)、環境需求(所需的服務器型号、操作系統、中間件、數據庫等基礎軟件)、可靠性需求(災備和冗餘機制）、安全保密需求、資源使用需求(軟件運行時所需的CPU、内存、網絡帶寬等)、軟件成本與開發進度需求等。對于一般用戶來說，他們沒有能力提出清晰、完整的系統需求。所以，需求分析師在系統分析階段要對系統需求進行完善的分析，合理的定義。

需求分析階段的成果是需求規格說明書初稿，和産品經理章節談到的産品需求文檔PRD基本是一回事。需求分析師交付的一般叫需求規格說明書，産品經理交付的一般叫産品需求文檔。實際上，他們可能用的就是同一個文檔模闆。

另外，基于需求分析的結果，需求分析師往往會制作一個用戶易于理解的原型Demo,既便于用戶直觀理解系統的需求，也有助于需求分析師在後續的需求評審和确認中講解系統的各項需求。

三、需求确認

需求分析過程完成需求規格說明書初稿後，這個需求說明書所描述的需求一定要經過雙方（用戶方和開發團隊）确認，沒有确認的需求不能算作正式的需求。需求确認一般是通過需求評審來完成，需求分析師可以分别與外部用戶或者内部開發團隊組織召開需求評審會議，也可以組織用戶方和開發團隊一起召開需求評審會。總之，這個評審和确認環節很重要，是用戶方和開發團隊就需求達成一緻的過程。所以，這個需求評審和确認過程往往要重複好幾次，評審、修改、确認，再評審、再修改、再确認……。需求評審和确認環節一般至少要重複2~3次，所以在做時間計劃的時候一定要留出充足的時間。

如果用戶方不積極确認需求，一味催促開發實施，需求分析師應該和用戶方多溝通，讓他們認識到，未經确認的需求，如果投入開發，會浪費雙方的成本，而且可能會因為不必要的變更影響交付時間。開發團隊對需求是否可實現的反饋更是需求确認的重要任務，不能實現或者實現成本超出預期的需求、 對功能的正确性、完整性和清晰性以及其它需求給予的評價都應該及時反饋給用戶。需求規格說明書通過評審确認後才可以交付給開發團隊進行開發,否則需求分析師還需要重新進行需求調研、需求分析等先導工作。

基于需求規格說明書初稿，反複評審、修改、确認後的需求就是最終的需求，即可發布為需求基線版本。确認後的需求規格說明書就可以交付給開發人員來按需求實現系統，也是測試人員、項目管理等人員的最重要技術文檔。

四、需求變更

對确認後的需求，如果要發生變更，就需要做需求變更。需求變更的原因可能來自市場、管理、客戶、軟硬件工程環境和測試等方面，對于這些變更來說，如果不控制或者控制不好就會導緻項目陷入混亂、不能按進度執行或軟件質量低下等一系列的問題。

需求變更應該是需求分析師最頭痛的事情。一旦要變更需求，也就意味着上述需求調研、需求分析和需求确認的流程又得再走一遍。所以，對于需求變更，需求分析師既不能一概拒絕用戶的要求，也不能一味地遷就用戶，實施需求變更之前必須做好管理和控制。

需求變更控制是需求管理的主要工作之一，需求分析師要能正确判斷内在或外在原因導緻的變更所帶來的影響，并且調整開發過程以控制和适應這些變化。在管理和控制需求變更的時候，需求分析師一般要考慮：變更對已有的需求以及開發、測試成本的影響；變更應該劃分優先級，有序處理；變更可以設置一個緩沖期，這樣有助于讓變更更穩定，避免反複變更。需求變更需要經過評審後才決定是否接受、拒絕或者延遲，最終确保項目開發範圍可控。

在需求分析師的整個工作流程中，他們可能面對如下問題：用戶缺乏技術知識，不能準确地表達自己的需求，所提出的需求往往不斷地變化；需求人員缺乏用戶的專業業務知識，不易理解用戶的真正需求，甚至誤解用戶的需求；需求人員不清楚需求有哪些内容和層次，需求工作太被動，主要是等待用戶提出需求；對需求缺乏系統的分析和長遠的規劃，造成需求變更出現的時候疲于奔命，等等。

解決這些需求問題的方法其實也就一條——需求分析師必須不斷深入地與用戶進行交流，才能逐步确定用戶的實際需求，也就是需求調研、需求分析、需求确認這三個過程不斷地重複。隻有前期的工作做到位，後面的需求變更才可能是比較少，或者根本沒有需求變更。

不過，從我十多年的項目經驗來看，沒有需求變更的項目好像也是屈指可數！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!