❶ 需求分析和系統設計應該採用什麼樣的方法更能體現系統本質
1 需求分析的任務與過程
需求分析所要做的工作是深入描述軟體的功能和性能，確定軟體設計的限制和軟體同其他系統元素的介面細節，定義軟體的其他有效性需求，細化軟體要處理的數據域。用一句話概括就是：需求分析主要是確定待開發軟體的功能、性能、數據、界面等要求。需求分析的實現步驟通常包括：獲取當前系統的物理模型，抽象出當前系統的邏輯模型，建立目標系統的邏輯模型三個部分。具體來說，需求分析階段的工作可以分成 4 個方面：
（1）問題識別：用於發現需求、描述需求，主要包括功能需求、性能需求、環境需求、可靠性需求、安全保密需求、用戶界面需求、資源使用需求、軟體成本消耗與開發進度需求，以此來預先估計以後系統可能達到的目標。
（2）分析與綜合：也就是對問題進行分析，然後在此基礎上整合出解決方案。這個步驟經常是反復進行的，常用的方法有面向數據流的結構化分析方法（Structured Analysis， SA），面向數據結構的 Jackson 方法，面向對象的分析方法（Object Oriented Analysis，OOA），以及用於建立動態模型的狀態遷移圖和 Petri 網。
（3）編制需求分析的文檔：也就是對已經確定的需求進行文檔化描述，該文檔通常稱為「需求規格說明書」。
（4）需求分析與評審：它是需求分析工作的最後一步，主要是對功能的正確性、完整性和清晰性，以及其他需求給予評價。
❷ 需求分析有哪兩種主要分析方法
從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。
❸ 系統分析方法有哪幾種
系統分析方法（System Analysis Method）
什麼是系統分析方法
系統分析方法是指把要解決的問題作為一個系統，對系統要素進行綜合分析，找出解決問題的可行方案的咨詢方法。蘭德公司認為，系統分析是一種研究方略，它能在不確定的情況下，確定問題的本質和起因，明確咨詢目標，找出各種可行方案，並通過一定標准對這些方案進行比較，幫助決策者在復雜的問題和環境中作出科學抉擇。
系統分析方法來源於系統科學。系統科學是20世紀40年代以後迅速發展起來的一個橫跨各個學科的新的科學部門，它從系統的著眼點或角度去考察和研究整個客觀世界，為人類認識和改造世界提供了科學的理論和方法。它的產生和發展標標志著人類的科學思維由主要以「實物為中心」逐漸過渡到以「系統為中心」，是科學思維的一個劃時代突破。
系統分析是咨詢研究的最基本的方法，我們可以把一個復雜的咨詢項目看成為系統工程，通過系統目標分析、系統要素分析、系統環境分析、系統資源分析和系統管理分析，可以准確地診斷問題，深刻地揭示問題起因，有效地提出解決方案和滿足客戶的需求。
咨詢工具
安索夫矩陣
案例面試分
析工具/框架
ADL矩陣
安迪·格魯夫的
六力分析模型
波士頓矩陣
標桿分析法
波特五力分析
模型
波特價值鏈
分析模型
波士頓經驗曲線
波特鑽石理論模型
貝恩利潤池
分析工具
波特競爭戰略
輪盤模型
波特行業競爭結構
分析模型
波特的行業組織
模型
變革五因素
BCG三四規則矩陣
產品/市場演變
矩陣
差距分析
策略資訊系統
策略方格模型
CSP模型
創新動力模型
定量戰略計劃矩陣
大戰略矩陣
多點競爭戰略
杜邦分析法
定向政策矩陣
德魯克七種
革新來源
二元核心模式
服務金三角
福克納和鮑曼的
顧客矩陣
福克納和鮑曼的
生產者矩陣
FRICT籌資分析法
GE矩陣
蓋洛普路徑
公司層戰略框架
高級SWOT分析法
股東價值分析
供應和需求模型
關鍵成功因素
分析法
崗位價值評估
規劃企業願景的
方法論框架
核心競爭力分析
模型
華信惠悅人力
資本指數
核心競爭力識別
工具
環境不確定性分析
行業內的戰略群體
分析矩陣
橫向價值鏈分析
行業內戰略集團
分析
IT附加價值矩陣
競爭態勢矩陣
基本競爭戰略
競爭戰略三角模型
競爭對手分析論綱
價值網模型
績效稜柱模型
價格敏感性測試法
競爭對手的成本分析
競爭優勢因果關系
模式
競爭對手分析工具
價值鏈分析方法
腳本法
競爭資源四層次模型
價值鏈信息化管理
KJ法
卡片式智力激勵法
KT決策法
擴張方法矩陣
利益相關者分析
雷達圖分析法
盧因的力場分析法
六頂思考帽
利潤庫分析法
流程分析模型
麥肯錫7S模型
麥肯錫七步分析法
麥肯錫三層面理論
麥肯錫邏輯樹分析法
麥肯錫七步成詩法
麥肯錫客戶盈利性
矩陣
麥肯錫5Cs模型
內部外部矩陣
內部因素評價矩陣
諾蘭的階段模型
牛皮紙法
內部價值鏈分析
NMN矩陣分析模型
PEST分析模型
PAEI管理角色模型
PIMS分析
佩羅的技術分類
PESTEL分析模型
企業素質與活力分析
QFD法
企業價值關聯分析
模型
企業競爭力九力分析
模型
企業戰略五要素分析法
人力資源成熟度模型
人力資源經濟分析
RATER指數
RFM模型
瑞定的學習模型
GREP模型
人才模型
ROS/RMS矩陣
3C戰略三角模型
SWOT分析模型
四鏈模型
SERVQUAL模型
SIPOC模型
SCOR模型
三維商業定義
虛擬價值鏈
SFO模型
SCP分析模型
湯姆森和斯特克蘭
方法
V矩陣
陀螺模型
外部因素評價矩陣
威脅分析矩陣
新7S原則
行為錨定等級評價法
新波士頓矩陣
系統分析方法
系統邏輯分析方法
實體價值鏈
信息價值鏈模型
戰略實施模型
戰略鍾模型
戰略地位與行動
評價矩陣
戰略地圖
組織成長階段模型
戰略選擇矩陣
專利分析法
管理要素分析模型
戰略群模型
綜合戰略理論
縱向價值鏈分析
重要性-迫切性模型
知識鏈模型
知識價值鏈模型
知識供應鏈模型
組織結構模型
[編輯]
系統分析方法的分類
1）系統特徵分析方法；
2）系統邏輯分析方法；
3）系統工程技術。
系統分析方法的步驟
系統分析方法的具體步驟包括：限定問題、確定目標、調查研究收集數據、提出備選方案和評價標准、備選方案評估和提出最可行方案。
1、 限定問題
所謂問題，是現實情況與計劃目標或理想狀態之間的差距。系統分析的核心內容有兩個：其一是進行「診斷」，即找出問題是及其原因；其二是「開處方」，即提出解決問題的最可行方案。所謂限定問題，就是要明確問題的本質或特性、問題存在范圍和影響程度、問題產生的時間和環境、問題的症狀和原因等。限定問題是系統分析中關鍵的一步，因為如果「診斷」出錯，以後開的「處方」就不可能對症下葯。在限定問題時，要注意區別症狀和問題，探討問題原因不能先入為主，同時要判別哪些是局部問題，哪些是整體問題，問題的最後確定應該在調查研究之後。
2、確定目標
系統分析目標應該根據客戶的要求和對需要解決問題的理解加以確定，如有可能應盡量通過指標表示，以便進行定量分析。對不能定量描述的目標也應該盡量用文字說明清楚，以便進行定性分析和評價系統分析的成效。
3、調查研究，收集數據
調查研究和收集數據應該圍繞問題起因進行，一方面要驗證有限定問題階段形成的假設，另一方面要探討產生問題的根本原因，為下一步提出解決問題的備選方案做准備。
調查研究常用的有四種方式，即閱讀文件資料、訪談、觀察和調查。
收集的數據和信息包括事實（facts）、見解(opinions)和態度(attitudes)。要對數據和信息去偽存真，交叉核實，保證真實性和准確性。
4、提出備選方案和評價標准
通過深入調查研究，使真正有待解決的問題得以最終確定，使產生問題的主要原因得到明確，在此基礎上就可以有針對性地提出解決問題的備選方案。備選方案是解決問題和達到咨詢目標可供選擇的建議或設計，應提出兩種以上的備選方案，以便提供進一步評估和篩選。為了對備選方案進行評估，要根據問題的性質和客戶具備的條件。提出約束條件或評價標准，供下一步應用。
5、備選方案評估
根據上述約束條件或評價標准，對解決問題備選方案進行評估，評估應該是綜合性的，不僅要考慮技術因素，也要考慮社會經濟等因素，評估小組應該有一定代表性，除咨詢項目組成員外，也要吸收客戶組織的代表參加。根據評估結果確定最可行方案。
6、提交最可行方案
最可行方案並不一定是最佳方案，它是在約束條件之內，根據評價標准篩選出的最現實可行的方案。如果客戶滿意，則系統分析達到目標。如果客戶不滿意，則要與客戶協商調整約束條件或評價標准，甚至重新限定的問題，開始新一輪系統分析，直到客戶滿意為止。
系統分析方法的案例分析
案例一:某鍛造廠系統分析方法分析
某鍛造廠是以生產解放、東風140和東風130等汽車後半軸為主的小型企業，現在年生產能力為1.8萬根，年產值為130元。半軸生產工藝包括鍛造、熱處理、機加工、噴漆等23道工序，由於設備陳舊，前幾年對某些設備進行了更換和改造，但效果不明顯，生產能力仍然不能提高。廠領導急於要打開局面，便委託M咨詢公司進行咨詢。M咨詢公司採用系統分析進行診斷，把半軸生產過程作為一個系統進行解剖分析。通過限定問題，咨詢人員發現，在半軸生產23道工序中，生產能力嚴重失調，其中班產能力為120-190根的有9道工序，主要是機加工設備。班產能力為70-90根的有6道工序，主要是淬火和矯直設備。其餘工序班產能力在30-45根之內，都是鍛造設備。由於機加工和熱處理工序生產能力大大超過鍛造工序，造成前道工序成為「瓶頸」，嚴重限制後道工序的局面，使整體生產能力難於提高。所以，需要解決的真正問題是如何提高鍛造設備能力？
在限定問題的基礎上，咨詢人員與廠方一起確定出發展目標，即通過對鍛造設備的改造，使該廠汽車半軸生產能力和年產值都提高1倍。
圍繞如何改造鍛造設備這一問題，咨詢人員進行深入調查研究，初步提出了四個備選方案，即：新裝一台平鍛機；用軋同代替原有夾板錘；用軋制機和碾壓機代替原有夾板錘和空氣錘；增加一台空氣錘。
咨詢人員根據對廠家人力物力和資源情況的調查分析，提出對備選方案的評價標准或約束條件，即：投資不能超過20萬元；能與該廠技術水平相適應，便於維護；耗電量低；建設周期短，回收期快。咨詢小組吸收廠方代表參加，根據上述標准對各備選方案進行評估。第1個方案（新裝一台平鍛機），技術先進，但投資高，超過約束條件，應予以淘汰。對其餘三個方案，採取打分方式評比，結果第4方案（增加一台空氣錘）被確定為最可行方案，該方案具有成本低，投產周期短，耗電量低等優點，技術上雖然不夠先進，但符合小企業目前的要求，客戶對此滿意，系統分析進展順利，為該項咨詢提供了有力的工具。
本條目對我有幫助
70
分享到：
❹ 需求分析的步驟有哪些
一、需求識別
需求人員在此步驟應該分析需求類別、需求復雜度和需求價值用來確定需求實施的優先順序。
1.需求類別確認：
需求類別包含流程類需求、統計分析類需求、介面類需求，一個需求可能為某一類型需求，也可能包含多類需求。
確認需求類別後應對每類需求的數量進行初步分析（比如流程類需求包含幾個流程、統計分析類需求包含幾個報表、介面類需求包含幾個介面）。
2.需求復雜度分析：
一般需求受理工作量在1-5人天的需求復雜度低，工作量在5-15人天的需求復雜度中，工作量在15人天以上需求復雜度高。（工作量表示需求受理全過程需求人員需要付出的工作量）。
3.價值分析：
需求人員收到需求後應根據收集需求內容初步分析需求痛點/目標、需求復雜度、業務重要程度確定需求價值，需求價值分析
二、業務流程/統計查詢/介面分析
針對流程類需求必須進行業務流程分析，統計查詢和介面類需求可不進行詳細的流程分析。
1.業務流程分為部門級、組織級和崗位級
部門級流程關注脈絡需要分析涉及哪些具體崗位、執行活動、每個活動之間的關聯關系，它是需求分析的主線條，也是流程分析的主要產物。
組織級流程關注宏觀一般不會直接繪制，是對部門級流程的概括和抽象。
崗位級流程關注每個業務活動的執行步驟屬需求細節范疇，在流程分析階段不要過度進入細節。
2.需求識別階段確認的流程均為部門級流程
需求人員在進行流程分析應遵循如下方法：
（1）業務流程確認：
一個流程為一個業務事件，一般是外部角色發起或系統內部主動發起（比如時間事件或狀態事件），發起後會觸發一系列業務活動。
（2）角色及業務活動確認：
流程圖中的每個泳道都必須對應到角色，每個角色對應多個業務活動。需求人員在確認業務活動時一定要保證活動的粒度，一個業務活動一定是由一個角色完成且每個業務活動都是有價值的活動。
比如項目輸入項目名稱是一個執行步驟，這個動作沒有價值，項目經理查詢項目信息就是一個業務活動。
在需求描述時針對線下活動或新增活動應該應標識區分。
（3）業務活動間關系及數據確認：
確定所有業務活動的前後置關系，並明確流程間的傳遞的數據實體。
（4）流程整體瓶頸分析：
一般若某個角色業務活動工作量較大，或流程涉及高級領導，一般都會造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優化建議。
3.針對統計查詢類需求及介面類需求，按照上述業務活動確定原則分析、確定角色，並明確每個角色所執行的業務活動即可。
三、數據實體分析
針對流程類需求需要分析各業務活動傳遞的數據實體，統計分析類需求需要分析統計查詢條件和查詢展現兩類數據實體、介面類需求需要分析介面傳遞數據實體，具體分析包含如下內容：
1.明確數據實體：
確認需要分析的所有數據實體，明確哪些為系統原有實體、哪些為新增實體、哪些為改造實體。
2.明確所有數據實體間關系：
實體間關系包含（1對1、1對多、多對多），另外需要分析數據實體變更是否需要保留版本，實體刪除（邏輯刪除、物理刪除）是否影響其它數據實體。
3.明確數據實體欄位：
針對新增數據或改造數據實體需要明確新增欄位的名稱、欄位類型、是否必填、欄位取值方式（人工輸入、系統自動繼承自其它數據實體、系統自動計算需要明確計算公式）。
4.數據許可權分析：
需要分析不同角色在數據許可權方面的差異，若涉及縱向多級用戶，要說明對於集團/省/地市用戶的數據隔離。
四、角色及使用場景分析
一般來說每個業務活動是對用戶使用場景的抽象，每個業務活動可能包含多個場景，分析使用場景時應按照業務活動為主線逐個進行分析，每個業務活動分析時應包含如下內容：
1.明確活動執行角色。
2.明確活動執行的前置條件和後置條件。
3.明確不同場景：
一個業務活動可能包含正常的使用場景、備選使用場景和異常使用場景；
4.明確每個場景的執行步驟：
描述執行步驟時應使用簡單的語法，主語明確語義易於理解，每個步驟不應該在任何一方（執行角色、系統）停留兩部以上，重點描述如何交互。
5.業務規則和約束：
明確在每個業務活動下應遵循的業務規則和約束，這里一般是與業務流程相關的行為規則（比如項目周期時長超過90天必須提交二級領導審批），或與數據實體相關的數據規則（需求交接單拒收時候必須填寫拒收原因，且拒收原因不能超過500字）。
五、系統功能分析
❺ 需求分析有哪三種方法2，什麼是面向數據結構方法
它首先用結構化分析（SA）對軟體進行需求分析，然後用結構化設計（SD）方法進行總體設計，最後是結構化編程（SP）。它給出了兩類典型的軟體結構（變換型和事務型）使軟體開發的成功率大大提高。
三種基本的結構形式就是順序、選擇和重復。三種數據結構可以進行組合，形成復雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業應用中的文件表格處理。該方法也可與其它方法結合，用於模塊的詳細設計。
❻ 需求分析有哪些方法
三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。
面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人員的要求非常高。
❼ 軟體工程中常用的需求分析的方法有哪些
一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。
這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。
過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。
1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。
如果不能幫助用戶，那麼這個需求就可能是偽需求。
以下面的案例說明：
背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。
需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。
分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。
因此，該需求是個偽需求，應該被過濾掉。
2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。
因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。
如果不屬於該系統范疇，那麼直接說服需求方更換方案。以
下面的案例說明：
背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。
需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。
分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。
所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。
之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；
其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。
結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。
否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。
二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。
但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：
先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。
每個需求點再當做一個子需求進行調研，最後再聚合在一起。
以下面的案例說明：
背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。
需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。
該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：
自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。
這里不一一展開。
2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：
由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。
然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。
三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。
比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。
最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：
背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。
需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。
分析：需求是很明白的，也有它的意義，但有風險。
因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。
因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。
於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。
測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。
四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。
舉例說明：
背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。
需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。
分析：
第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……
第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……
通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。
羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。