如何改進需求分析的方法和策略

『壹』 需求分析的主要方法是什麼

1.1 需求的背景

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

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

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

1.2 需求的受眾

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

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

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

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

1.3 需求的目的

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

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

1.4 需求的目標

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

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

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

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

其公式如下：

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

表1-需求評估加權表

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

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

『貳』 如何做好需求分析，需求調研

轉載以下資料供參考

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

需求分析20條法則
客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦（如一方要求而另一方不願意或不能夠滿足要求）。
1、 分析人員要使用符合客戶語言習慣的表達
需求討論集中於業務需求和任務，因此要使用術語。客戶應將有關術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。
2、分析人員要了解客戶的業務及目標
只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助於開發人員設計出真正滿足客戶需要並達到期望的優秀軟體。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新系統，那麼開發和分析人員應使用一下舊系統，有利於他們明白系統是怎樣工作的，其流程情況以及可供改進之處。
3、 分析人員必須編寫軟體需求報告
分析人員應將從客戶那裡獲得的所有信息進行整理，以區分業務需求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客戶就能得到一份「需求分析報告」，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易於翻閱和理解的方式組織編寫。客戶要評審此報告，以確保報告內容准確完整地表達其需求。一份高質量的「需求分析報告」有助於開發人員開發出真正需要的產品。
4、 要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性「需求分析報告」的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的價值；雖然它們不太難於理解，但是客戶可能對此並不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。
5、 開發人員要尊重客戶的意見
如果用戶與開發人員之間不能相互理解，那關於需求的討論將會有障礙。共同合作能使大家「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間，同樣，客戶也應對開發人員為項目成功這一共同目標所做出的努力表示尊重。
6、 開發人員要對需求及產品實施提出建議和解決方案
通常客戶所說的「需求」已經是一種實際可行的實施方案，分析人員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的事情後，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人員還能提出增加一些用戶沒有發現的很有價值的系統特性。
7、 描述產品使用特性
客戶可以要求分析人員在實現功能需求的同時還注意軟體的易用性，因為這些易用特性或質量屬性能使客戶更准確、高效地完成任務。例如：客戶有時要求產品要「界面友好」或「健壯」或「高效率」，但對於開發人員來講，太主觀了並無實用價值。正確的做法是，分析人員通過詢問和調查了解客戶所要的「友好、健壯、高效所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡，以確保做出合理的取捨。
8、 允許重用已有的軟體組件
需求通常有一定靈活性，分析人員可能發現已有的某個軟體組件與客戶描述的需求很相符，在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠降低新系統的開發成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們並不完全適合您所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。
9、 要求對變更的代價提供真實可靠的評估
有不同的選擇。而這時，對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。所以，客戶有權利要求開發人員通過分析給出一個真實可信的評估，包括影響、成本和得失等。開發人員不能由於不想實施變更而隨意誇大評估成本。
10、 獲得滿足客戶功能和質量要求的系統
每個人都希望項目成功，但這不僅要求客戶要清晰地告知開發人員關於系統「做什麼」所需的所有信息，而且還要求開發人員能通過交流了解清楚取捨與限制，一定要明確說明您的假設和潛在的期望，否則，開發人員開發出的產品很可能無法讓您滿意。
11、 給分析人員講解您的業務
分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析人員能把握客戶業務的細微潛在之處，他們可能不知道那些對於客戶來說理所當然的「常識」。
12、 抽出時間清楚地說明並完善需求
客戶很忙，但無論如何客戶有必要抽出時間參與「頭腦高峰會議」的討論，接受采訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點，而過後發現還需要您的講解，這時請耐心對待一些需求和需求的精化工作過程中的反復，因為它是人們交流中很自然的現象，何況這對軟體產品的成功極為重要。
13、 准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的。由於處理細節問題不但煩人而且耗時，因此很容易留下模糊不清的需求。但是在開發過程中，必須解決這種模糊性和不準確性，而客戶恰恰是為解決這些問題作出決定的最佳人選，否則，就只好靠開發人員去正確猜測了。
在需求分析中暫時加上「待定」標志是個方法。用該標志可指明哪些是需要進一步討論、分析或增加信息的地方，有時也可能因為某個特殊需求難以解決或沒有人願意處理它而標註上「待定」。客戶要盡量將每項需求的內容都闡述清楚，以便分析人員能准確地將它們寫進「軟體需求報告」中去。如果客戶一時不能准確表達，通常就要求用原型技術，通過原型開發，客戶可以同開發人員一起反復修改，不斷完善需求定義。
14、 及時作出決定
分析人員會要求客戶作出一些選擇和決定，這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切，盡快做處理，做決定，因為開發人員通常只有等客戶做出決定才能行動，而這種等待會延誤項目的進展。
15、 尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本。客戶所希望的某些產品特性可能在技術上行不通，或者實現它要付出極高的代價，而某些需求試圖達到在操作環境中不可能達到的性能，或試圖得到一些根本得不到的數據。開發人員會對此作出負面的評價，客戶應該尊重他們的意見。
16、 劃分需求的優先順序
絕大多數項目沒有足夠的時間或資源實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，是需求開發的主要部分，這只能由客戶負責設定需求優先順序，因為開發者不可能按照客戶的觀點決定需求優先順序；開發人員將為您確定優先順序提供有關每個需求的花費和風險的信息。
在時間和資源限制下，關於所需特性能否完成或完成多少應尊重開發人員的意見。盡管沒有人願意看到自己所希望的需求在項目中未被實現，但畢竟是要面對現實，業務決策有時不得不依據優先順序來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。
17、 評審需求文檔和原型
客戶評審需求文檔，是給分析人員帶來反饋信息的一個機會。如果客戶認為編寫的「需求分析報告」不夠准確，就有必要盡早告知分析人員並為改進提供建議。更好的辦法是先為產品開發一個原型。這樣客戶就能提供更有價值的反饋信息給開發人員，使他們更好地理解您的需求；原型並非是一個實際應用產品，但開發人員能將其轉化、擴充成功能齊全的系統。
18、 需求變更要立即聯系
不斷的需求變更，會給在預定計劃內完成的質量產品帶來嚴重的不利影響。變更是不可避免的，但在開發周期中，變更越在晚期出現，其影響越大；變更不僅會導致代價極高的返工，而且工期將被延誤，特別是在大體結構已完成後又需要增加新特性時。所以，一旦客戶發現需要變更需求時，請立即通知分析人員。
19、 遵照開發小組處理需求變更的過程
為將變更帶來的負面影響減少到最低限度，所有參與者必須遵照項目變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最後做出合適的決策，以確定應將哪些變更引入項目中。
20、 尊重開發人員採用的需求分析過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性，分析人員採用的方法有其合理性。也許客戶認為收集需求的過程不太劃算，但請相信花在需求開發上的時間是非常有價值的；如果您理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術，那麼整個過程將會更為順利。
「需求確認」意味著什麼
在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標志行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文檔的最後一行下面簽名，於是我就簽了，否則這些開發人員不開始編碼。」
這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上簽了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」
同樣問題也會發生在僅把「簽字確認」看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著「需求分析報告」說：「您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什麼，您應早些告訴我們。」
這兩種態度都是不對的。因為不可能在項目的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。
對「需求分析報告」的簽名是建立在一個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文檔表述了我們對項目軟體需求的了解，進一步的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和項目階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦來源於項目的改進和需求的誤差或市場和業務的新要求等。 需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成一個持續良好的客戶與開發人ONT>

