需求分析常用五種方法

㈠ 需求分析常用方法

行為事件分析

行為事件分析是根據運營關鍵指標對用戶特定事件進行分析。通過追蹤或記錄用戶行為事件，可以快速的了解到事件的趨勢走向和用戶的完成情況。

以用戶投標的行為事件為例，出借人在完成投標過程中，所進行的注冊、認證、開戶、充值、投資等行為，都可以定義為事件，也是完成投標成功的一個完整事件。
確定投標行為事件後，我們可以根據事件屬性細分維度：用戶來源、性別、出生年月、注冊時間、綁卡時間、首次充值時間、首次投資時間、標的ID，標名、期限、利率、還款方式等。然後從中找出符合指標的規律，並制定針對性的措施。

用戶留存分析

用戶留存分析是一種用來分析用戶參與情況與活躍程度的模型。通過留存量和留存率，可以了解用戶的留存和流失狀況。比如用次日留存、周留存、月留存等指標來衡量產品的人氣或粘度。以渠道訪問的用戶留存為例，我們對APP端有過訪問行為的渠道用戶進行留存分析。用戶留存一般符合40-20-10法則，即新用戶的次日留存應該大於40%，周留存大於20%，月留存大於10%才符合業務標准。我們做用戶留存分析主要驗證是否達到既定的運營目標，進而影響下一步的產品決策。

漏斗模型分析

漏斗模型分析是用戶在使用產品過程中，描述各個階段中關鍵環節的用戶轉化和流失率情況。比如在日常活動運營中，通過確定各個環節的流失率，分析用戶怎麼流失、為什麼流失、在哪裡流失。找到需要改進的環節，要重點關注，並採取有效的措施來提升整體轉化率。

邀請人將活動專題頁分享給好友，之後進行的注冊、認證、開戶、充值到投資，用漏斗模型分析一些關鍵節點的轉化率。其中用戶注冊轉化率為68%，實名認證轉化率為45%，綁卡開戶轉化率為29%，線上充值轉化率為17%，投資標的轉化率為8%。
漏斗模型分析可以驗證整個流程的設計是否合理。經過對比發現，訪問到注冊的轉化率為68%，遠低於預期的80%。這次運營策略是用戶必須先注冊才能領取新手福利。之後採取A/B測試的方式，優化為先領取新手福利再誘導用戶注冊。經過數據對比分析，注冊轉化率提升了20%。因此，通過對各環節相關轉化率的比較，可以發現運營活動中哪些環節的轉化率沒有達到預期指標，從而發現問題所在，並找到優化方向。

行為路徑分析

行為路徑分析就是分析用戶在產品使用過程中的訪問路徑。通過對行為路徑的數據分析，可以發現用戶最常用的功能和使用路徑。並從頁面的多維度分析，追蹤用戶轉化路徑，提升產品用戶體驗。

不管是產品冷啟動，還是日常活動營銷，做行為路徑分析首先要梳理用戶行為軌跡。用戶行為軌跡包括認知、熟悉、試用、使用到忠誠等。軌跡背後反映的是用戶特徵，這些特徵對產品運營有重要的參考價值。我們可以記錄用戶從注冊、認證、開戶、充值到投資的行為軌跡。通過分析用戶的這些行為軌跡數據，來驗證訪問路徑是否和預期指標的一致。

㈡ 需求分析的主要方法是什麼

1.1 需求的背景

需求的背景指的是動機，這一項實質上是換位思考，它能夠幫助我們從業務方的角度，從使用場景、用戶心理去理解需求。

在實際工作中，我們所接收到的「需求」常常是表述不清晰的、不完整的，甚至是具有欺騙性的。

一個問題會對應許多的解決方案，找到真正的需求，也正是我們的職責。

1.2 需求的受眾

需求的受眾需要注意的問題有兩點：

誰是真正的受眾；
受眾人群是否具有代表性。
需求的來源很多，可能是用戶、業務方等。我們需要分清楚誰才是真正的受眾。

