運用什麼方法進行需求分析

❶ 需求分析的方法

原型法：獲取一組基本需求之後，快速構造出一個能夠反映客戶需求的初始系統原型。

讓用戶看到未來系統的概貌，以便判斷哪些功能是符合要求的，哪些還需要改進。

按照信息的流向、結構和內容三個方面將現有的需求分析建模方法劃分為結構化分析方法，Jackson分析方法和面向對象分析方法。

通過E-R圖提供表示實體、屬性和聯系的方法，描述顯示世界中的概念模型，不涉及這些實體在系統中的實現方法。

通過數據流圖描述邏輯模型，表示數據在系統內的變化；分層表示信息流和功能的細節。

行為建模採用動態分析方法，直觀地分析系統的動作，最常用的動態分析方法包括狀態遷移圖，時序圖和Petri網。

狀態遷移圖通過描述狀態以及導致系統改變狀態的事件來表示系統的行為，指明了系統如何在狀態間移動。

❷ 論述項目需求分析的技術與方法

1、篩掉明顯不合理的需求

這個階段的判斷標准就是需求的合理性，用你的經驗、專業知識，甚至是直覺，過濾掉大部分需求。比如，當前技術不可能實現的或意義不大的、投入產出比低的、明顯不合理的需求。

因為從各種不同渠道會收集到大量的需求，為了提高效率，你不得不這么做。當用戶量達到一定規模後，光每天收到的用戶反饋就夠你喝一壺的。甚至因此，你不得不做一個用戶幫助和反饋系統，來幫助你過濾和初步加工需求。

有個簡單的判斷方法：這需求做了會怎樣？不做又會怎樣？

如果做不做沒多大區別，甚至做了會起到負效果，那就不需要猶豫了，可以直接過濾掉這條需求。

2、挖掘用戶的潛在需求和動機

這是用戶需求進化為產品需求的關鍵一步。

用戶需求：need，用戶想要的。

產品需求：solution，解決方案。可以是推薦演算法優化、界面布局調整、新功能點，甚至是新產品等等

以上是用戶需求和產品需求的定義，用戶需求是用戶想要的東西，產品需求是滿足用戶需求的解決方案。用戶畢竟不是專業人士，考慮問題的出發點是用戶自身，這就需求產品經理去挖掘用戶的潛在需求和動機。

最著名的例子就是：If I had to ask customers what they want,they will tell me:a faster horse.「如果我當年去問顧客他們想要什麼,他們肯定會告訴我：一匹更快的馬.』」

如果福特先生不去挖掘用戶背後動機的話，可能就去研究馬的配種問題了，而不會有福特汽車了。

那麼如何挖掘用戶潛在需求和動機？

用戶需求的產生，帶有很強的不確定性，受環境、情緒等各種因素影響。所以光看錶面描述不行，得有代入感的去感受。可以通過以下幾個要素進行場景分析：

用戶需求=誰（用戶特徵）+在什麼情況下+想滿足什麼？

比如你是Todo list產品經理，調研過程中，某用戶反饋添加過程太麻煩了，沒法批量添加。追問為什麼需要批量添加後，對方回答，她是一名學生，想要把課程表導入到list中，方便查看。

這時候你就明白了，對方是一名大學生，在添加操作的環節遇到了麻煩，她是想要添加課程表。

這時候你就可以馬上找到解決方法：可以利用OCR技術，只需掃描一下，直接將整張課程表導入進來。

再深入思考一下！添加課程表就是最終的目的嗎？

顯然不是，對方添加課程表後，一是為了方便查看，二是為了上課時間快到時提醒她上課。那麼就可在導入後，行程一個可視化的日程表，提前提醒上課。

這就是需求挖掘過程。

3、需求歸類整理

挖掘到用戶的真實目的後，會發現，多個看似不同的需求背後，原來是出於同一個目的。這就可以將這幾個需求歸納為同一個。

接著可以通過如下維度歸類整理需求：

1）判斷是否有價值：廣度、頻率、強度

如果使用人數很多、頻率很高、需求也很強烈，那當然是好需求。如果這三者都不沾邊，可以判斷為無價值需求，可過濾掉。

❸ 傳統需求分析方法包括哪些主要特點是什麼

傳統需求分析方法：結構化分析方法。

主要特點：結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。

因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制。

通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。

當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。

需求分析原則

為了促進軟體研發工作的規范化、科學化，軟體領域提出了許多軟體開發與說明的方法，如結構化方法、原型化法、面向對象方法等。這些方法有的很相似。在實際需求分析工作中．每一種需求分析方法都有獨特的思路和表示法，基本都適用下面的需求分析的基本原則。

