如何調研需求的方法

Ⅰ 怎麼做才能充分了解顧客的需求

怎麼做才能充分了解顧客的需求？
為每一位顧客都是抱著某種需求才走進店的，所以，店員要盡快了解顧客的真正購買動機，才能向他推薦最合適的產品，店員向顧客做產品提示的目的也就在於此。然而，顧客的購買決策源於他們自己的想法，而非店員的想法，不同的顧客由於購買動機不一樣，會產生不同的購買行為，即會購買不同的產品，基於此，店員在做完產品提示後，必須要運用一些方法揣摩、找到顧客的真正需求。 怎樣才能了解到顧客的購買需求呢？我們可以通過下面幾種方法： （1）觀察購買信號。通過仔細觀察顧客的動作和表情來洞察他們的需求，找到顧客購買意願產生的線索。 ①觀察動作。顧客是匆匆忙忙，快步走進店尋找一款花色，還是漫不經心地閑逛；是三番五次拿起一件樣品打量，還是多次折回觀看。店員注意觀察顧客的這些舉動，就可以從中透視出他們的心理了。 ②觀察表情。當接過店員遞過去的樣品時，顧客是否顯示出興趣，面帶微笑，還是表現出失望和沮喪；當店員向其介紹產品時，他是認真傾聽，還是心不在焉，如果兩種情形下都是前者的話，說明顧客對產品基本滿意，如都是後者的話，說明產品根本不對顧客的胃口。 採用觀察法，切忌以貌取人。衣著簡朴的人可能會花大價錢購買名貴產品；衣著考究的人可能去買最便宜的系列產品。因此，店員不能憑主觀感覺去對待顧客，要尊重顧客的願望。 （2）推薦產品法。假如店員通過觀察法並未能准確地把握顧客的需求，那麼，不妨試一下推薦法。通過向顧客推薦一、兩件產品，觀看顧客的反應，就可以了解顧客的願望了。 例如：如果顧客只是簡單地應酬了一句，那麼店員可以採用下面的方法探測這位顧客： 「這個花色很好，很多人買。」顧客：「我不知道是不是這一花色和我家的風格是否合適。」「您家是什麼風格，是胡桃木色還是白色的，如果是深色我建議用中性色的地板，這一款就比較合適。」 就這樣，店員一句試探性的話，就達成了一筆交易。顧客所看的鬧表為話題，而是採用一般性的問話，如：「您要買什麼？」顧客：「沒什麼，我先隨便看看。」店員：「假如您需要的話，可以隨時叫我。」店員沒有得到任何關於顧客購買需要的線索。所以，店員一定要仔細觀察顧客的舉動，再加上適當的詢問和推薦，就會較快地把握顧客的需要了。 (3）詢問法。在上面的例子中我們可以看出，「詢問」在了解顧客需求的過程中是很重要的，但是作為一名顧客又非常討厭被別人探察，他們不願意被審問，有時候當店員想通過直接性提問去發現顧客的需求與要求時，往往發現顧客會產生抗拒而不是坦誠相告。所以，提問一定要以有技巧、巧妙、不傷害顧客感情為原則。 店員可以提出幾個經過精心選擇的問題有禮貌地詢問顧客，再加上有技巧的介紹產品和對顧客進行贊美，以引導顧客充分表達他們自身的真實想法。在詢問時要遵循三個原則： ①不要單方面的一味詢問。缺乏經驗的店員常常犯一個錯誤，就是過多地詢問顧客一些不太重要的問題或是接連不斷的提問題，使顧客有種「被調查」的不良感覺，從而對店員產生反感而不肯說實話。 ②詢問與產品提示要交替進行。因為「產品提示」和「詢問」如同自行車上的兩個輪子，共同推動著銷售工作，店員可以運用這種方式一點一點地往下探尋，就肯定能掌握顧客的真正需求。 ③詢問要循序漸進。店員可以從比較簡單的問題著手，如「請問，您買這種葯是給誰用的？」或「您想買瓶裝的還是盒裝的？」，然後通過顧客的表情和回答來觀察判斷是否需要再有選擇地提一些深入的問題，就象上面的舉例一樣，逐漸地從一般性討論縮小到購買核心，問到較敏感的問題時店員可以稍微移開視線並輕松自如地觀察顧客的表現與反應。 （4）傾聽法。「喜歡說，不喜歡聽」乃人性的弱點之一，如果店員一味地去表述自己的觀點，可能就會引起爭論或者馬上使顧客忘掉你所說的話。優秀的店員善於掌握此人性弱點，讓顧客暢所欲言，不論顧客的稱贊、說明、抱怨、駁斥，還是警告、責難、辱罵，她都會仔細傾聽，並適當有所反應，以表示關心和重視。因為顧客所言是「難以磨滅的」，店員可以從傾聽中了解到顧客的購買需求，又因為顧客尊重對那些能認真聽自己講話的人，願意去回報。因此，傾聽——用心聽顧客的話，不論對導購新手還是老手，都是一句終身受用不盡的忠告。 傾聽如此重要，那麼要如何洗耳恭聽呢？ ①做好「聽」的各種准備。首先要做好心理准備，要有耐心傾聽顧客的講話；其次要做好業務上的准備，對自己銷售的產品要了如指掌，要預先考慮到顧客可能會提出什麼問題，自己應如何回答，以免到時無所適從。 ②不可分神，要集中注意力。聽人說話也是一門學問，當顧客說話速度太快、或與事實不符時，店員絕不能心不在焉，更不能流露出不耐煩的表情。就象我們在第二章中所說的「推銷產品之前先推銷自己」一樣，一旦讓顧客發覺店員並未專心在聽自己講話，那店員也將失去顧客的信任，從而導致銷售失敗。 ③適當發問，幫顧客理出頭緒。顧客在說話時，原則上店員要有耐性，不管愛聽不愛聽都不要打斷對方，可是適時地發問，比一味地點頭稱是、或面無表情地站在一旁更為有效。 一個好的聽者既不怕承認自己的無知，也不怕向顧客發問，因為她知道這樣做不但會幫助顧客理出頭緒，而且會使談話更具體生動。為了鼓勵顧客講話，店員不僅要用目光去鼓勵顧客，還應不時地點一下頭，以示聽懂或贊同。例如：「我明白您的意思」、「您是說……」、「這種葯很不錯」，或者簡單地說一聲：「是的」、「不錯」等等。 ④從傾聽中，了解顧客的意見與需求。顧客的內心常有意見、需要、問題、疑難等等，店員就必須要讓顧客的意見發表出來，從而了解需要、解決問題、清除疑難。在店員了解到顧客的真正需求之前，就要找出話題，讓顧客不停地說下去，這樣不但可避免聽片斷語言而產生誤解，而且店員也可以從顧客的談話內容、聲調、表情、身體的動作中觀察、揣摩其真正的需求。 ⑤注意平時的鍛煉。聽別人講話也是一門藝術。店員在平時同朋友、家人、服務對象交談時，隨時都可以鍛煉聽力，掌握傾聽技巧，慢慢地就可以使傾聽水平有很大的提高，而且也可以從傾聽中學到許多有用的知識。 最後，提醒各位店員千萬不要自以為知道顧客想要什麼，必須仔細傾聽他們所講的每一句話，而且通過顧客的談話來鑒定他最關心的問題，而後根據他們的需要提出合理化建議，只有這樣，才能收到事半功倍的效果。

Ⅱ 如何做好需求分析，需求調研

轉載以下資料供參考

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。
原因
需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個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、問卷調查法：范圍大一些的調查，常採用問卷的方式進行。問卷即是書面提問的方式。問卷調查通過收集資料，然後作定量和定性的研究分析，歸納出調查結論。

(3)如何調研需求的方法擴展閱讀：

主要特點：

調查法是科學探究常用的方法之一，調查時要明確調查目的和調查對象，制定合理的調查方案，如實記錄，對結果進行整理和分析，有時還要用數學方法進行統計。常用的調查方法有普查法和抽樣法等。

調查法的主要特點是，以問題的方式要求被調查者針對問題進行陳述的方法。根據研究的需要，可以向被調查者本人作調查，也可以向熟悉被調查者的人作調查。調查法可以分為書面調查和口頭調查兩種。

調查法能夠同時收集到大量的資料，使用方便，並且效率高。

參考資料：調查法-網路

Ⅳ 如何通過客戶現場訪問調研用戶需求

客戶現場訪問是一種揭示客戶需求的定性市場調研方法。走到客戶工作現場，觀察客戶如何利用產品功能來解決問題，並記錄下客戶做了什麼，為什麼這么做、客戶使用該產品時遇到的問題是什麼，解決效果如何。在客戶訪問現場，面對面溝通能提供更多信息，特別是當訪問是在徵得客戶同意時；經常能夠看到產品的使用情形，對產品的優點和缺點進行第一手觀察，可以直接與客戶討論應該做哪些改進。客戶現場訪問對於參與新產品開發的產品經理特別有用，可以通過提問和觀察的方式來洞察客戶「內心」——超越當前產品——的需求，理解如何將客戶需求轉換為產品設計規范。
這種方法的主要挑戰是如何使客戶配合公司訪談，同意參與訪談並提供誠實的回答。一個產品經理可以計劃與銷售人員或客戶經理一起拜訪客戶，提前就需要拜訪的對象與銷售人員或客戶經理進行溝通，獲取支持，B2B模式的目標客戶類型包括買方、用戶、影響者和決策者。當組織訪談時，一份結構良好、精心構思的談話指導十分重要。這些指導的作用是合理安排問題和話題，確保整個訪談的完整性和一致性，並提供記錄回答的地方。在訪談過程中，他們發掘使用者所追求的利益、功能和需要，而不僅僅是產品特點。因此，最好的問題是間接並可推理的。

案例：「你想從新產品中得到什麼？」
間接問題可以使你對使用者的喜好、厭惡、問題、最關心的地方、無法滿足和不能用語言表達的需要有更深入的理解。
一旦訪談完成，訪談團隊應該實施一個非正式調查，即和確實在使用新產品的客戶相處一段時間。通常，通過觀察他們對產品的使用、誤用及對產品的濫用，公司可以得到更多關於無法滿足的需要的啟發。
客戶現場訪問是B2B企業用最多的一種市場研究方法，它涉及與供應商的一個或多個客戶（或潛在客戶）進行直接交流，能夠洞察到技術或競爭者的產品信息，獲得客戶不能或者不願表達的隱性需求信息。

Ⅳ 需求分析常用方法

行為事件分析

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

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

用戶留存分析

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

漏斗模型分析

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

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

行為路徑分析

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

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

Ⅵ 如何做產品業務需求調研

怎麼做需求分析？

能夠像主角鎮長一樣找到村民真實的需求呢？

首先，需求分析應該服務於用戶，所以要以用戶為中心做需求分析

其次，需求分析後要形成一份PRD，讓團隊里的人更流程地工作，減少溝通成本

那麼，它的步驟是怎樣的？

第一步：給你的產品定個位

「請用一句話描述你的產品」

（結構是：主要面向XX用戶，提供XX功能，具有XX特色）

這個方法誰用誰知道，如果很難描述出來的話，你的這個產品就定位有點模糊了，方向也不明確。

第二步：找到初步需求

首先，通過用戶研究、頭腦風暴等方法，產出用戶需求示意列表

得到初步需求後，先把不可實現、不合理、價值不大、無適合場景的需求剔除。——篩選

然後，挖掘用戶的目標，找到用戶真實的需求。——挖掘

這里需要注意的兩點是：

1、傾聽用戶並不等於聽從用戶

2、用戶想要什麼不等於真實需求

接著就是匹配產品定位，找出產品主要功能和特色功能。——匹配

最後就是根據項目的資源來確定需求的優先順序

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

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

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

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

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

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

以下面的案例說明：

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

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

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

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

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

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

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

下面的案例說明：

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

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

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

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

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

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

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

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

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

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

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

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

以下面的案例說明：

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

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

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

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

這里不一一展開。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舉例說明：

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

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

分析：

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

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

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

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

Ⅷ 如何進行需求調研

力，才能真正體現出軟體的價值。
4.編寫用戶需求說明書
需求調研的步驟
需求分析員對收集到的所有需求信息進行分類整理，消除錯誤，歸納與總結共性的用戶需求，然後形成文檔，編寫《用戶需求說明書》。對於《用戶需求說明書》要和客戶以及相關的行業專家進行共同評審。以前整理的需求記錄可以作為附件整理在《用戶需求說明書》之後。
《用戶需求說明書》與《產品需求規格說明書》的主要區別與聯系是：
（1）前者主要採用自然語言（和應用域術語）來表達用戶需求，其內容相對於後者而言比較粗略，不夠詳細。
（2）後者是前者的細化，更多地採用計算機語言和圖形符號來刻畫需求，產品需求是軟體系統設計的直接依據。
（3）兩者之間可能並不存在一一影射關系，因為軟體開發商會根據產品發展戰略、企業當前狀況適當地調整產品需求，例如用戶需求可能被分配到軟體的數個版本中。軟體開發人員應當依據《產品需求規格說明書》來開發當前產品。
需求調研的步驟
用戶需求說明書的模板
需求調研中的注意事項
對每一次的調研形成正確的文檔
需求調研中的注意事項
需求調研是一個漫長的過程。能夠正確理解用戶的需求，並且將用戶的各種需求完整地體現在《軟體需求規格說明書》中將更是一個復雜而艱辛的過程，因此在每一次的會談之後必須將當天的會談紀錄形成文檔，可以以備忘錄的形式讓用戶進行確認。
需求調研後形成的文檔文檔必須是正確的，是經過驗證的，是在受控的狀態下變更的。而很多開發人員往往會問：「簡單的系統就不用寫需求了吧？」其實簡單的系統未必簡單，只有想清楚、寫清楚、說清楚才說明已經真正把需求整理清楚了。
做好需求變更的控制
需求調研中的注意事項
對每一次的變更要雙發進行確認，並進行版本控制，做到有據可依。

Ⅸ 需求分析的主要方法是

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