需求分析方法

① 需求分析有哪幾個步驟

一、需求獲取階段
在需求獲取階段，需要做好收集和管理兩件事。

這些需求既有產品經理主動挖掘的，也有從用戶、運營、業務方、領導等渠道被動獲取的，無論哪個渠道來的需求，都需要有一個正式的地方進行管理，也就是我們通常所說的需求池。

不過，對於多方關注的重點需求，通過需求池來向各方同步就不太合適了：

一是因為需求池內容太多、太雜，向業務方、領導匯報的時候會有很多干擾信息，難以快速抓住重點；
二是因為需求池裡面可能有些需求不適合完全公開。
這時我們就需要使用《事項跟蹤表》來單獨跟進，形式上用Excel、PPT都可以。

而放在《事項跟蹤表》里的需求，也要在需求池裡記錄下來，即需求池是做全量需求管理的，《事項跟蹤表》是做重點需求跟進、匯報的。

二、需求分析階段
1. 分析內容
需求分析主要從需求要素、定位、分解、優先順序四個方面進行。

1）需求要素分析

需求要素分析是從需求本身出發，不考慮其他因素。

這些要素包括：內容、用戶/角色、頻次、價值、場景-動機、強度六個方面，這些要素的含義大家應該都比較清楚了，這里說一下分析各個要素的目的是什麼：

分析需求內容，是為了弄清楚需求是什麼；
分析需求用戶/角色，是為了弄清楚需求為誰服務；
分析需求頻次、強度，是為了弄清楚需求對用戶的重要性、緊迫程度；
分析需求場景-動機，是為了弄清楚需求真偽、用戶目的，更深入的理解需求；
分析需求價值，是為了弄清楚需求值不值得做。
2）定位分析

需求的定位分析是分析需求對產品當前階段目標的意義。

分析需求的定位，有以下兩個目的：

一是作為優先順序排期的判斷條件之一，如果需求與產品當前階段的目標密切相關，則需要作為高優先順序上線；
二是為了框定需求范圍。每個需求的實現程度都有深有淺，可以很簡單，也可以很復雜，了解了需求之於產品的定位，就能判斷需求要做到什麼程度。如果一個需求對產品很重要，那就需要做得很豐富，如果只是輔助需求，則需要適當輕量。
3）需求分解

原始需求的顆粒度往往較粗，不利於後續的分析、設計、開發等工作，所以我們需要對這些顆粒度較粗的原始需求進行分解，分解為一個個完整、獨立、可實現的子需求。

4）優先順序分析

優先順序分析是以拆解後的子需求為單位進行的，根據各類優先順序的判斷方法、原則，初步評估各個子需求的上線順序及時間。

2. 常見問題
需求分析應該是大家從入行那天就知道要做的事，但大多數同學在做需求分析時會犯以下三個比較常見的錯誤。

1）缺乏系統性

這是在分析中最常見的問題，即很多同學在分析需求時沒有系統性的框架，導致很多方面沒有分析到、考慮到，從而對需求認識不全面。

2）缺乏深度

對需求某些要素認識比較淺，不夠細致深入，例如在分析需求的用戶時，沒有對用戶分層、切片，對各個分層的用戶也缺乏足夠的了解，導致對用戶只有一個籠統、模糊的認識，最後自然無法深入進去。

不過分析是否有深度的定義其實很難把握，也缺乏明確的判斷標准，需要隨著分析者思維能力的提升、信息量的提升來加強。

② 需求分析的步驟有哪些

一、需求識別
需求人員在此步驟應該分析需求類別、需求復雜度和需求價值用來確定需求實施的優先順序。

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字）。

五、系統功能分析

③ 需求分析的建模分析方法有哪兩種

資料庫設計需求
1. 需求概述
建立完善的資料庫結構管理設備的基本參數、運行狀態和各種工作計劃。

資料庫的框架和結構必須根據設備和運行狀態而設計，方便提供強大的錄入、查詢、統計、分析和報表等各種功能操作，較好的反映平台業務的基本情況和運行狀況，滿足平台的基本要求。