『叄』 項目需求分析的分析方法

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

『肆』 需求分析有哪兩種主要分析方法

從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。

『伍』 如何做好客戶的需求分析

分析客戶需求是銷售的一個關鍵點，知道客戶需要什麼，才能更好地制定銷售策略。了解客戶的真實需求，需要我們多站在客戶的角度上思考問題，而在與客戶交談中，也要多用心聆聽，從談話內容中掌握用戶的關注點，是產品的質量還是價格還是優惠福利。察覺出用戶的關注點之後，我們就可以適時地將談話中心放在這些因素上，引導客戶最終達成交易。

1、心理分析模式

心理分析模式，又稱為需求的驅策力分析模式。這種分析模式認為投保人的投保行為是由於需求的存在而促發的，而需求則是由投保人內在的驅策力引起的。

這種使人們產生需求的驅策力又可分為原始驅策力和學習驅策力原始驅策力是人們對生理方面的需求，是非理性因素的行為。需求的產生，是以學習驅策力為主，原始驅策力為輔而引起的。保險營銷人員，可針對不同的投保人與險種，採用不同的分析模式，也可同時採用兩種或更多的分析模式來加以分析

2、、經濟分析模式

經濟分析模式是保險營銷人員注重從險種的保費以及與此保費相對應的保障程度、投保人的整體效益等因素來考慮對投保人行為的影響，即它主要強調由投保人的經濟動機的推動而產生的投保行為。