在一個需求里不同的角色認知和訴求是不同的，當信息帶上了主觀判斷也就被污染了。

其次，則是覆蓋度的問題。對於頻次不夠高或者人群不夠有代表性的需求，投入產出比會是一個大大的問號。辨清受眾，在評估需求的優先順序和制定解決方案時，迷惑性會大大降低。

1.3 需求的目的

需求的目的指需要做什麼，很多時候我們接到的「需求」其實是業務方過濾後的「解決方案」。

以「口渴」為例，此時業務方提出的需求是要製作一台飲水機，然而飲水機並不能解決問題。如果我們挖掘到背後的動機是「口渴」，那麼我們可以從補充水分和減少水分的流失來著手提供解決方案。

1.4 需求的目標

在漢語辭典里的解釋，目的是期望，而目標是成果。

目標更為具象，並且能夠用數據指標來衡量，後續也能夠指導需求的改進。

需求的本質是為了創造價值，而創造價值最直白的則是開源和節流。具象到目標，可以用創造的收益，提升的效率以及節省的資源等方面進行量化。

2. 因果關系分析法
、需求優先順序的評定
最後一個環節是需求優先順序的評定，我常用的方法是選取影響優先順序的因素並設定比例，經過加權計算出優先順序，分數越高優先順序越高。

其公式如下：

優先順序=因素1比例*因素1分值+因素2比例*因素2分值+….

表1-需求評估加權表

這張表，影響的因素主要有兩項：投入產出比以及重要程度。

投入產出比個人認為是必選的，而重要程度中的維度可以根據實際情況去增加、減少。同理，加權中比例的設置也是如此。

㈢ 需求分析方法有哪些

問題一：需求分析有哪些方法 三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業或沖務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。
面向對象的分析方法陪團如的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺蘆啟點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人骸的要求非常高。

問題二：項目需求分析的分析方法 需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.

問題三：如何做好需求分析，需求調研 轉載以下資料供參考
從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。
原因
需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個for linux的軟體，而你在軟體開發前期忽略了軟體的運行環境，忘了向用戶詢問這個問題，而想當然的認為是開發for windows的軟體。當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。
需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟體開發的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟體系統的開發中，他的作用要遠遠大於程序設計。
任務
簡言之，需求分析的任務就是解決「做什麼的問題，就是要全面地理解用戶的各項要求，並准確地表達所接受的用戶需求。
過程
需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。
問題識別：就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標准。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟體運行是所需的內存、CPU等)、軟體成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
分析與綜合： 逐步細化所有的軟體功能，找出系統各元素間的聯系，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。
制訂規格說明書： 即編制文檔，描述需求的文檔稱為軟體需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。
評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。
方法
需求分析的方法有很多，這里只強調原型化方法，其它的方法如：結構化方法、動態分析法等，從來沒用過這些方法在此不討論。
原型化方法是十分重要的，原型就是軟體的一個早期可運行的版本，它實現了目標系統的某些或全部功能。
原型化方法就是盡可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能。但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如演算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟體工具快速的建造一個原型系統，這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。
原型主要有三種類型：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。
實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。
進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。
在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。
廢棄策略：先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成......>>

問題四：請問常用的需求分析方法有哪些？ 結構分析方法和面向對象分析法

問題五：培訓需求分析的方法有哪幾種 組織資源分析
如果沒有確定可被利用的人力、物力和財力資源，就難以確立培訓目標。組織資源分析包括對組織的金錢、時間、人力等資源的描述。一般情況下，通過對下面問題的分析，就可了解一個組織資源的大致情況。
組織特質與環境分析
組織特質與環境對培訓的成功與否也起重要的影響作用。因為，當培訓規劃和組織的價值不一致時，培訓的效果則很難保證。組織特質與環境分析主要是對組織的系統結構、文化、資訊傳播情況的了解。主要包括如下內容：
系統特質指組織的輸入、運作、輸出、次級系統互動以及與外界環境間的交流特質，使管理者能夠系統地面對組織，避免組織分析中以偏概全的缺失。
文化特質。指組織的軟硬體設施、規章、制度、組織經營運作的方式、組織成員待人處事的特殊風格，使管理者能夠深入了解組織，而非僅僅停留在表面。
資訊傳播特質。指組織部門和成員收集、分析和傳遞信息的分工與運作，促使管理者了解組織信息傳遞和溝通的特性。

