需求調研的評估方法問題(需求分析有哪幾個步驟)
1.需求分析有哪幾個步驟
一、需求獲取階段
在需求獲取階段，需要做好收集和管理兩件事。
這些需求既有產(chǎn)品經(jīng)理主動挖掘的，也有從用戶、運營、業(yè)務方、領導等渠道被動獲取的，無論哪個渠道來的需求，都需要有一個正式的地方進行管理，也就是我們通常所說的需求池。
不過，對于多方關注的重點需求，通過需求池來向各方同步就不太合適了：
一是因為需求池內容太多、太雜，向業(yè)務方、領導匯報的時候會有很多干擾信息，難以快速抓住重點；
二是因為需求池里面可能有些需求不適合完全公開。
這時我們就需要使用《事項跟蹤表》來單獨跟進，形式上用Excel、PPT都可以。
而放在《事項跟蹤表》里的需求，也要在需求池里記錄下來，即需求池是做全量需求管理的，《事項跟蹤表》是做重點需求跟進、匯報的。
二、需求分析階段
1. 分析內容
需求分析主要從需求要素、定位、分解、優(yōu)先級四個方面進行。
1）需求要素分析
需求要素分析是從需求本身出發(fā)，不考慮其他因素。
這些要素包括：內容、用戶/角色、頻次、價值、場景-動機、強度六個方面，這些要素的含義大家應該都比較清楚了，這里說一下分析各個要素的目的是什么：
分析需求內容，是為了弄清楚需求是什么；
分析需求用戶/角色，是為了弄清楚需求為誰服務；
分析需求頻次、強度，是為了弄清楚需求對用戶的重要性、緊迫程度；
分析需求場景-動機，是為了弄清楚需求真?zhèn)?、用戶目的，更深入的理解需求?/p>
分析需求價值，是為了弄清楚需求值不值得做。
2）定位分析
需求的定位分析是分析需求對產(chǎn)品當前階段目標的意義。
分析需求的定位，有以下兩個目的：
一是作為優(yōu)先級排期的判斷條件之一，如果需求與產(chǎn)品當前階段的目標密切相關，則需要作為高優(yōu)先級上線；
二是為了框定需求范圍。每個需求的實現(xiàn)程度都有深有淺，可以很簡單，也可以很復雜，了解了需求之于產(chǎn)品的定位，就能判斷需求要做到什么程度。如果一個需求對產(chǎn)品很重要，那就需要做得很豐富，如果只是輔助需求，則需要適當輕量。
3）需求分解
原始需求的顆粒度往往較粗，不利于后續(xù)的分析、設計、開發(fā)等工作，所以我們需要對這些顆粒度較粗的原始需求進行分解，分解為一個個完整、獨立、可實現(xiàn)的子需求。
4）優(yōu)先級分析
優(yōu)先級分析是以拆解后的子需求為單位進行的，根據(jù)各類優(yōu)先級的判斷方法、原則，初步評估各個子需求的上線順序及時間。
2. 常見問題
需求分析應該是大家從入行那天就知道要做的事，但大多數(shù)同學在做需求分析時會犯以下三個比較常見的錯誤。
1）缺乏系統(tǒng)性
這是在分析中最常見的問題，即很多同學在分析需求時沒有系統(tǒng)性的框架，導致很多方面沒有分析到、考慮到，從而對需求認識不全面。
2）缺乏深度
對需求某些要素認識比較淺，不夠細致深入，例如在分析需求的用戶時，沒有對用戶分層、切片，對各個分層的用戶也缺乏足夠的了解，導致對用戶只有一個籠統(tǒng)、模糊的認識，最后自然無法深入進去。
不過分析是否有深度的定義其實很難把握，也缺乏明確的判斷標準，需要隨著分析者思維能力的提升、信息量的提升來加強。
2.需求調研的幾種錯誤觀點
1）快速原型法，可以替代需求 軟件工程項目中，經(jīng)常會遇到這樣一種尷尬的局面，我們調研完需求，做完設計，代碼也編寫的差不多了，這時請客戶過來一看，客戶卻驚奇地發(fā)現(xiàn)這根本不是他們想要的東西。
為了讓客戶更早更快的對將要建成的軟件系統(tǒng)，有直觀和感性的認識，我們便建立一個系統(tǒng)原型，用于給客戶做演示?？蛻粼谖覀冄菔竞椭v解的時候，馬上就可以發(fā)現(xiàn)問題，而我們甚至可以現(xiàn)場修改原型，直到客戶滿意為止。
從理論上說，快速原型法確實幾乎沒有任何問題。但實際情況并非如此。
第一點，也是最重要的一點，快速原型法無法解決需求主線的問題。關于需求主線前文已經(jīng)講得很多，而調研需求主線的禁忌中，就特別提到不可以上來就做原型。
說直接點，你是做了某個模塊或功能的原型，而且這部分原型也得到了客戶的認可，但項目中真的需要這個模塊或功能嗎？另外更可怕的一點，當你宣告整個項目的原型已經(jīng)制作完畢，并且全面得到了用戶的認可，而那些必須有的需求主線，真的全部包括進來了嗎？ 第二點，快速原型法背后還隱含了一個假設，客戶就有極高的計算機素養(yǎng)，非常清楚自己需要什么樣的系統(tǒng)，他的認可就標志著原型已經(jīng)合理且完善。但現(xiàn)實中，絕大多數(shù)情況下，這種假設是不成立的。
我們知道，客戶方的角色實際至少可以分為兩個部分：項目發(fā)起人與項目負責人。發(fā)起人多數(shù)是職能部門，而負責人是IT部門。
你能指望職能部門的最終使用者，能有多大的概率說清楚自己到底想要什么。 第三點，再好的原型，它的層次感也要弱于建筑行業(yè)的沙盤或效果圖，這使得原型演示不可能完美的表達軟件系統(tǒng)建成后的效果。
以大樓建設為例。我們可以用幻燈片或沙盤的方式，首先展示建筑的外部環(huán)境、外觀設計。
然后再進入到某一層的樓層布局設計圖，在進入到該樓層某個房間的布局設計圖。這些甚至可以用3D的方法演示出來。
再配合講解，就能夠使客戶非常清晰全面的了解到整個設計。 我們知道，一個大型軟件系統(tǒng)，可能包含幾十個大模塊、上百個小模塊，成百上千的界面，而涉及到按鈕、功能鍵、數(shù)據(jù)輸入和顯示等細節(jié)甚至多達數(shù)萬個。
這樣龐大的軟件系統(tǒng)，要去演示它的軟件原型，我們就只能在屏幕上，演示一個又一個的界面，根本無法遵行從整體到局部再到細節(jié)這樣一個流程來展示。 這樣的一種情況，相當于在建筑行業(yè)中，客戶要求你蓋一棟商業(yè)、辦公綜合性大樓，而你給客戶演示的幻燈片，卻只是一大堆的房間、廚房、衛(wèi)生間、甚至于類似排氣扇、開關之類非常細枝末節(jié)的東西。
又如何讓客戶提意見，客戶又從何提起？只見樹木，不見森林，說的就是這個意思。 在快速原型法相關知識普及率如此之高的情況下，軟件項目失敗率依然居高不下，其最根本原因，就在于此。
在筆者看來，只有當需求分析已經(jīng)細化到具體某個界面的時候，快速原型法的好處才能真正體現(xiàn)出來。而在此之前的僅僅只能用于確定界面布局，以及界面風格。
否則將不會對項目有多少幫助。 2）迭代次數(shù)越多，越能貼近用戶需求 曾經(jīng)有一次到一個朋友公司去談事情，到朋友的辦公室的時候，恰好有一個項目經(jīng)理正在匯報項目進度。
朋友知道我也是做軟件工程管理的，就讓項目經(jīng)理繼續(xù)匯報。當時項目經(jīng)理說的有一件事情記憶特別深刻：“現(xiàn)在的原型和設計已經(jīng)進行到第5次迭代……”。
似乎迭代次數(shù)越多，就代表項目越能取得成功。 完成一個軟件項目，特別是大型的軟件項目，總是需要很長的時間，為了避免在項目已經(jīng)進行到尾聲的時候，才發(fā)現(xiàn)原來和用戶的要求有很大的差別，于是產(chǎn)生了迭代法。
迭代的方式如下，假如這個項目要求6個月交貨，我在第一個月就會拿出一個產(chǎn)品來，當然，這樣會很不完善，會有很多功能還沒有添加進去，bug很多，還不穩(wěn)定，但客戶看了以后，會提出更詳細的修改意見，這樣就知道自己距離客戶的需求有多遠。 回家以后，再花一個月，在上個月所作的需求分析、框架設計、代碼、測試等等的基礎上，進一步改進，又拿出一個更完善的產(chǎn)品來，給客戶看，讓他們提意見。
就這樣，我的產(chǎn)品在功能上、質量上都能夠逐漸逼近客戶的要求，不會出現(xiàn)我花了大量心血后，直到最后發(fā)布之時才發(fā)現(xiàn)根本不是客戶要的東西的情況。 對比快速原型法和迭代法，就可以發(fā)現(xiàn)它們所需要解決的核心問題是一樣的，那就是如何應對和適用客戶需求在項目實施過程中的變化。
實際上快速原型法中就包含了迭代的意思。它的目標是爭取在設計、編碼開始前，將客戶的需求穩(wěn)定下來。
而迭代法則走得更遠，它發(fā)現(xiàn)在客戶需求變化幾乎貫穿了軟件工程項目的整個過程，而不僅僅是在需求調研過程之中。于是迭代法就包含設計迭代、代碼迭代、測試迭代。
但迭代法的同快速原型法一樣，它重點仍然是著眼于如何應付需求的變化上，只是把變化擴展為整個開發(fā)過程。也因此，迭代法仍然無法擺脫上述快速原型法中，講到的只見樹木不見森林缺陷。
3）敏捷開發(fā)和極限編程，可以應付需求變動 敏捷開發(fā)這個詞很好很形象。它使我仿佛看見一幅場景：兩個人正在做游戲，一個人不停的丟出雞蛋，而另一個人則敏捷地接下所有的雞蛋，避免它掉在地。
3.市場需求預測有哪三種方法,其優(yōu)缺點各是什么
1.定性預測方法。主要是通過社會調查，采用少量的數(shù)據(jù)和直觀材料，結合人們的經(jīng)驗加以綜合分析，作出判斷和預測。它是以市場調研為基礎的經(jīng)驗判斷法。具體方法主要有：購買者意向調查法 、銷售人員意見綜合法、專家意見法、市場試銷法。
2.定量預測方法。是依據(jù)市場調查所得的比較完備的統(tǒng)計資料，運用數(shù)學特別是數(shù)理統(tǒng)計方法，建立數(shù)學模型，用以預測經(jīng)濟現(xiàn)象未來數(shù)量表現(xiàn)的方法的總稱。運用定量預測方法，一般需具有大量的統(tǒng)計資料和先進的計算手段。定量預測方法大致可分為兩大類，即時間序列預測方法和因果分析預測方法。時間序列預測方法主要有：水平型發(fā)展趨勢、線性變化趨勢、二次曲線趨勢、對數(shù)直線趨勢、修正指數(shù)曲線趨勢、龔佩子曲線趨勢。因果分析法的主要工具是回歸分析技術，因此又稱其為回歸分析預測方法。運用回歸方程進行分析預測的方法主要有 三種：一元回歸預測、多元回歸預測、自回歸預測。
4.社區(qū)需求評估包括哪些
1、社區(qū)需求評估包括兩大方面：
(1)社區(qū)共同性問題（社區(qū)需求與問題評估）；
(2)社區(qū)群體性問題（服務對象群需求與問題評估及服務對象需求與問題評估）。
2、社區(qū)需求評估的目的：
(1)確認社區(qū)的需要、關注點與問題；
(2)建立社區(qū)服務的發(fā)展目標；
(3)幫助社區(qū)采取必要的行動；
(4)判斷社區(qū)的需求是否發(fā)生了變化；
(5)收集社區(qū)的希望、夢想和愿望。
擴展資料：
社區(qū)擁有的三大類資源：
1、人力資源：社區(qū)中所有的個人的體力、技術、智慧、助人意愿以及人際關系等。（重視的對象：社區(qū)領袖、專家、學者、領導人、社工、志愿者）。
2、物力資源：用于社區(qū)服務的場地、設備。
3、財力資源：社區(qū)服務所需的經(jīng)費，來源——政府、社會捐助、服務收費。
參考資料來源：百度百科 - 需求評估
5.軟件工程中常用的需求分析的方法有哪些
一、過濾需求的方法做后端系統(tǒng)，要學會的第一個技能就是砍需求。
也就是過濾需求。這不是一個貶義詞，反而是體現(xiàn)后端產(chǎn)品價值判斷的基礎。
過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。1. 用戶場景模擬法后端產(chǎn)品的出發(fā)點就是幫助業(yè)務用戶，因此在調研需求的時候要模擬業(yè)務的場景，分析業(yè)務用戶提到的需求是否能解決他的問題。
如果不能幫助用戶，那么這個需求就可能是偽需求。以下面的案例說明：背景：“貨到付款”類型的訂單會因為缺貨而無法發(fā)出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。
需求：由于這種訂單的數(shù)量還是蠻多的，逐個取消太費時間，因此業(yè)務用戶要求在“缺貨訂單”列表頁增加“批量取消訂單”按鈕。分析：調研到業(yè)務操作場景，是先找到該類缺貨訂單，然后和顧客溝通，顧客同意刪除，才進行刪除。
也就是逐個溝通確認，再逐個取消訂單的，所以“批量取消訂單”無法被有效使用。因此，該需求是個偽需求，應該被過濾掉。
2. 功能歸屬分析專門的系統(tǒng)做專職功能，有助于合理的產(chǎn)品體系建設。因此需求調研的時候，可以通過系統(tǒng)的定位，判斷需求是否應該在該系統(tǒng)完成。
如果不屬于該系統(tǒng)范疇，那么直接說服需求方更換方案。以下面的案例說明：背景：CRM系統(tǒng)（顧客關系管理系統(tǒng)）有一個顧客標簽生成功能，就是根據(jù)顧客的消費行為數(shù)據(jù)，自動對應關聯(lián)上標簽，如優(yōu)質顧客、高潛力顧客、欺詐顧客等。
需求：業(yè)務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統(tǒng)下使用。分析：調研到翻譯之后的標簽不是在CRM系統(tǒng)使用的，而是給到SMS（客服系統(tǒng)）使用的。
所以應該由SMS根據(jù)CMS提供的基礎標簽數(shù)據(jù)，自己做二次的衍生。之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統(tǒng)提出類似的需求；其次，CRM系統(tǒng)已經(jīng)完成了“接力賽”的第一棒，創(chuàng)造了基礎數(shù)據(jù)，那么其他系統(tǒng)要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統(tǒng)。
結論：案例的需求本身是真需求，并且實現(xiàn)上也沒難度，但是該功能的定位超出了本系統(tǒng)范疇，專門系統(tǒng)做專職功能，化衍生需求應該在下游執(zhí)行。否則，耦合性過高只會增加系統(tǒng)的復雜程度，難以維護和擴展。
二、拆分和聚合的方法1. 拆分需求法業(yè)務用戶提出一個需求，很可能只是短短的一段話。但是不要高興太早，可能這一句話暗含了很多線索，因此要善于拆分：先找他要解決的核心問題，再圍繞核心點，理清前、后、左、右、上、下的旁系需求點。
每個需求點再當做一個子需求進行調研，最后再聚合在一起。以下面的案例說明：背景：訂單業(yè)務的類型很多，訂單退貨之后需要創(chuàng)建售后單據(jù)，但是因為數(shù)量大，所以花費很多人力，且手動創(chuàng)建有出錯的風險。
需求：業(yè)務提出的需求是“增加退貨訂單自動創(chuàng)建售后單的功能”，這是個一句話需求。該一句話需求，其實包含了多種具體的訂單類型和場景，那么我們就要拆分調研，拆分的維度比如：自營訂單、第三方訂單、貨到付款訂單、先款后貨訂單、部分退貨訂單、完全退貨訂單、服裝事業(yè)部訂單、電子事業(yè)部訂單等，其中每一個維度就相當于一個小需求。
這里不一一展開。2. 聚合需求法拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯(lián)的小需求的共性，然后統(tǒng)籌成一個大需求去完成。
例如：由于業(yè)務用戶分散在不同的部門，各自為政，于是張三、李四可能都對一個業(yè)務流程有相同的需求，或者對同一個功能有相同的優(yōu)化期望，結果倆人分別提了需求過來。那么產(chǎn)品經(jīng)理就要找到二者背后的相關性和交叉區(qū)。
然后統(tǒng)籌規(guī)劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。三、利用輔助功能調研需求調研產(chǎn)品現(xiàn)有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。
比如業(yè)務用戶需要更新一個功能，為了避免更新出錯或遺漏，產(chǎn)品經(jīng)理需要知道修改前和修改后是否會能正常運行。最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態(tài)變化、數(shù)據(jù)流向等。
看看下面的例子：背景：從銷售網(wǎng)站獲取到OMS系統(tǒng)（訂單管理系統(tǒng)）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網(wǎng)站修改郵箱，而此時已經(jīng)獲取到OMS的歷史訂單中的郵箱是不變的。
需求：顧客若在銷售網(wǎng)站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。分析：需求是很明白的，也有它的意義，但有風險。
因為我們知道訂單信息貫穿于整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發(fā)貨等，而這些環(huán)節(jié)跳轉的觸發(fā)條件可能就是某個信息更新（這里面就可能包括有郵箱更新）。因此，更新郵箱是否會影響流程中的某些環(huán)節(jié)，一時間很難準確知道。
于是，我們可以采用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環(huán)節(jié)郵箱變更的影響，然后收集起來分析對策。測試法就像是探雷一樣，主要用來解決未知風險點。
這個方式的重點是記錄和分析操作前狀態(tài)、操作位。
6.市場調查常用的方法有哪些,各自有什么優(yōu)缺點
市場研究分為定量訪問和定性訪問。
定量訪問指：大量訪問普通的消費者，從而分析普通消費者的情況。一般最少80樣本以上，最多可達數(shù)萬甚至十幾萬樣本。
定性訪問指：訪問特定的消費者，以得出特殊人群的共性。根據(jù)不同的形式，樣本量在4個樣本到幾百樣本不等。
定量研究的方法有：
電訪訪問（CATI）：優(yōu)點是可同時訪問不同城市、地區(qū)的消費者，完成樣本速度快、費用低，質量可控性強。缺點是無法準確找到特殊條件的消費者，無法執(zhí)行滲透率低的項目。無法出示圖片和廣告。
街訪：優(yōu)點是可通過選取街訪點，有針對性的訪問不同階層的消費者。且面對面的訪問更便于出示圖片和廣告。缺點是被訪者的隨機性不夠強，受街訪點影響，被訪者有一定的傾向性。
入戶：優(yōu)點是可以準確的抽取不同的區(qū)、街道、地址，使得樣本分布均勻?？闪糁卯a(chǎn)品，使用 后再作回訪。缺點是質量可控性相對較弱。
在線訪問（online）：優(yōu)點是可由被訪者在方便的時間自行上線填寫，可出示圖片和廣告，減少訪問員參加的環(huán)節(jié)，避免因訪問員理解或聽力問題造成的誤差。缺點是難以確定被訪者是否認真填寫（一般通過強制訪問時長來限制），難以區(qū)分填寫過程中是否換人。
定性訪問有：
座談會：優(yōu)點是客戶可在現(xiàn)場觀看，并隨時補充需要了解的問題。缺點是一般座談會訪問8人（最少4人，最多12人），如其中個別被訪者的預約質量有問題（如兩兩相識或條件造假），則整個座談會的訪問結果都會有偏差。
深訪：優(yōu)點是能深入了解特定消費者的深層需求和意見。缺點是，對訪問者本身有較高的要求，深訪訪問的要求和定量訪問截然不同，如訪問員深訪經(jīng)驗不足，不能隨機應變的挖掘被訪者的深層想法，則所能得到的信息有限。
有任何問題請追問，希望滿意，~
7.需求分析的步驟有哪些
一、需求識別 需求人員在此步驟應該分析需求類別、需求復雜度和需求價值用來確定需求實施的優(yōu)先級。
1.需求類別確認：需求類別包含流程類需求、統(tǒng)計分析類需求、接口類需求，一個需求可能為某一類型需求，也可能包含多類需求。確認需求類別后應對每類需求的數(shù)量進行初步分析（比如流程類需求包含幾個流程、統(tǒng)計分析類需求包含幾個報表、接口類需求包含幾個接口）。
2.需求復雜度分析：一般需求受理工作量在1-5人天的需求復雜度低，工作量在5-15人天的需求復雜度中，工作量在15人天以上需求復雜度高。（工作量表示需求受理全過程需求人員需要付出的工作量）。
3.價值分析：需求人員收到需求后應根據(jù)收集需求內容初步分析需求痛點/目標、需求復雜度、業(yè)務重要程度確定需求價值，需求價值分析 二、業(yè)務流程/統(tǒng)計查詢/接口分析 針對流程類需求必須進行業(yè)務流程分析，統(tǒng)計查詢和接口類需求可不進行詳細的流程分析。1.業(yè)務流程分為部門級、組織級和崗位級 部門級流程關注脈絡需要分析涉及哪些具體崗位、執(zhí)行活動、每個活動之間的關聯(lián)關系，它是需求分析的主線條，也是流程分析的主要產(chǎn)物。
組織級流程關注宏觀一般不會直接繪制，是對部門級流程的概括和抽象。崗位級流程關注每個業(yè)務活動的執(zhí)行步驟屬需求細節(jié)范疇，在流程分析階段不要過度進入細節(jié)。
2.需求識別階段確認的流程均為部門級流程 需求人員在進行流程分析應遵循如下方法：（1）業(yè)務流程確認：一個流程為一個業(yè)務事件，一般是外部角色發(fā)起或系統(tǒng)內部主動發(fā)起（比如時間事件或狀態(tài)事件），發(fā)起后會觸發(fā)一系列業(yè)務活動。（2）角色及業(yè)務活動確認：流程圖中的每個泳道都必須對應到角色，每個角色對應多個業(yè)務活動。
需求人員在確認業(yè)務活動時一定要保證活動的粒度，一個業(yè)務活動一定是由一個角色完成且每個業(yè)務活動都是有價值的活動。比如項目輸入項目名稱是一個執(zhí)行步驟，這個動作沒有價值，項目經(jīng)理查詢項目信息就是一個業(yè)務活動。
在需求描述時針對線下活動或新增活動應該應標識區(qū)分。（3）業(yè)務活動間關系及數(shù)據(jù)確認：確定所有業(yè)務活動的前后置關系，并明確流程間的傳遞的數(shù)據(jù)實體。
（4）流程整體瓶頸分析：一般若某個角色業(yè)務活動工作量較大，或流程涉及高級領導，一般都會造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優(yōu)化建議。3.針對統(tǒng)計查詢類需求及接口類需求，按照上述業(yè)務活動確定原則分析、確定角色，并明確每個角色所執(zhí)行的業(yè)務活動即可。
三、數(shù)據(jù)實體分析 針對流程類需求需要分析各業(yè)務活動傳遞的數(shù)據(jù)實體，統(tǒng)計分析類需求需要分析統(tǒng)計查詢條件和查詢展現(xiàn)兩類數(shù)據(jù)實體、接口類需求需要分析接口傳遞數(shù)據(jù)實體，具體分析包含如下內容：1.明確數(shù)據(jù)實體：確認需要分析的所有數(shù)據(jù)實體，明確哪些為系統(tǒng)原有實體、哪些為新增實體、哪些為改造實體。2.明確所有數(shù)據(jù)實體間關系：實體間關系包含（1對1、1對多、多對多），另外需要分析數(shù)據(jù)實體變更是否需要保留版本，實體刪除（邏輯刪除、物理刪除）是否影響其它數(shù)據(jù)實體。
3.明確數(shù)據(jù)實體字段：針對新增數(shù)據(jù)或改造數(shù)據(jù)實體需要明確新增字段的名稱、字段類型、是否必填、字段取值方式（人工輸入、系統(tǒng)自動繼承自其它數(shù)據(jù)實體、系統(tǒng)自動計算需要明確計算公式）。4.數(shù)據(jù)權限分析：需要分析不同角色在數(shù)據(jù)權限方面的差異，若涉及縱向多級用戶，要說明對于集團/省/地市用戶的數(shù)據(jù)隔離。
四、角色及使用場景分析 一般來說每個業(yè)務活動是對用戶使用場景的抽象，每個業(yè)務活動可能包含多個場景，分析使用場景時應按照業(yè)務活動為主線逐個進行分析，每個業(yè)務活動分析時應包含如下內容：1.明確活動執(zhí)行角色。2.明確活動執(zhí)行的前置條件和后置條件。
3.明確不同場景：一個業(yè)務活動可能包含正常的使用場景、備選使用場景和異常使用場景；4.明確每個場景的執(zhí)行步驟：描述執(zhí)行步驟時應使用簡單的語法，主語明確語義易于理解，每個步驟不應該在任何一方（執(zhí)行角色、系統(tǒng)）停留兩部以上，重點描述如何交互。5.業(yè)務規(guī)則和約束：明確在每個業(yè)務活動下應遵循的業(yè)務規(guī)則和約束，這里一般是與業(yè)務流程相關的行為規(guī)則（比如項目周期時長超過90天必須提交二級領導審批），或與數(shù)據(jù)實體相關的數(shù)據(jù)規(guī)則（需求交接單拒收時候必須填寫拒收原因，且拒收原因不能超過500字）。
五、系統(tǒng)功能分析。