通過經濟分析，明白這個投保人的投保能力有多少，這樣就可以在制定好計劃書之後，做好完全的准備之後，再來找這個客戶商談。

(5)如何改進需求分析的方法和策略擴展閱讀：

客戶需求指在廣泛和深入地了解客戶的實際需求，從而幫助企業做出正確的決策。不管是經濟低迷還是高漲，企業的生存發展都應該始終以客戶需求為導問，也只有以客戶的需求為導向，不斷完善業務的發展方向，才能贏取更多消費者的青睞，提高客戶滿意度。

要想說服客戶，就必須了解他當前的需要，然後著重從這一層次的需要出發，動之以情，曉之以理。在與客戶溝通的過程中，你可以通過觀察客戶非語言行為了解他的需要慾望、觀點和想法。

總而言之，通過適當地問問題，用心去傾聽，以及觀察他們非語言行為，可以了解客戶的需求和想法，更好地為他們服務。

網路-客戶需求

『陸』 簡要闡述需求分析的幾大技巧

• 進行有效的需求分析需要：制定計劃和方案。要進行有效的需求分析，需要有具體的計劃和方案，需要根據目前自己掌握的情況來確定自己的具體工作內容。有了計劃和方案，更利於自己高效完成工作，也知道朝著什麼方向努力。

  

『柒』 需求分析常用方法

行為事件分析

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

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

用戶留存分析

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

漏斗模型分析

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

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

行為路徑分析

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

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

『捌』 調節需求有哪幾種策略其應用條件及限制如何

根據生產管理學的理論知識來說：

1、改變庫存、改變價格需求轉移需求；
2、改變生產效率、加班加點、改變需求；
3、改變員工人員的數量；
4、編制滾動式計劃；
5、推遲交貨時間。推遲一段時間交貨，同時給顧客一定的價格折 扣。 能否成功應用這種策略取決於顧客的態度，推遲交貨有損失和失去顧客的危險；

『玖』 如何進行需求分析