問題六：在需求分析階段常用的圖形工具有哪三種 1. 需求分析是准確的理解用的需求將其轉換成需求定義，然後由需求定義轉換成形式化的功能規約。需求分析的困難表現在問題的復雜性、交流的障礙、不完備和不一致性、需求易變性。 2. 結構化分析方法是採用自頂向下逐層分解的分析策略把一個復雜的系統分解成若干小問題然後分別解決 3. 數據流即數據通過一個系統時的變化方式。輸入數據首先轉換成中間數據，然後轉換成輸出結果數據。在此期間可以從已有的數據存儲（如磁碟文件或內存緩沖區）中引入附加數據。對數據進行轉換是程序中應有的功能或子功能。兩個轉換功能之間的數據傳遞就確定了功能間的介面。 4. 把一個功能分解成幾個子功能，並確定這些子功能與父功能的介面，就屬於橫向分解。 5. 把一個功能分解成幾個子功能，並確定這些子功能與父功能的介面，就屬於橫向分解。但如果繼續分解，把某些子功能又分解為小的子功能，某個小的子功能又分解為更小的子功能，這就屬於縱向分解了。 6. 數據流圖是用來表示系統的功能的工具它表示系統的邏輯模型描述了數據流在系統中流動的情況它是一種功能模型。

問題七：如何做需求分析 隨著技術的不斷發展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟體工程，也越來越復雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規范的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。
網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網路和Web
伺服器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關系管理。）等項目管理中。
按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業務流程分析
3. 系統分析及軟體建模
4. 界面設計、交互設計及程序開發
5. 系統測試和文檔編寫
6. 客戶培訓、技術支持和售後服務
需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。
（一）如何做好需求分析及變更管理？
業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
一：讓客戶暢所欲言，羅列出所有的需求
讓用戶將所有的想法盡可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕「勾引」起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求准確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用伺服器、資料庫還是程序全部要重新開發！
二：透過現象分析潛在的需求
很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。
客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理伺服器；設計網路電子商店時今後增加庫存產品進銷存統計分析等等；限於時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今後的需求變更除了使項目開發更加順利以外，也為今後業務的進一步深入打下......>>

問題八：軟體需求分析的方法和工具有哪些內容 1. 問卷調查法， 開發方就用戶需求中的一些個性化的、需要進一步明確的需求，通過採用向用戶發問卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。這種方法適合於開發方和用戶方都清楚項目需求的情況。因為開發方和建設方都清楚項目的需求，則需要雙方進一步溝通的需求就比較少，通過採用這種簡單的問卷調查方法就能使問題得到較好的解決
2. 會議討論法 ，開發方和用戶方召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法，這種方法適合於開發方不清楚項目需求（一般開發方是剛開始做這種業務類型的工程項目）但用戶方清楚項目需求的情況。因為用戶清楚項目的需求，則用戶能准確地表達出他們的需求，而開發方有專業的軟體開發經驗，對用戶提供的需求一般都能准確地描述和把握
3. 界面原型法 ，開發方根據自己所了解的用戶需求，描畫出應用系統的功能界面後與用戶進行交流和溝通，通過「界面原型」這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合於開發方和用戶方都不清楚項目需求的情況。因為開發方和用戶方都不清楚項目需求，因此此時就更需要藉助於一定的「載體」來加快對需求的挖掘和雙方對需求理解。這種情況下，採用「可視化」的界面原型法比較可取

㈣ 需求預測的常用方法及適用條件

一、定性預測方法

1.管理評價法。