2. 外部設計需求
2.1 標識符和狀態

資料庫表前綴：根據模塊名定義（如用戶模塊：sys_）

用戶名：root

密碼：待定

許可權：全部

有效時間：開發階段

說明：系統正式發布後，可能更改資料庫用戶/密碼。

2.2 使用它的程序

本系統主要利用java作為後端的應用開發工具，使用MySQL作為後台的資料庫， Linux或Windows均可作為系統平台。

2.3 約定

所有命名一定要具有描述性，杜絕一切拼音、或拼音英文混雜的命名方式。
字元集採用 UTF-8，請注意字元的轉換。
所有數據表第一個欄位都是系統內部使用主鍵列，自增欄位，不可空，名稱為：id，確保不把此欄位暴露給最終用戶。
除特別說明外，所有日期格式都採用date格式。
除特別說明外，所有欄位默認都設置不充許為空， 需要設置默認值。
所有普通縮影的命名都是表名加設置縮影的欄位名組合，例如用戶表User中name欄位設置普通所以，則縮影名稱命名方式為user_name_index。
2.4 專門指導

對本系統的開發者、使用這、測試員和維護人員，提出以下參考意見：

在使用資料庫時，首先要參考上面的約定內容，做好軟體的安裝以及表格的建立。
資料庫的輸入統一採用鍵盤。對於資料庫的使用許可權，請參考本系統其他相關文檔。
資料庫的後台管理員沒用等級差異，可根據實際情況添加刪除管理員。
2.5 支持軟體

操作系統： Linux / Windows

資料庫系統：MySQL

查詢瀏覽工具：Navicat Premium

命令行工具：mysql

注意：mysql 命令行環境下對中文支持不好，可能無法書寫帶有中文的 SQL 語句。

3. 結構設計需求
3.1 概念結構設計需求

概念資料庫的設計是進行具體資料庫設計的第一步，概念資料庫設計的好壞直接影響到邏輯資料庫的設計，影響到整個資料庫的好壞。

我們已經得到了系統的數據流程圖和數據字典，現在就是要結合數據規范化的理論，用一種模型將用戶的數據要求明確地表示出來。

概念資料庫的設計應該極易於轉換為邏輯資料庫模式，又容易被用戶所理解。概念資料庫設計中最主要的就是採用「實體-關系數據」模型來確定資料庫的結構。

數據是表達信息的一種重要的量化符號，是信息存在的一種重要形式。數據模型則是數據特徵的一種抽象。它描述的是數據的共性，而不是描述個別的數據。一般來說，數據模型包含兩方面內容：

數據的靜態特性：主要包括數據的基本結構、數據間的關系和數據之間的相互約束等特性。
數據的動態特性：主要包括對數據進行操作的方法。
在資料庫系統設計中，建立反映客觀信息的數據模型，是設計中最為重要的，也最基本的步驟之一。

數據模型是連接客觀信息世界和資料庫系統數據邏輯組織的橋梁，也是資料庫設計人員與用戶之間進行交流的共同基礎。概念資料庫中採用的實體-關系模型，與傳統的數據模型有所不同。「實體-關系」模型是面向現實世界，而不是面向實現方法的，它主要是用使用方便，因而在資料庫系統應用的設計中，得到了廣泛應用。「實體-關系」模型可以用來說明資料庫中實體的等級和屬性。

以下是實體-關系模型中的重要標識：

在資料庫中存在的實體；
實體的屬性；
實體之間的關系；
3.2 邏輯結構設計需求
物理結構設計需求

1）定義資料庫、表及欄位的命名規范：

資料庫、表及欄位的命名要遵守可讀性原則。
資料庫、表及欄位的命名要遵守表意性原則。
資料庫、表及欄位的命名要遵守長名原則。
2）選擇合適的存儲引擎：
3）為表中的欄位選擇合適的數據類型。

4）建立資料庫結構

4. 運用設計需求
4.1 表名的命名規范

表名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求小於30位。

4.2 表欄位的命名規范

