需求分析的工作方法

① 培訓需求分析的方法有哪些

1、問卷調研法。

問卷調研法是最普遍也最有效的收集資料和數據的方法之一。一般由培訓部門設計一系列培訓需求相關問題，以書面問卷的形式發放給培訓對象，待培訓對象填寫之後再收回進行分析，獲取培訓需求的信息和數據。

2、訪談法。

訪談法也是數據收集的一種重要方法。它是指為了得到培訓需求的數據和信息，與訪談對象進行面對面交流的活動過程。這個過程不只是收集硬性數據，比如事實、數據等，包括印象、觀點、判斷等信息。

3、小組討論法。

小組討論法是指從培訓對象中選出一部分有代表性且熟悉問題的員工作為代表，通過討論的形式調查培訓需求信息。小組討論法的形式比較靈活，可以是正式的也可以是非正式的，可以通過頭腦風暴、組織對照等多種方式進行。

培訓需求分析的三個層次：

1、必須在崗位任職人員的個體層次上進行分析。在這一層次上，培訓部門、培訓崗位主管共同對企業員工進行需求分析，確定參加培訓的人員和培訓內容。

2、是在組織層次上的培訓需求分析，它是從客觀的角度對組織近中期的目標，以及培訓效果轉換的組織氛圍和企業整體人力資源存量進行分析，設計員工的培訓計劃。

3、是在戰略層面上的分析。戰略分析不是集中在個體、組織、部門現在有效工作所需要的知識、技能和能力上。例如，未來需要多少或什麼類型的工作人員、組織是否現在正經歷和將要經歷能夠影響從事工作方式的巨大變化等。

② 需求分析的十個步驟

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）角色分析：分析該需求涉及的角色及在本需求內容的行為；

（3）業務流程分析：分析該需求涉及的業務流程、以流程圖或用例圖表示；

（4）數據分析：分析該需求涉及數據項的名稱、含義、格式、規則；

（5）全線分析：定義各角色在該需求中的行為；

（6）界面分析：分析實現該需求的界面風格、表單樣式及頁面布局；

（7）性能分析：分析該需求的最大數據量、訪問頻度，定義用戶訪問時間等要求；

（8）耦合性分析：分析該需求和其他需求的相互關系及影響。

④ 需求分析常用方法

行為事件分析

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

以用戶投標的行為事件為例，出借人在完成投標過程中，所進行的注冊、認證、開戶、充值、投資等行為，都可以定義為事件，也是完成投標成功的一個完整事件。
確定投標行為事件後，我們可以根據事件屬性細分維度：用戶來源、性別、出生年月、注冊時間、綁卡時間、首次充值時間、首次投資時間、標的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-需求評估加權表

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

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

⑥ 簡要闡述需求分析的幾大技巧

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

  

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

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

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

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

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

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

需求分析原則

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

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

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

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

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

轉載以下資料供參考

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。
原因
需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個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. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。

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

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

下面的案例說明：

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

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

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

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

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

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

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

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

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

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

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

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

以下面的案例說明：

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

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

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

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

這里不一一展開。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舉例說明：

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

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

分析：

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

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

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

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

⑩ 需求分析有哪兩種主要分析方法

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