管理評價法，是預測企業人力資源需求最常用的一種主觀預測法。它是由高層管理者、部門經理和人力資源部專員等人員一起預測和判斷企業在某段時間對人力資源的需求。管理評價法可以分為自下而上的下級估計法和自上而下的上級估計法兩種。下級估計法是首先由基層管理人員根據其生產能力、員工流動等情況預測人員需求，然後向上級主管部門匯報。上級估計法是由高層管理者根據組織發展目標和發展戰略以及經營環境等的變化預測人員需求。利用管理評價法預測人陪搜雹員需求的主要依據是：企業的目標、生產規模、市場需求、銷售或者服務規模、人員配置及流動性等。這種方法的主要缺點是：具有較強的主觀性，受判斷依據以及判斷者經驗的影響較大。該方法通常用於中短期預測，並且在預測中將下級估計法和上級估計法結合起來運用。

2.現狀預測法。

現狀預測法是一種適用於短期預測的最簡便的預測方法。這種方法假定組織的員工總數與結構完全能適應預期的需求，管理者只需要安排適當的人員在適當的時間內去補缺即可，如替補晉升和跳槽者的工作崗位。

3.經驗預測法。

經驗預測法，是一種利用現有情報和資料，根據以往的經驗，結合本企業的實際特點，對企業未來員工需求進行預測的一種簡便易行的預測方法。這種預測方法是基於人力資源的需求與蘆帆某種次要因素之間存在某種關系的假設。由於這種方法完全是依靠預測者的經驗和能力，預測結果的准確性和精確度得不到保證，通常只能用於短期預測。

4.情景描述法。

情景描述法是企業的人力資源部門對組織未來的戰略目標和相關因素進行假設性描述、分析和綜合，並作出多種人力資源需求的備選方案，以此適應和應付環境與因素的變化。情景描述法通常用於環境變化或者組織變革時的人力資源需求預測分析。

5.微觀集成法。