欄位名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求不超過30位。
欄位名以名詞或名詞短語，欄位採用單數形式。若表名由多個單片語成，則取各個單詞的縮寫組成，單詞縮寫間使用下劃線作為分隔。
若某個欄位是引用某個表的外鍵，則欄位名應盡量與源表的欄位名保持一致，一面混淆。
5. 安全保密設計需求
5.1 防止用戶直接操作資料庫的方法

通過把關鍵應用伺服器和資料庫伺服器進行分離，防止用戶對資料庫伺服器的直接操作，保證資料庫安全。

5.2 應用系統的用戶口令進行加密

在軟體系統中，對於數據的保護、業務操作的許可是通過識別用戶身份和許可權來完成的。用戶口令相比較，相同的話系統將該用戶的操作許可權分配給用戶，用戶再根據所分配的許可權對系統進行操作。

由以上過程可知，用戶口令在傳輸過程中容易被竊取泄漏，另外如果資料庫被非法進入則其中保存的口令能夠被非法查看。因此，在傳輸過程中和資料庫中的口令記錄欄位不應使用明文傳遞和保存，應該在口令被傳遞前對其明文口令使用有效的主流技術，對傳輸數據進行加密部分描述的加密演算法進行加密，在加密後傳輸到系統。系統將用戶提交的經過加密的口令數據保存的加密口令進行比較，相一致則進行後續操作。

④ 需求分析有哪三種方法2，什麼是面向數據結構方法

它首先用結構化分析（SA）對軟體進行需求分析，然後用結構化設計（SD）方法進行總體設計，最後是結構化編程（SP）。它給出了兩類典型的軟體結構（變換型和事務型）使軟體開發的成功率大大提高。

三種基本的結構形式就是順序、選擇和重復。三種數據結構可以進行組合，形成復雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業應用中的文件表格處理。該方法也可與其它方法結合，用於模塊的詳細設計。

⑤ 需求分析怎麼做

10月22日 10:37 盡量把客戶所持的假設解釋清楚，特別是那些發生沖突的部分。從字里行間去理解以明確客戶沒有表達清楚但又想加入的特性或特徵。Gause 和Weinberg（1989）提出使用「上下文無關問題」—這是一個高層次的問題，它可以獲取業務問題和可能的解決方案的全部信息。客戶對這些問題的回答諸如「產品要求怎樣的精確度」或「你能幫我解釋一下你為什麼不同意某人的回答嗎？」這些回答可以更直接地認識問題，而這是封閉（close-end）問題所不能做到的。

需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟體解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間採用了更多的交流方式（Kiel and Carmel 1995）。與單個客戶或潛在的用戶組一起座談，對於業務軟體包或信息管理系統（MIS）的應用來說是一種傳統的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入（buy-in）的一種方式。

盡量理解用戶用於表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，並提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。

在需求獲取的過程中，你可能會發現對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業務和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那麼客戶將會提出很重要的但又在當前產品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的范圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。

正如經常所說的，需求主要是關於系統做什麼，而解決方案如何實現是屬於設計的范圍。這樣說雖然很簡潔，但似乎過於簡單化。需求的獲取應該把重點放在「做什麼」上，但在分析和設計之間還是存在一定的距離。你可以使用假設「怎麼做」來分類並改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然後提供一個尋找錯誤和遺漏的辦法。把你在需求開發階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。

需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。相反地，從極少的代表那裡收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最好的權衡在於選擇一些授權為他們的用戶類發言的產品代表者，他們也被同組用戶類的其它代表所支持。

沒有一個簡單、清楚的信號暗示你什麼時候已完成需求獲取。當客戶和開發者與他們的同事聊天、閱讀工業和商業上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。

1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。

2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。

3. 如果用戶開始重復原先討論過的問題，此時，也許你就完成了收集需求的工作。

4. 如果所提出的新需求比你已確定的需求的優先順序都低時，也許你就完成了收集需求的工作。

5. 如果用戶提出對將來產品的要求，而不是現在我們討論的特定產品，也許你就完成了收集需求的工作。