1、側重表達理解問題的數據域和功能域。對新系統程序處理的數據，其數據域包括數據流、數據內容和數據結構。而功能域則反映它們關系的控制處理信息。

2、需求問題應分解細化，建立問題層次結構。可將復雜問題按具體功能、性能等分解並逐層細化、逐一分析。

3、建立分析模型。模型包括各種圖表，是對研究對象特徵的一種重要表達形式。通過邏輯視圖可給出目標功能和信息處理間關系，而非實現細節。由系統運行及處理環境確定物理視圖，通過它確定處理功能和數據結構的實際表現形式。

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

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

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

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

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

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

以下面的案例說明：

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

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

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

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

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

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

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

下面的案例說明：

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

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

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

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

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

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

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

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

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

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

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

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

以下面的案例說明：

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

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

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

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

這里不一一展開。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舉例說明：

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

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

分析：

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

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

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

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

❺ 如何進行軟體需求分析

軟體需求分析免費下載

鏈接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。

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

1.1 需求的背景

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

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

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

1.2 需求的受眾

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

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

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

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

1.3 需求的目的

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

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

1.4 需求的目標

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

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

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

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

其公式如下：

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

表1-需求評估加權表

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

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

❼ 如何做需求分析

你這個問題問的有點太大了，不知道怎麼回答，需求的工作存在很多靈活性，很難整理出一個流程性的東西，我也是正在學習，最近在學習徐峰老師的《軟體需求實踐》，把我知道的拿出來分享，錯了的話請大家糾正，但是不要噴我啊！妹子心裡素質不行，嘿嘿
1、需求是有層次的，分為業務需求、用戶需求以及系統需求，所以在進行需求分析時肯定是要根據不同層次階段進行不同方式、內容以及側重點的需求調研。
1）業務需求，一般是公司的高層提出的，就是我們這個系統的指導需求，這個需求比較空，但是卻是整個系統需求的指導思想，在做需求時經常想想這個知道思想，可以防止需求跑偏。

2）用戶需求，一般是公司的中層和操作層提出的需求。中層突出流程，就是整個框架，而操作層提出具體的細節性需求。就是往中層的框架裡面添加需求細節。

3）系統需求，就是針對前兩種需求調研之後得結果進行需求分析和業務建模之後，得到了系統開發的需求。

2、需求的步驟分為：需求定義（對應上面的業務需求）、需求捕獲（對應上面的用戶需求）、需求分析與需求建模（對應上面的系統需求）、需求驗證、需求跟蹤、需求管理。

3、做需求工程中可以使用的工具：AXURE（用來製作原型，讓用戶更直觀的了解即將做成什麼狀態的系統，便於需求確認）、EA（是建模工具，用來繪制UML圖，「一圖抵千言」為了更好的表達需求和溝通需求）、word、Excel、Visio等工具。

❽ 需求分析常用方法

行為事件分析

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

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

用戶留存分析

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

漏斗模型分析

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

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

行為路徑分析

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

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

❾ 需求分析常用方法都有哪些，請舉例說明

問卷調查法，是指設計方就用戶需求中的一些個性化的、需要進一步明確的需求或問題，通過採用向用戶問卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。 這種方法適合於設計方和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進一步溝通的需求或問題就比較少，通過採用這種簡單的問卷調查方法就能使問題得到較好的解決。顯然對於樂百氏集團這樣規模龐大的公司，簡單的問卷調查是不能夠滿足准確獲得需求的需要的。會議討論法，是指設計方和用戶相關人員召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法。這種方法適合於設計方不清楚用戶的詳細業務需求，但使用方清楚項目需求的情況。因為使用方清楚項目的需求，他們能准確地表達出他們的需求，而設計方有專業的需求，而我們有專業的軟體開發經驗，經過回憶討論交流之後，能夠對用戶的需求進行准確描述和把握。這個方法對於准確的獲得樂百氏公司的需求是一種不錯的選擇。在本案例中系統的設計人員也是這么做的，他們通過和樂百氏項目組經理的討論，很快了解了樂百氏的運作過程的數據。界面原型法，是指設計方根據自己所了解的用戶需求，描畫出應用系統的功能界面後與用戶進行交流和溝通，通過「界面原型」這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合於設計方和用戶都不是非常清楚項目需求、只是大概了解用戶需求的情況。因為設計方和用戶方都不能非常准確的描述出客戶的需求，因此此時就更需要藉助於一定的「載體」來加快對需求的挖掘和雙方對需求理解