使用微觀集成法，是組織的各個部門根據自己單位、部門的需要預測將來某時期內對各種人員的需求量，人力資源管理的`計劃人員就可以把各部門的預測綜合起來，形成總體預測方案。這種方法由上而下布置預測工作，由各直線部門經理根據本部門的業務發展需要，預測出將來對某種人員的需求量，然漏搏後再由下而上逐級進行匯報、預測和匯總。它適用於短期預測並且組織的生產或者服務比較穩定的情況。

6.工作研究預測法。

工作研究預測法，是企業根據具體崗位的工作內容和職責范圍，在假設崗位工作人員安全適崗的前提下，確定其工作量，最後得出需要的人數。工作研究預測法的關鍵是首先進行科學的工作分析，編寫出准確的職務說明書，制定出科學的崗位用人標准。當企業的結構比較簡單、職責清晰的時候，工作研究分析預測法比較容易實施。

7.德爾菲法。

又稱為專家預測法，是指邀請在某領域的一些專家或有經驗的管理人員採用問卷調查或小組面談的形式對企業未來人力資源需求量進行分析、評估和預測並最終達成一致意見的方法。這種方法要求比較嚴格，在實施時需要注意：專家人數一般不少於30人，問卷的返回率不低於60%，以保證調查的權威性和廣泛性；實施該方法必須取得高層的支持，同時給專家提供充分的資料和信息，確保判斷和預測的質量；問卷題目設計應主題突出，意向明確，保證專家都從同一個角度去理解問題。這種方法適用於長期預測，調查對象既可以是個人或面對面專家小組，也可以是背靠背的專家小組。面對面的方式，專家之間可能相互啟發；背靠背的形式可以免除某一權威專家對其他專家影響，而使每位專家獨立發表看法。德爾菲法的整個過程可以用圖4—4來表示。

3.工作負荷預測法。

工作負荷預測法，是指按照歷史數據、工作分析的結果，先計算出某一特定工作每單位時間（如一天）的每人的工作負荷（如產量），然後再根據未來的生產量目標（或者勞務目標）計算出所需要完成的總工作量，然後依據前一標准折算出所需要的人力資源數量。這種方法的考慮對象是企業工作總量和完成工作所需要的人力資源數量之間的關系，考慮的是每位員工的工作負荷和企業總體工作量之間的比率。可用公式表示為：

未來每年所需員工數=未來每年工作總量/每年每位員工所能完成的工作量=未來每年的總工作時數/每年每位員工工作時數

因此，工作負荷預測法的關鍵部分是准確預測出企業總的工作量和員工的工作負荷。當企業所處的環境、勞動生產率增長比較穩定的時候，這種預測方法就比較方便，預測效果也比較好。

4.勞動定額預測法。

勞動定額，是對勞動者在單位時間內應完成的工作量的規定。在已知企業的計劃任務總量，以及科學合理的勞動定額的基礎上，運用勞動定額法能夠比較准確地預測企業人力資源需求量。該方法可以運用公式：N=W/q（1+R）進行計算。式中，N為企業人力資源需求量，W為計劃期任務總量，q為企業制定的勞動定額，R為部門計劃期內生產率變動系數。R=R1+R2+R3，其中，R1為企業技術進步引起的勞動生產率提高系數，R2為由經驗積累導致的勞動生產率提高系數，R3為由與員工年齡增大以及某些社會因素導致的勞動生產率下降系數。

㈤ 需求分析的主要方法是

目前，軟體需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開發過程及特點出發，軟體開發一般採用軟體生存周期的開發方法，有時採用開發原型以幫助了解用戶需求。在軟體分析與設計時，自上而下由全局出發全面規劃分析，然後逐步設計實現。
從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。
(4)面向對象的分析方法。
面向對象的分析方法的關鍵是識別問題域內的對象，分析它們之間的關系，並建立三類模型，即對象模型、動態模型和功能模型。面向對象主要考慮類或對象、結構與連接、繼承和封裝、消息通信，只表示面向對象的分析中幾項最重要特徵。類的對象是對問題域中事物的完整映射，包括事物的數據特徵(即屬性)和行為特徵(即服務)

㈥ 需求分析的十個步驟

1、概念明確----2、需求分析目的------3、如何識別需求---4、判斷需求真偽----5、分析[ 用戶故事評估框架、馬斯洛框架、營銷框架定位]---6、評判價值----7、砍需求能力---8、分類----9、排優先順序----10、提升需求分析能力

一、什麼是產品需求?

1、想要 vs 需要 vs 需求

「想要」(Want)是用戶外在表達出來的，而「訴求」(Need)是用戶內在的心理預期。產品需求滿足的是用戶的內在訴求，這是根本。

想要(Want)是外在的、具體的、有指向性的解決方案。

需要(Need)，或者如我們前面說到的「訴求」，是內在的、原始的最終動機。

需求(Demand)是滿足內在需要的同時，在可控成本內實現外在想要的解決方案。

二、需求分析的目的

需求分析，本質是動機的分析，目的在於預測用戶未來的行為。需求分析階段的產出 物，需要回答用戶要什麼、為什麼要，還要回答以後什麼情況下還可能要類似的東西、這種情

況有什麼特點、如何人為的製造這種情況、

需求重要，是因為它是用戶行為的動機;需求是分層的，說出來的一個樣，實際是另一個樣。

用戶需求分析，是為了通過分析動機，准確預測用戶的行為。不同的需求，代表   了不同的動機，註定會產生不同的行為，應當看做不同類型的用戶。

在需求分析中考慮競爭性，是為了比競爭對手預測得更准確，這是我們在後面要說的。

【知識點】需求= 購買慾望 + 購買力 = 需要 + 目標產品 + 購買力

三、如何識別需求？

       分析完需求，那我們如何去發掘新需求呢?這里就涉及如何識別需求。 識別需求可以從三個方面去考慮，分別是視角、效率、體驗。

       1、視角

       先說視角。作為產品經理，我們要具備多樣化的視角來審視需求和產品，分為用戶視角和產品視角。

        比如:開頭我們提到的關於微信朋友圈可見范圍的例子，相比於之前三天可見和半年可見，增加了一個月可見范圍。

        在這個設計里，用戶往往會站在自我的角度說，「不想讓別人看我的朋友圈」，這是用戶視角。而產品視角是考慮群體和整體，是「讓用戶更小壓力去發朋友」。這種視角差異，最終的方案也會有差別。

        用戶視角滿足的是「想要」(Want)，產品視角實現的是「需要」(Need)。

        2. 效率

        另一個識別需求的維度就是效率。在最優效率的前提下，滿足盡可能多的用戶需求。

        我們還是用一個例子來說明，用過微信公眾號贊賞功能的人都知道，如果自己贊賞過作者，那自己的頭   像就會始終排在最前面。

        如果自己沒有贊賞過，那每次進入文章，且贊賞人數超過 24 人後，底部的贊賞頭像都不是固定順序展示的。

        3. 體驗

            最後一個識別需求的維度就是體驗，關於體驗，做產品的同學就比較熟悉了。體現在信息架構設計、流程設計、交互設計還有文案設計等方面。

            體驗也是一個很虛的指標，很難量化，每個人的認知和感受都會因為習慣、文化、個人傾向產生差別。任何細節的體驗設計，都會給用戶傳遞一個認知，而我們要明白的是，獨立個體的認知差異是很大的。

            比如:對於「快車」這個概念，剛出來的時候，大眾是無認知的，只能找到對標，比如計程車和專車，而快車是介乎於兩者之間的一種服務。

            如何更好的設計快車體驗呢，其實用價格比專車低、比計程車干凈舒服、且車多三個認知來傳遞給用戶，就能讓用戶快速接受並理解。

四、接收需求判斷真偽

真需求要滿足三個條件

            1. 該用戶屬於目標用戶

            2. 需求必須符合產品定位

            3. 需求能夠實現

五、如何分析需求

1、採用用戶故事的方式進行分析

    需求是結合用戶表達的外在慾望、內在的核心訴求以及可用成本的綜合評估。

    基於這個定論，我整理了一句話，可以作為需求分析的一個評估框架—— 我們為誰用什麼方法解決了一個什麼問題?

    在這句話里，「誰」指的就是我們的目標用戶，我們需要明確用戶畫像;「問題」對應的是前文提到的需求，而「方法」就是我們基於需求提供的產品方案。

    我們為誰用什麼方法解決了一個什麼問題?其實就是在反問我們自己，作為產品經理，你在為哪類人服務，他們的核心訴求是什麼，你設計了一個什麼產品方案去滿足他們的需求。

用戶分析，我們可以從用戶身份和用戶特徵兩個角度出發，用戶是什麼人群，年齡、性別、地區等都是構建用戶畫像的基本素材。

目標用戶有什麼樣的特徵，比如職業特徵、文化特徵等，這些都能幫助我們進一步理解用戶。

其次是需求場景，說白了，就是用戶是在什麼環境和狀態下來使用我們的產品。

「場」是時間加空間，「景」是情景和互動。當用戶停留在這個空間的時間里，情景互動觸發並裹挾用戶的意見就是場景。

可以用比較通用的馬斯洛需求理論對用戶需求進行分析，評估滿足的是哪個層級的

需求，或者是通過用戶體驗五層模型來劃分需求層級。

用戶價值是從體驗和效率兩方面來衡量的，一個需求能改善現有體驗，那就能提升用戶價值，能提高使用效率，也能提升用戶價值。

如何衡量體驗是否有提升呢，可以用新體驗減去舊體驗的方式，例如針對某個體驗改進，簡單粗暴的做法就是新舊體驗相減得到的用戶投訴率，如果為正，說明用戶價值有提升。

而效率則可以通過用戶完成某一任務的平均時長來衡量，例如在電商產品中，用新舊總平均成交轉化時長的差值來衡量提單效率是否有提升。

商業價值就比較直觀了，關乎於成本和利潤，互聯網傳統的商業化方式包括了廣告、游戲、會員等。目前也有很多做增值服務和第三方能力輸出服務的，這都是商業化手段，同時也會對應到一些產品需求上。

2、馬斯洛框架和營銷層方式結合起來

做需求調研和分析，最尷尬的結局就是:用戶以為自己說清楚了，我們以為自己聽清楚了，結果兩邊就這樣整差了。

 在產品上線之前，甚至在進入產品設計階段之前，我又怎麼能知道我做的需求分析已經足夠深了呢?

  行業給出的一般方法是MVP(MinimumViable Proct)，利用MVP收集線上實際數據。 但MVP只能告訴你，你是錯了還是對了，依然解決不了「為什麼」以及「應該怎樣」的問 題。況且MVP還有覆蓋度的問題，怎麼設計才能讓MVP覆蓋所有「應該」被測試的場景呢?

到了1959年以後，馬斯洛認為「人本」的導向會產生「自由主義」傾向，從而產生自私、不負責任、不顧他人、自我放縱等自我中心傾向。於是，馬斯洛於1969年發表了論文《Z理論 ——兩種不同類型的自我實現者》，並依照「超人本心理學」(Trans-HumanisticPsychology)將需求層次理論拆解為三個次理論:X理論、Y理論和Z理論。

依次為:

Z理論

                       最高需求(超越性靈性需求)

Y理論

                       自我實現需求

                       尊重需求

                       社會需求

X理論

                        安全需求 生理需求

營銷學中的需求分層

在科特勒老師的《營銷管理》(15th Global Edition)中，給出了這樣一個案例:

表明了的需求:顧客需要一個便宜的汽車;

真正的需求:顧客需要一個養車比較便宜的汽車，而不是價格便宜的汽車;

未表明的需求:顧客希望零售商提供較好的服務;

愉快的需要:顧客希望零售商給裝配車載GPS系統;

秘密的需要:顧客希望朋友們將TA看作是懂行的消費者;

有了前面兩套框架，我們就守住了需求的來源和表達過程。但是兩套框架的用法正好截然相 反:馬老師的框架是「5:1」——從五個層次里選一個當前所在的層次;但營銷學的需求理論 是「1:5」——拿到一個需求從五個方面來分解。

我們用賣蘋果的例子還原一下需求分析的過程:

用戶說:「我要買一個蘋果」。此時千萬不要直接就套上馬老師的需求層次了，因為這根本就不是一個「根本性」的需要，而是一個結合了具體產品——蘋果的具體需要。

這時應當用的是營銷中的五個分類:

                       表明了的需要:我要一個蘋果;

                       真正的需要:可能是解決餓肚子，可能是解決饞，更有甚者是解決低血糖的症狀等

  等;

                       未表明的需要:如果為了填飽肚子，就需要個大的;如果為了解饞，就需要味道好

  的;如果為了解決低血糖，就需要一個更甜的;

                       愉快的需要:吃飽了、解饞了、頭不暈了(低血糖的症狀之一)當然開心，如果買一

  送一、免費加工成蘋果汁、還能額外加點糖，有可能就更好了;

                       秘密的需要:可能是工作繁忙，接下來還要趕往別處，實在沒時間吃別的了;又或者

  是最近吃胖了，需要用水果當飯吃;

六、評判需求價值

1. 廣度:受眾人群以及受眾面

2. 強度:用戶對於需求的迫切程度

3. 頻率:間隔時間及可持續性

七、砍需求能力

                        1. 對需求進行價值評估和量化

                        2. 關聯性較強的需求進行整合

                         3. 排列優先順序

所有對產品的價值判斷，都基於對行業、市場的探知程度;對人性的認識和了解程度(發現沒有，把握人性始終貫穿產品的各個層面)

八、對需求分類

九、對需求排優先順序

能用是基本要求，能用的標準是產品功能完整、沒有異常、邏輯閉環，如果功能或流程缺失，或者產品有bug，那是達不到能用的標準的。

易用對應一些錦上添花的需求，在滿足能用的前提下，做流程優化和交互優化，使產品達到用戶體驗良好的狀態。

愛用是讓用戶形成習慣和依賴，例如我們在朋友圈裡發布了很多內容，隨著內容增多，我們的離開成本就越高，並且每次都能收到朋友圈的正向反饋，這個閉環就能形 成習慣和依賴。

傳播能力使產品具備價值可擴散的屬性，滿足用戶需求並獲得市場認可後，需要將價值外延以吸引更多的用戶，這是建立在基礎功能完備、體驗優良，並且滿足用戶價值 的前提下。

十、如何提升需求分析能力？

1. 傾聽

首先是傾聽，面對需求方，不論是用戶還是運營還是工程師，首先做到先聽，這是放下自我做產品的前提。

什麼是事實? 客觀的原因和現象是事實，基於現象去分析背後的原因，基於原因再形成觀點。

2. 觀察

其次是觀察，觀察是最好的洞察用戶需求的方式，到用戶身邊去，看他們做了什麼，行動往往反映了用戶的真實訴求。

3. 同理心

       如何切身感受、設身處地呢?最簡單的方式就是到用戶的環境中去，感受用戶不如變成用戶。

只有切身感受，尤其是感受到了痛，你才真的理解了用戶。

附記：

需求溝通:需求中的需求?

            至於怎麼講，我們還可以套用前面的框架——老闆跟你說:「你做個需求分析」。

 那麼:        

表明了的需要:老闆需要你做一個需求分析;

真正的需要:老闆可能在策劃下一款新產品，或者要把一個競爭對手打掉，或者是老闆的老闆要求下來的，或者......

未表明的需要:時間呢?質量呢?形式呢?匯報對象呢?怎麼，你不知道?快問啊!

愉快的需要:老闆可能希望你從不同的視角(員工視角、跨行業視角、年輕視角等 等)給出不一樣的答案;可能希望你直接做成他能用來匯報的ppt格式，可能......

秘密的需要:老闆背負著公司巨大的業績壓力需要尋找突破口、老闆「可能」也有自己升職加薪的小算盤......

㈦ 需求分析的主要方法是什麼

需求分析的主要方法是面向過程法（自上向下分解），信息工程法（數據驅動）（數據流分析結構化分析方法），面向對象法(對象驅動)。需求分析是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸頌指飢入什麼數據，要得到什麼結果，野返最後應輸出什麼。在軟體工程中，需求分析指的是在建立一個新的或改變一個現存的電腦系統時描寫新系統的目的、范圍、定義和功能時所要做的所有的工作。需求分析是軟體逗氏工程中的一個關鍵過程。在這個過程中，系統分析員和軟體工程師確定顧客的需要。只有在確定了這些需要後，他們才能夠分析和尋求新系統的解決方法。需求分析階段的任務是確定軟體系統功能。

㈧ 軟體工程中常用的需求分析的方法有哪些

一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。

這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。

1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那麼這個需求就可能是偽需求。

以下面的案例說明：

背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。

需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。

分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。

因此，該需求是個偽需求，應該被過濾掉。

2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。

因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。

如果不屬於該系統范疇，那麼直接說服需求方更換方案。以

下面的案例說明：

背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。

需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。

分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。

所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；

其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。

結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。

否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。

二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：

先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。

每個需求點再當做一個子需求進行調研，最後再聚合在一起。

以下面的案例說明：

背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。

需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。

該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：

自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。

這里不一一展開。

2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：

由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。

然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。

三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。

比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。

最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：

背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。

分析：需求是很明白的，也有它的意義，但有風險。

因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。

因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。

於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。

測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。

四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。

舉例說明：

背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。

需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。

分析：

第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……

第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……

通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。

羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。