以上知識大致上討論需求分析應該如何做，實際上對於需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的應用主要還是要靠個人。所以，大家在實際應用的時候，不妨結合自己的實際，有選擇性的採用一些方法，那你就是成功的。
用例在需求分析中的使用

多年來，分析者總是利用情節或經歷來描述用戶和軟體系統的交互方式，從而獲取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源於面向對象的開發環境，但是它也能應用在具有許多開發方法的項目中，因為用戶並不關心你是怎樣開發你的軟體。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什麼遠遠強於詢問用戶希望系統為他們做什麼這一傳統方法。

用例的重要功能是用畫用例圖的功能來鑒別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬體或者甚至是其它軟體系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分並接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應採取的補救措施。

這樣說可能會非常復雜，其實一個用例描述了系統和一個角色（actor）的交互順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:

· 用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。

· 用例由角色激活，並提供確切的值給角色。

· 用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。在UML中，用例表示為一個橢圓。

角色是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例（例如有很多個銷售員），但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，一個高級營銷人員既可以是貿易經理，也可以是普通的營銷人員；一個營銷人員也可以是售貨員。在處理角色時，應考慮其作用，而不是人或工作名稱，這一點是很重要的。

我們使用不帶箭頭的線段將角色與用例連接到一起，表示兩者之間交換信息，稱之為通信聯系。角色觸發用例，並與用例進行信息交換。單個角色可與多個用例聯系；反過來，一個用例可與多個角色聯系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡管執行的，但角色未必是人。例如，角色也可以是一個外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進行交互。

一個用例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個用例是相關的用法說明的集合，並且一個說明（scenario）是用例的實例。這種關系就像是類和對象的關系。在用例中，一個說明被視為事件的普通過程(normal course)，也叫作主過程，基本過程，普通流，或「滿意之路」 (happy path)。在描述普通過程時列出執行者和系統之間相互交互或對話的順序。當這種交互結束時，執行者也達到了預期的目的。

在用例中的其它說明可以描述為可選過程(alternative coruse)。可選過程也可促進成功地完成任務，但它們代表了任務的細節或用於完成任務的途徑的變化部分。在交互序列中，普通過程可以在一些決策點上分解成可選過程，然後再重新匯成一個普通過程。

角色類和角色實例

軟體產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟體目標組織中所處的地位不同，地理位置不同，業務熟練程度不同。

不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率。考慮到用戶的差異性，將用戶分類並研究用戶類的行為特徵是非常有必要的。所以在做具體的需求之前，先將用戶分局行為和特點進行分類，對於研究、收集用戶的需求是非常有幫助的。

可以利用一個簡單的表格列出一些原始的分類，然後不斷的完善這個表格。確認你的分類之間沒有交集。並充分描述用戶分類的行為，目的，要求等。在企業分析中，比較常見的分類可能包括，供應商，客戶，部門等。

就像C++中的類和對象一樣，我們把分析出的用戶分類稱為「角色類」，把實際的用戶稱為「角色實例」。在得到用戶分類之後，最重要的就是要選出用戶代表，用戶代表不僅僅是在需求階段中參與項目，還必須對項目的全過程負責。用戶代表能夠代表用戶分類的需求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規模的調查的，只是要把重點放在用戶代表上。

確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向後傳，到最後，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。

對於和用戶直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟體，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：

做大規模的市場調查，針對你的目標市場做市場調查，並根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些游戲公司會發布一些Demo版的游戲。可是對於一般的企業來說，這項工作費時費力，高昂的成本往往使大家知難而退。我的意見是，方法是非常好的，但是可以採用折衷的辦法，例如選取有代表性的企業，為特定企業製作一個較小的版本並收集反饋意見等。這涉及到很多市場營銷的內容，並不是我的專業所長，這里就不多弄斧了。
聘請行業專家，一個行業專家往往可以在項目需求方面發揮極為重要的作用。一個行業專家往往都有大量的行業經驗和行業的人際關系網路。在產品的設計方面，這個行業專家提供很多寶貴的意見。在目前很多的軟體的開發過程中都採用了這種方式。行業專家有兩種：一種是在這個行業中有很深的資歷，但是對軟體技術並不熟悉；第二種是開發過同類軟體的軟體專家，這種人在開發同類軟體過程中已經積累了大量的項目經驗，並且具有軟體開發的知識。這種方式是獲取需求的最好的方式。 分析對比同類軟體，微軟在開發Office、Visual Studio的時候，也是參照了Lotus和Borland的成熟產品。這種方式的特點在於成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。