項目需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。 在原則上，需求階段監理應尊重承建方的項目管理和項目分析能力；在具體的任務開展上，以不深入、不幹擾承建方的自主權為主，除非在項目合作過程中發現承建方的項目管理以及項目分析能力存在很大的差距和不足。 為了保證項目的成功，監理方必須加強項目管理和項目分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。其中，需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。而項目的整體風險往往表現在需求分析不明確、業務流程不合理，用戶不習慣或不願意去用承建方的軟體。作為第三方的監理公司，必須提醒承建方、客戶方重視需求分析的重要性，採用必要的手段和方法來進行需求調研，同時監理方也應深入具體的需求調研中去。只有這樣才能切切實實地把握用戶的需求和方向，才能在將來的功能界定、開發范圍上有發言權。 需求分析不象偵探推理那樣需從蛛絲馬跡著手，而是應該先了解宏觀的問題，再了解細節的問題。 一個應用軟體系統（記為S）的涉及面可能很廣，可以按不同的問題域（記為D）分類，每個問題域對應於一個軟體子系統。 S={D1，D2，D3，…Dn} 問題域Di由若干個問題（記為P）組成，每個問題對應於子系統中的一個軟構件。 Di={P1，P2，P3，…Pm} 問題Pj有若干個行為（或功能，記為F），每個行為對應於軟構件中的實現介面。 Pj={F1，F2，F3，…Fk} 需求說明書應該對於那些只想了解宏觀需求的領導，和需要了解細節的技術員都合適。在寫需求說明書時應該注意兩個問題： 1.最好為每個需求注釋「為什麼」，這樣可讓程序員了解需求的本質，以便選用最合適的技術來實現此需求。 2.需求說明不可有二義性，更不能前後相矛盾。如果有二義性或前後相矛盾，則要重新分析此需求。 重點監控需求分析 由於項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟體需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本是由於以下情況造成的。 客戶說不清楚需求 有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多部門、機構、單位在進行應用系統以及網路建設時，客戶方的辦公人員大多不清楚計算機網路有什麼用，更缺乏IT系統建設方面的專家和知識。此時，用戶就會要求軟體系統分析人員替他們設想需求。工程的需求存在一定的主觀性，為項目未來建設埋下了潛在的風險。 需求自身經常變動 根據以往的歷史經驗，隨著客戶方對信息化建設的認識和自己業務水平的提高，他們會在不同的階段和時期對項目的需求提出新的要求和需求變更。事實上，歷史上沒有一個軟體的需求改動少於三次的！所以必須接受「需求會變動」這個事實，在進行需求分析時要懂得防患於未然，盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟體的核心建築在穩定的需求上，同時留出變更空間。咨詢監理方在需求分析的功能界定上擔任一個中間、公平、公正的角色，所以也必須積極參與到需求分析的准備中來，以便協助客戶方和承建方來界定「做什麼」、「不做什麼」的系統功能界限。 分析人員或客戶理解有誤 軟體系統分析人員不可能都是全才，更不可能是行業方面的專家。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以後的開發工作勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：「主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜裡能射出強光……有趣的是，車里住著一種叫作『人』的寄生蟲，這些寄生蟲完全控制了車。」所以分析人員知識的專一性也會造成需求分析的誤解和失敗。這時，咨詢監理公司就必須根據實際的項目需求調研計劃，提醒承建方加強業務了解程度和注重溝通技巧。 需求分析方法論 根據以往的工程經驗，需求分析工作方法，應該定位在「三個階段」（也稱「三步法」）。 第一階段：「訪談式」（Visitation） 這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的介面人。 實現手段：訪談、調查表格 輸出成果：調查報告、業務流程報告 第二階段：「誘導式」（Incement） 這一階段是在承建方已經了解了具體用戶方的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體實際、客觀的信息基礎上，結合現有的硬體、軟體實現方案，做出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶採用誘導式、啟發式的調研方法和手段，和用戶一起探討業務流程設計的合理性、准確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業務流程的設計合理性、准確性等等問題，及時地提出改進意見和方法。 實現手段：拜訪（誘導）、原型演示 輸出成果：調研分析報告、原型反饋報告、業務流程報告 第三階段：「確認式」（Afirm） 這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，並能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查業務流程報告、數據項表以及操作承建方提供的DEMO系統，來提出反饋意見，並對已經可接受的報告、文檔簽字確認。 實現手段：拜訪（回顧、確認），提交業務流程報告、數據項表；原型演示系統 輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見（後三者可以統一歸入需求分析報告中，提交用戶方、監理方進行確認和存檔） 整體來講，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和採用，對用戶和承建方都同樣提供了項目成功的保證。當然在系統建設的過程中，特別在採用迭代法的開發模式時，需求分析的工作需一直進行下去，而在後期的需求改進中，工作則基本集中在後兩個階段中。