軟件進行需求分析的方法(軟件需求的分析方法)
1.軟件需求的分析方法
軟件需求分析方法大體分為如下四類：結構化方法、面向對象方法、面向控制方法和面向數(shù)據(jù)方法。限于篇幅，將主要從結構化方法和面向對象方法以及RUP三個方面進行簡要的探討。 面向對象（Object Oriented, OO）的方法把分析建立在系統(tǒng)對象以及對象間交互的基礎之上，使得我們能以3個最基本的方法框架——對象及其屬性、分類結構和集合結構來定義和溝通需求。面向對象的問題分析模型從3個側面進行描述，即對象模型（對象的靜態(tài)結構）、動態(tài)模型（對象相互作用的順序）和功能模型（數(shù)據(jù)變換及功能依存關系）。需求工程的抽象原則、層次原則和分割原則同樣適用于面向對象方法，即對象抽象與功能抽象原則是一樣的，也是從高級到低級、從邏輯到物理，逐級細分.每一級抽象都重復對象建模（對象識別）一動態(tài)建模（事件識別）一功能建模（操作識別）的過程，直到每一個對象實例在物理（程序編碼）上全部實現(xiàn)為止。
面向對象需求分析（OORA）利用一些基本概念來建立相應模型，以表達目標系統(tǒng)的不同側面。盡管不同的方法所采用的具體模型不盡相同，但都無外乎用如下五個基本模型來描述軟件需求：
整體—部分模型：該模型描述對象（類）是如何由簡單的對象（類）構成的。將一個復雜對象（類）描述成一個由交互作用的若干對象（類）構成的結構的能力是OO途徑的突出優(yōu)點。該模型亦稱聚合模型。
分類模型：分類模型描述類之間的繼承關系。與聚合關系不同，它說明的是一個類可以繼承另一個或另一些類的成分，以實現(xiàn)類中成分的復用。
類—對象模型：分析過程必須描述屬于每個類的對象所具有的行為，這種行為描述的詳細程度可以根據(jù)具體情況而定。既可以只說明行為的輸入、輸出和功能，也可以采用比較形式的途徑來精確地描述其輸入、輸出及其相應的類型甚至使用偽碼或小說明的形式來詳細刻畫。
對象交互模型：一個面向對象的系統(tǒng)模型必須描述其中對象的交互方法。如前所述，對象交互是通過消息傳遞來實現(xiàn)的。事實人對象交互也可看作是對象行為之間的引用關系。因此，對象交互模型就要刻畫對象之間的消息流。對應于不同的詳細程度，有不同的消息流描述分析，分析人員應根據(jù)具體館況而選擇。一般地，一個詳細的對象交互模型能夠說明對象之間的消息及其流向，并且同時說明該消息將激活的對象及行為。一個不太詳細的對象交互模型可以只說明對象之間有消息，并指明其流向即可。還有一種狀況就是介于此兩者之間。
狀態(tài)模型：在狀態(tài)模型中，把一個對象看作是一個有限狀態(tài)機，由一個狀態(tài)到另一狀態(tài)的轉變稱作狀態(tài)轉換。狀態(tài)模型將對象的行為描述成其不同狀態(tài)之間的通路。它也可以刻畫動態(tài)系統(tǒng)中對象的創(chuàng)建和廢除，并稱由對象的創(chuàng)建到對象的廢除狀態(tài)之間的退路為對象的生存期。
狀態(tài)模型既可以用狀態(tài)轉換因的圖形化手段，又可用決策表或稱決策矩陣的形式來表。 RUP(Rational Unified Process)是Rational公司開發(fā)和維護的過程產品。RUP是工程化的軟件開發(fā)過程，它提供了在開發(fā)機構中分派任務和責任的紀律化方法。RUP不僅僅是一個簡單的過程，而是一個通用的過程框架，可用于各種不同類型的軟件系統(tǒng)、各種不同的應用領域、各種不同類型的組織、各種不同的功能級別以及各種不同的項目規(guī)模。RUP的突出特點可以由以下三個關鍵詞來體現(xiàn)——用例驅動、以構架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來指導迭代過程中的工作，而用例則確定了目標井驅動每次迭代的工作。
進行需求分析的基礎是要獲得用戶的需要，為了完成這一工作，必須建立業(yè)務模型，通過描述業(yè)務規(guī)則、業(yè)務邏輯，明確業(yè)務過程并對其進行規(guī)范、優(yōu)化。對于一個系統(tǒng)，在建立業(yè)務模型時，應從3個方面來描述其特性：功能、行為、數(shù)據(jù)，對應于這些特性。 基于上述分析可知，結構化分析方法與面向對象分析方法的區(qū)別主要體現(xiàn)在兩個方面：
* 將系統(tǒng)分解成于系統(tǒng)的方式不同。前者將系統(tǒng)描述成一組交互作用的處理，后者則描述成一組交互作用的對象。
* 子系統(tǒng)之間的交互關系的描述方式不一樣。前者加工之間的交互是通過不太精確的數(shù)據(jù)流來表示的，而后者對象之間通過消息傳遞交互關系。
因此，面向對象軟件需求分析的結果能更好地刻畫現(xiàn)實世界，處理復雜問題，對象比過程更具有穩(wěn)定性，便于維護與復用。
2.軟件工程中常用的需求分析的方法有哪些
一、過濾需求的方法做后端系統(tǒng)，要學會的第一個技能就是砍需求。
也就是過濾需求。這不是一個貶義詞，反而是體現(xiàn)后端產品價值判斷的基礎。
過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。1. 用戶場景模擬法后端產品的出發(fā)點就是幫助業(yè)務用戶，因此在調研需求的時候要模擬業(yè)務的場景，分析業(yè)務用戶提到的需求是否能解決他的問題。
如果不能幫助用戶，那么這個需求就可能是偽需求。以下面的案例說明：背景：“貨到付款”類型的訂單會因為缺貨而無法發(fā)出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。
需求：由于這種訂單的數(shù)量還是蠻多的，逐個取消太費時間，因此業(yè)務用戶要求在“缺貨訂單”列表頁增加“批量取消訂單”按鈕。分析：調研到業(yè)務操作場景，是先找到該類缺貨訂單，然后和顧客溝通，顧客同意刪除，才進行刪除。
也就是逐個溝通確認，再逐個取消訂單的，所以“批量取消訂單”無法被有效使用。因此，該需求是個偽需求，應該被過濾掉。
2. 功能歸屬分析專門的系統(tǒng)做專職功能，有助于合理的產品體系建設。因此需求調研的時候，可以通過系統(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)化期望，結果倆人分別提了需求過來。那么產品經(jīng)理就要找到二者背后的相關性和交叉區(qū)。
然后統(tǒng)籌規(guī)劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。三、利用輔助功能調研需求調研產品現(xiàn)有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。
比如業(yè)務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經(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)、操作位。
3.需求分析有哪些方法
三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。
結構化的分析方法是傳統(tǒng)的分析法，它的好處是在需求階段可以不需要精確地定義系統(tǒng)，只需要根據(jù)業(yè)務框架確定系統(tǒng)的功能范圍，以及每個功能的處理邏輯和業(yè)務規(guī)則，功能需求規(guī)格書等。因為不需要精確描述，因此描述系統(tǒng)的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來描述系統(tǒng)。在系統(tǒng)開發(fā)以前，一般還可以采用更為直觀的原型系統(tǒng)方式和最終用戶進行交流和確認，因此對業(yè)務需求的要求會低一些，業(yè)務需求階段的周期相對容易控制；通過業(yè)務全景圖，最終用戶也能了解系統(tǒng)的功能；通過功能活動圖和業(yè)務規(guī)則的描述，也可以相對精確地描述業(yè)務系統(tǒng)；因為沒有嚴格的標記語言，可以采用適當?shù)钠枋鲞m當?shù)南到y(tǒng)。當然，這種方法的缺點也是明顯的，分析人員和業(yè)務人員之間可能缺乏共同語言，機器不能識別業(yè)務需求書，在設計階段還需要繼續(xù)和用戶確認一部分功能。
面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統(tǒng)，采用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發(fā)現(xiàn)很多問題，避免在開發(fā)的過程中出現(xiàn)需求的反復，而且在系統(tǒng)設計和開發(fā)階段不需要最終用戶參與。在實施上，一般可以采用場景、業(yè)務功能等方式來描述，比較適合于業(yè)務流程環(huán)節(jié)多的系統(tǒng)，或者軟件產品的開發(fā)。但是，我們也要看到，在現(xiàn)實中，絕大多數(shù)的應用系統(tǒng)都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業(yè)務系統(tǒng)應該是什么樣，或者采用一種抽象的方式能夠確定最終的應用系統(tǒng)；其次，因為最終用戶不需要參與設計和開發(fā)階段的工作，所以雙方確定業(yè)務需求的過程也會比較長；同時，因為是精確描述，因此描述系統(tǒng)的語言是非常邏輯化的，一般通過某種方式可以使機器識別業(yè)務需求，采用這種方式寫的業(yè)務需求是非常格式化的，一方面描述一個系統(tǒng)需要的信息非常多，可能使需求說明的篇幅非常長，不便于理解和閱讀；另外由于通過抽象的方式來推演最終系統(tǒng)的運行方式，對業(yè)務人員的要求非常高。
4.軟件需求分析在軟件工程中的作用,有哪些軟件需求分析的方法
軟件工程中包含需求、設計、編碼和測試四個階段，其中需求工程是軟件工程第一個也是很重要的一個階段，需求分析是要決定“做什么，不做什么”。
在一個軟件項目中，軟件需求包括三個不同的層次-業(yè)務需求、用戶需求和功能需求-也包括非功能需求：業(yè)務需說明了提供給客戶和產品開發(fā)商的新系統(tǒng)的最初利益，反映了組織機構或客戶對系統(tǒng)、產品高層次的目標要求。
軟件開發(fā)，能否獲得成功，最重要的是需求分析的工作。因此，軟件需求分析能力和水平，對軟件項目至關重要。
一般的分析方法和步驟如下：
⑴首先調查組織機構情況 包括了解該組織的部門組成情況，各部門的職能等，為分析信息流程作準備。
⑵然后調查各部門的業(yè)務活動情況 包括了解各個部門輸入和使用什么數(shù)據(jù)，如何加工處理這些數(shù)據(jù)，輸出什么信息，輸出到什么部門，輸出結果的格式是什么。
⑶協(xié)助用戶明確對新系統(tǒng)的各種要求 包括信息要求、處理要求、完全性與完整性要求。
⑷確定新系統(tǒng)的邊界 確定哪些功能由計算機完成或將來準備讓計算機完成，哪些活動由人工完成。由計算機完成的功能就是新系統(tǒng)應該實現(xiàn)的功能。
常用的調查方法有：
⑴跟班作業(yè) 通過親身參加業(yè)務工作來了解業(yè)務活動的情況。這種方法可以比較準確地理解用戶的需求，但比較耗費時間。
⑵開調查會 通過與用戶座談來了解業(yè)務活動情況及用戶需求。座談時，參加者之間可以相互啟發(fā)。
⑶請專人介紹。
⑷詢問 對某些調查中的問題，可以找專人詢問。
⑸設計調查表請用戶填寫 如果調查表設計得合理，這種方法是很有效，也很易于為用戶接受的。
⑹查閱記錄 即查閱與原系統(tǒng)有關的數(shù)據(jù)記錄，包括原始單據(jù)、賬簿、報表等。 通過調查了解了用戶需求后，還需要進一步分析和表達用戶的需求。分析和表達用戶需求的方法主要包括自頂向下和自底向上兩類方法。
5.如何進行軟件需求分析
軟件需求的定義：（1）用戶解決問題或達到目標所需的條件或能力。
（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。（3）一種反映上面（1）或（2）所描述的條件或權能的文檔說明。
實通俗的講，“需求”就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現(xiàn)這些目標所需要的條件，它是一個程序或系統(tǒng)開發(fā)工作的說明，表現(xiàn)形式一般為文檔形式。需求工程的定義：需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發(fā)和需求管理兩個部分。
需求開發(fā)是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規(guī)格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反復的。
需求管理是軟件項目開發(fā)過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態(tài)跟蹤等工作。需求開發(fā)與管理的一些方法：（1）繪制關聯(lián)圖：繪制系統(tǒng)關聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。
（2）可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現(xiàn)相關風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。（4）系統(tǒng)原型：當用戶自身對有的需求不十分清楚時，我們可以建立一個系統(tǒng)原型，用戶通過評價原型更好地理解所要解決的問題。
（5）圖形分析模型：繪制圖形分析模型是編制軟件需求規(guī)格說明重要手段。
它們能幫助分析人員理清數(shù)據(jù)、業(yè)務模式、工作流程以及他們之間的關系，找出遺漏、冗余和不一致的需求。這樣的模型包括數(shù)據(jù)流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。
（6）數(shù)據(jù)字典：數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項，確?？蛻襞c開發(fā)小組是使用一致的定義和術語。
需求管理的方法主要包括以下一些方面：1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。
2）進行需求變更影響分析。評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關的任務并評估完成這些任務需要的工作量。
通過這些分析將有助于需求變更控制部門做出更好的決策。3）建立需求基準版本和需求控制版本文檔。
確定需求基準，這是項目各方對需求達成一致認識時刻的一個快照，之后的需求變更遵循變更控制過程即可。每個版本的需求規(guī)格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。
4）維護需求變更的歷史記錄。將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號等內容，及時通知到項目開發(fā)所涉及的人員。
為了盡量減少困惑、沖突、誤傳，應指定專人來負責更新需求。5）跟蹤每項需求的狀態(tài)。
可以把每一項需求的狀態(tài)屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在數(shù)據(jù)庫中，這樣可以在任何時候得到每個狀態(tài)類的需求數(shù)量。6）衡量需求穩(wěn)定性。
可以定期把需求數(shù)量和需求變更（添加、修改、刪除）數(shù)量進行比較。過多的需求變更"是一個報警信號"，意味著問題并未真正弄清楚。
4.需求分析評價標準 （1）清晰：目前大多數(shù)的需求分析采用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發(fā)人員需要對需求分析中采用的語言做某些限制。例如盡量采用主語+動作的簡單表達方式。
需求分析中的描述一定要簡單，千萬不要采用疑問句、修飾這些復雜的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。
需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業(yè)人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。（2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟件開發(fā)過程中，最糟糕的事情莫過于在軟件開發(fā)接近完成時發(fā)現(xiàn)遺漏了一項需求。
但實際情況是，需求的遺漏是常發(fā)生的事情，這不僅僅是開發(fā)人員的問題，更多發(fā)生在用戶那里。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最后的需求評審。
（3）一致：一致性是指用戶需求必須和業(yè)務需求一致，功能需求必須和用戶需求一致。在需求過程中，開發(fā)人員需要把一致性關系進行細化，比如用戶需求不能超出預前指定的范圍。
嚴格的遵守不同層次間的一致性關系，就可以保證最后開發(fā)出來的軟件系統(tǒng)不會偏離最初的實現(xiàn)目標。（4）可測試：一個項目的測試從什么時候開始呢？有人說是從編碼完成后開始，有人說是編碼的時候同時進行單元測試，編碼完成后進行系統(tǒng)測試，這些結論都不完全正確。
實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統(tǒng)的所有需求都是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統(tǒng)是成功的。
6.需求分析的步驟有哪些
一、需求識別 需求人員在此步驟應該分析需求類別、需求復雜度和需求價值用來確定需求實施的優(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)關系，它是需求分析的主線條，也是流程分析的主要產物。
組織級流程關注宏觀一般不會直接繪制，是對部門級流程的概括和抽象。崗位級流程關注每個業(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)功能分析。
7.需求分析有哪三種方法
它首先用結構化分析（SA）對軟件進行需求分析，然后用結構化設計（SD）方法進行總體設計，最后是結構化編程（SP）。它給出了兩類典型的軟件結構（變換型和事務型）使軟件開發(fā)的成功率大大提高。
三種基本的結構形式就是順序、選擇和重復。三種數(shù)據(jù)結構可以進行組合，形成復雜的結構體系。這一方法從目標系統(tǒng)的輸入、輸出數(shù)據(jù)結構入手，導出程序框架結構，再補充其它細節(jié)，就可得到完整的程序結構圖。這一方法對輸入、輸出數(shù)據(jù)結構明確的中小型系統(tǒng)特別有效，如商業(yè)應用中的文件表格處理。該方法也可與其它方法結合，用于模塊的詳細設計。