需求的沖突

有的時候，雖然已經將用戶分類並選出了用戶代表。但是需求的來源眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來後，人們難以解決沖突，澄清模糊之處以及協調不一致之處。某些人還要對不可避免要發生的范圍問題單獨作出決定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權並且有責任來作出決策，或者授權的個人不願意或不能作出決策，那麼決策者的角色將自然而然地落在開發者身上。這是一個非常糟糕的選擇，因為開發者通常沒有足夠多的信息和觀點來作出業務上的決策。

在軟體項目中，誰將對需求作出決策的問題並沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處於公司底層的人作出決策，因為他們與問題密切相關，並能得到關於這些問題的廣泛信息。

如果不同的用戶類有不一致的需求，那麼必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助於你決定哪一個用戶類所佔份額最大。

當開發者想像中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到「客戶總是對的」的陷阱中去，對他們百依百順。現實中，客戶並不總是對的。客戶總是持有自己的觀點，開發者必須理解並尊重這一觀點。

用例

在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由於用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。

為什麼要採用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上採集信息，然後由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。

用例圖適於表達交互，之所以上面使用了電信系統，是因為用例最早來自於Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，並於1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的用於對功能進行描述。每個用例代表了系統與外部ACTOR的交互。可以採取順序圖來表達用例的具體操作程序。ACTOR用於確定系統的邊界。

ACTOR、用例可以從不同的層次來描述信息。採用該原則的原因有：

1. 需求並不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。

2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。採用不同的層次來描述，適於認知的過程。

使用用例開發系統的一般過程

在開發過程的初始階段，可以根據具體的項目特點，制訂開發各個視圖之間的關聯原則，指導規范。在開發的過程中，視圖的組織原則應不斷進行維護、更新。

識別ACTOR來識別系統與外界交互的實體。ACTOR具有特定領域的特徵，例如：交換機（採集系統）、97信息系統等。在系統層次的ACTOR確定了系統的邊界。

識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。註：系統開發需要一定的規則來確定，如何來分解用例；可能基於原有系統的經驗，或是參考現有資料。

當用例細化到可以被理解的層次。需要基於用例進行下一步的開發。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節。交互的實體採用類圖來描述；而交互的細節，採用順序圖來描述。

當系統復雜到一定層次時，類圖和順序圖可能不能足以描述其復雜程度。在該情況下，需要使用狀態圖來輔助闡述。狀態圖和順序圖之間使用事件聯結在一起。它們之間的一致性問題，目前UML和ROSE沒有提供解決方案。相對折衷的方法是使用事件的命名規范強制一致性。

可以說，之前說的所有的東西都是為了能夠導出用例在需求中的作用。用例是從用戶的角度看待系統，而不是基於程序員的角度。這樣的話，用例驅動的系統能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統開發鏈中完整的體現。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。 從前，系統開發者總是通過情節來獲取需求，是問用戶希望系統為他做什麼。在Jacobson發明了用例的概念之後，需求獲取就變成問用戶要利用系統做什麼。這是立場不同導致的結果。用戶通常並不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源於用戶，服務於用戶，但是它同樣可以用於開發的流程。當系統的開發過程都是基於用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。 用例和用例文檔

《軟體需求》一書中提到了幾種方法來確定用例：

· 首先明確執行者和他們的角色，然後確定業務過程，在這一過程中每一個參與者都在為確定用例而努力。

· 確定系統所能反映的外部事件，然後把這些事件與參與的執行者和特定的用例聯系起來。

· 以特定的說明形式表達業務過程或日常行為，從這些說明中獲得用例，並確定參與到用例中的執行者，有可能從現在的功能需求說明中獲得用例。如果有些需求與用例不一致，就應考慮是否真的需要它們。

用例代表了用戶的需求，在你的系統中，應該直接從不同用戶類的代表或至少應從代理那裡收集需求。用例為表達用戶需求提供了一種方法，而這一方法必須與系統的業務需求相一致。分析者和用戶必須檢查每一個用例，在把它們納入需求之前決定其是否在項目所定義的范圍內。基於「用例」方法進行需求獲取的目的在於：描述用戶需要使用系統完成的所有任務。在理論上，用例的結果集將包括所有合理的系統功能。在現實中，你不可能獲得完全包容，但是比起我所知道的其它獲取方法，基於用例的方法可以為你帶來更好的效果。

當使用用例進行需求獲取時，應避免受不成熟的細節的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節都作為需求記錄下來，他們會給隨後的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發過程中，將會詳盡闡述他們的需求。在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，並作為用例。然後，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和用戶對質量的期望。雖然最初的屏幕構思有助於描述你對需求的理解，但是你必須細化用戶界面設計。

建立用例文檔。在每一次的需求獲取之後，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術能夠提高你的速度和需求的復用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標識號、用例名稱、父用例標志號、創建者、創建時間、審核者、修訂記錄、角色、說明、先決條件、請求結果、優先順序、普通過程、可選過程、例外、非功能需求、假設、注釋和問題。

雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟體系統，並不是一大堆的用例說明。

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

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

⑦ 項目需求分析的分析方法

需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.
原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟體的一個早期可運行的版本,它實現了目標系統的某些或全部功能.
原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如演算法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟體工具快速的建造一個原型系統,這個系統只是一個界面,然後聽取用戶的意見,改進這個原型.以後的目標系統就在原型系統的基礎上開發.
原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標系統的要求,確定所希望的特性,並探討多種方案的可行性.實驗型:用於大規模開發和實現前,考核方案是否合適,規格說明是否可靠.進化型:目的不在於改進規格說明,而是將系統建造得易於變化,在改進原型的過程中,逐步將原型進化成最終系統。
在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想,據此設計出較完整,准確,一致,可靠的最終系統.系統構造完成後,原來的模型系統就被廢棄不用.探索型和實驗型屬於這種策略。
追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心,然後通過不斷地擴充修改,逐步追加新要求，發展成為最終系統。進化型屬於這種策略.

⑧ 需求分析方法主要包括哪些

結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。

面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於通過抽象的方式來推演最終系統的運行方式，對業務人員的要求非常高。

⑨ 測試需求分析方法有哪些

什麼是測試需求?
確切地講，所謂的測試需求就是在項目中要測試什麼。我們在測試活動中，首先需要明確測試需求(What)，才能決定怎麼測(How)，測試時間(When)，需要多少人(Who)，測試的環境是什麼(Where)，測試中需要的技能、工具以及相應的背景知識，測試中可能遇到的風險等等，以上所有的內容結合起來就構成了測試計劃的基本要素。而測試需求是測試計劃的基礎與重點。
就像軟體的需求一樣，測試需求根據不同的公司環境，不同的專業水平，不同的要求，詳細程度也是不同的。但是，對於一個全新的項目或者產品，測試需求力求詳細明確，以避免測試遺漏與誤解。
為什麼要做測試需求?
如果要成功的做一個測試項目，首先必須了解測試規模、復雜程度與可能存在的風險，這些都需要通過詳細的測試需求來了解。所謂知己知彼，百戰不殆。測試需求不明確，只會造成獲取的信息不正確，無法對所測軟體有一個清晰全面的認識，測試計劃就毫無根據可言。活在自己世界裡的人是可悲的，只憑感覺不做詳細了解就下定論的項目是失敗的。
測試需求越詳細精準，表明對所測軟體的了解越深，對所要進行的任務內容就越清晰，就更有把握保證測試的質量與進度。
如果把測試活動比作軟體生命周期，測試需求就相當於軟體的需求規格，測試策略相當於軟體的架構設計，測試用例相當於軟體的詳細設計，測試執行相當於軟體的編碼過程。只是在測試過程中，我們把「軟體」兩個字全部替換成了「測試」。這樣，我們就明白了整個測試活動的依據來源於測試需求。
測試需求的收集主要通過對測試依據進行分析整理，最後生成一個以測試的觀點出發的checklist(檢查表)，用來作為測試該軟體的主要工作內容。檢查表的檢查要點包括需求的正確性、必要性、優先順序、明確性、可測性、完整性、一致性、可修改性：
在整個信息收集過程中，務必確保軟體的功能與特性被正確理解。因此，測試需求分析人員必須具備優秀的溝通能力與表達能力。
以上主要描述了測試需求相關理論和獲得測試需求樹的一般過程。為具體項目實施測試中提供了一套獲取測試需求樹的參考方案。實際的測試類型劃分和測試需求樹生成的形式或粒度，因項目而不同，需靈活應用。

⑩ 如何做需求分析

1:抓核心點，不是所有用戶訴求都是需求
我們每做一個項目迭代或者新項目一定有目的，而需求分析階段，需求採集渠道中的需求往往是零散的、無重點的、邏輯性不強的，所以我們需要從這些離散的需求點中要抓住核心，梳理實際使用場景去分析問題，所有的核心點一定是以最終目的為導向的，不是所有用戶訴求都是需求。
以我的項目為例，由於歷史原因，自配送人員關系沒有進入OA系統，所以配送員工資結算數據只能做進配送系統，相當於是一個簡單考勤記錄，其實最早之前系統是有這個功能的，但是由於之前沒有仔細整理需求，導致這個功能白做了，所以這次我接手幾乎從做，我以為這個事情比較簡單就讓一個產品助理先去整理需求，當把原型圖出出來時發現並不能解決結算工資的功能，只是一個簡單的排班。
所以，當時我就跟那小兄弟說，你這東西只是完成了排班，然而排班的目的為了結算工資這還不能滿足需求。所以我跟他強調，我們做這個需求的目的是為了考勤，諸如請假、值班、加班工時、輪休日加班等數據要能提供出來，他的第一版原型其實沒有充分了解到我們為什麼要做這個排班功能，所以在了解需求過程中沒有抓住核心點，導致需求不明確。
2:制定規則、改善復雜流程
我的上一家企業做的是互聯網電商，其實在我看來電商和O2O有很大的區別點就是電商在當下盛行的情況下已經變的很有規則了，首頁、產品列表頁、詳情頁、下單頁等等，每個頁面展示的信息也大相徑庭，而O2O不一樣，一方面是O2O差不多13年才興起，到目前為止（15年）還沒有一個標桿行業，另一方面是O2O與日常生活聯系的太緊密，落地下來就是很復雜的業務流，這些是to C產品的規則化和流程化，而流程化的東西在to B產品上體現的尤為明顯，to B產品最經典的例子就是公司後台系統。
不論是一個to C的產品還是to B的產品，我們都要考慮到用戶使用場景，PM需要把自己當作用戶，充分考慮各種情況下的用戶思維才能設計一個滿足用戶需求的產品，這里並不是一味的去迎合用戶，做互聯網的都知道當一個業務不是規則化時很難用產品去滿足用戶，所以我們有必要制定規則，或者優化不完善、流程復雜的
規則。
下面說說制定規則，其實統一規則有利有弊，舉個例子，滴滴打車的訂單是搶的，uber打車的訂單是系統自動分配的，滴滴那種做法能提高司機積極性、自主性，司機可以選擇高金額的訂單，但是這種做法也會影響用戶體驗，比如說萬一以後不補貼了，我只是一個起步價，有些司機就不願意接單，要等待很久；而uber打車制定了自動分配的規則，先分配目前離乘客最近的空閑司機，如果他不接再分配給下一個，這種做法能不能滿足用戶我不說，我只說這種規則簡化了下單流程，司機和乘客只有兩個選項，接還是不接，坐還是不坐，司機如果不接，但他並不知道下一單能等到什麼時候，訂單金額有多大？雖然司機間的積極性和自主性減少，但是對用戶來說體驗很好。
說完了制定規則，再說一下改善流程，我上面說了這種流程化精簡在to B產品上尤為明顯，很多人有個看法就是後台系統反正是自己人或者其他企業人員用的，完成功能就行，沒必要做的這么便捷和細致，其實不然，優秀的PM在這方面總能善始善終，因為在他們眼裡一點點的產品優化或者流程優化能為企業帶來很多的效益，這個我有切身的體會。
之前做的多個項目，其中有兩個就是我在做需求的時候發現業務部門在實際運營中思維定勢或者每日重復做屬於他的工作，但是他們並沒有發現這樣做其實效率很低，在沒人觀察流程有問題的時候，業務部門已經形成規范，但是這種規范並不是最優的，當PM做需求分析的時候需要細致觀察他們部門或者個人的工作內容，想一想為什麼這么樣做，有沒有其他方案能提高其工作效率。
在做數據統計需求的時候我發現業務部門某同事每天要先導出所有新用戶電話、訂單號、餐廳金額、訂單金額等數據用於考察配送員滿意度、用戶滿意度，然而她每天導出的數據其實有另外兩個同事也需要用，只是使用目的不一樣，但是他們都很死板，他們三個每天導出一份完整數據，然後篩選條件，組合成自己要的數據，這種工作其實很沒必要，我們可以每天為他們部門發一份當日訂單報表，標注新用戶即可。
還有個例子是，財務在結算物流人員工資的時候很多計算公式是相互關聯的，比如說A=B+C，D=A*E+B-C，然而他們就計算成D=(B+C)*E+B-C，暫且不說他們部門管理流程怎麼樣，但是PM在遇到這樣業務流程的時候結合產品設計考慮是否可以精簡流程，實現產品設計的初衷的同時也能簡化流程。
3:離散需求整合
在和業務部門打交道的時候發現他們的思維邏輯性可能稍微差點，在PM了解需求的時候業務人員或者用戶表述的沒有前因後果，也就是沒有邏輯性，這時如果PM不追問下去自己很容易被帶到坑裡面，合格的PM應該在這種情況下峰迴路轉，把問題再闡述一遍，如遇到稍微強勢一點的PM，此時應該會指出剛才的表述有錯誤。
還有的業務部門人員在你去溝通的時候嘩啦啦的說了一大推產品改進意見或者新需求想法，此時PM應該細心聆聽，記錄下需求點，千萬不要給他們答復這個功能什麼時候做、什麼時候上線，因為系統永遠是不完善的、需求卻永遠是數不盡的，而資源是有限的，你給的答復實現不了別人會有不好的看法，優秀的PM需要大局觀，能夠和團隊一起評估需求優先順序，規劃產品生命周期，這才能推進產品迭代。
4:技術人員參與需求分析階段
現在很多互聯網公司基本上都是產品驅動，很難說技術驅動，因為產品團隊可以知道用戶想要什麼，我在參與需求分析過程中事業部技術負責人喜歡跟著我一起去了解需求，這在我之前的工作組中沒遇到過，現在做需求的時候他參與進來後我發現整個產品需求被亂了，阻礙了我需求分析進度，因為他總是以技術的角度考慮這樣實現的難度，由於他是技術負責人，邏輯思維能力很強，每當聽到這個數據沒有需要新增一個入口去維護時他就站出來說為什麼要這樣做，然後勸說業務部門說這個數據提供不了，能不能先不做。
但是從產品角度上考慮，既然選擇做這個項目那麼就該從產品角度去設計好，等一整套產品方案出來之後再去精簡功能是一個很好的方法，還有一些情況是當有一個比較好的idea產生時技術人員會首先考慮能不能實現、實現的復雜度，如果有一點困難或者技術可行方案不能當場給出時，這個功能就暫且擱置了，也許就會提出另一個不會錯但是並不是最好的方案，所以技術人員參與需求分析階段最容易把原本一個好的產品扼殺在搖籃之中。綜上考慮，我的理解是技術人員在需求分析階段暫且不要參與進來，等產品團隊內部討論之後技術團隊參與審評，這樣也許能達到事半功倍的作用。