需求分析員的工作方法

㈠ 需求分析常用方法

行為事件分析

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

以用戶投標的行為事件為例，出借人在完成投標過程中，所進行的注冊、認證、開戶、充值、投資等行為，都可以定義為事件，也是完成投標成功的一個完整事件。
確定投標行為事件後，我們可以根據事件屬性細分維度：用戶來源、性別、出生年月、注冊時間、綁卡時間、首次充值時間、首次投資時間、標的ID，標名、期限、利率、還款方式等。然後從中找出符合指標的規律，並制定針對性的措施。

用戶留存分析

用戶留存分析是一種用來分析用戶參與情況與活躍程度的模型。通過留存量和留存率，可以了解用戶的留存和流失狀況。比如用次日留存、周留存、月留存等指標來衡量產品的人氣或粘度。以渠道訪問的用戶留存為例，我們對APP端有過訪問行為的渠道用戶進行留存分析。用戶留存一般符合40-20-10法則，即新用戶的次日留存應該大於40%，周留存大於20%，月留存大於10%才符合業務標准。我們做用戶留存分析主要驗證是否達到既定的運營目標，進而影響下一步的產品決策。

漏斗模型分析

漏斗模型分析是用戶在使用產品過程中，描述各個階段中關鍵環節的用戶轉化和流失率情況。比如在日常活動運營中，通過確定各個環節的流失率，分析用戶怎麼流失、為什麼流失、在哪裡流失。找到需要改進的環節，要重點關注，並採取有效的措施來提升整體轉化率。

邀請人將活動專題頁分享給好友，之後進行的注冊、認證、開戶、充值到投資，用漏斗模型分析一些關鍵節點的轉化率。其中用戶注冊轉化率為68%，實名認證轉化率為45%，綁卡開戶轉化率為29%，線上充值轉化率為17%，投資標的轉化率為8%。
漏斗模型分析可以驗證整個流程的設計是否合理。經過對比發現，訪問到注冊的轉化率為68%，遠低於預期的80%。這次運營策略是用戶必須先注冊才能領取新手福利。之後採取A/B測試的方式，優化為先領取新手福利再誘導用戶注冊。經過數據對比分析，注冊轉化率提升了20%。因此，通過對各環節相關轉化率的比較，可以發現運營活動中哪些環節的轉化率沒有達到預期指標，從而發現問題所在，並找到優化方向。

行為路徑分析

行為路徑分析就是分析用戶在產品使用過程中的訪問路徑。通過對行為路徑的數據分析，可以發現用戶最常用的功能和使用路徑。並從頁面的多維度分析，追蹤用戶轉化路徑，提升產品用戶體驗。

不管是產品冷啟動，還是日常活動營銷，做行為路徑分析首先要梳理用戶行為軌跡。用戶行為軌跡包括認知、熟悉、試用、使用到忠誠等。軌跡背後反映的是用戶特徵，這些特徵對產品運營有重要的參考價值。我們可以記錄用戶從注冊、認證、開戶、充值到投資的行為軌跡。通過分析用戶的這些行為軌跡數據，來驗證訪問路徑是否和預期指標的一致。

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

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

  

㈢ 需求分析怎麼做

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發明了用例的概念之後，需求獲取就變成問用戶要利用系統做什麼。這是立場不同導致的結果。用戶通常並不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源於用戶，服務於用戶，但是它同樣可以用於開發的流程。當系統的開發過程都是基於用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。 用例和用例文檔

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

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

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

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

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

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

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

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

㈣ 需求分析師的一般工作流程是什麼

需求分析師的工作流程，首先是從需求調研開始的，調研完成後就是需求的分析，然後再去找客戶進行需求評審，最後確定需求。

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

轉載以下資料供參考

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。
原因
需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個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)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。
(4)面向對象的分析方法。
面向對象的分析方法的關鍵是識別問題域內的對象，分析它們之間的關系，並建立三類模型，即對象模型、動態模型和功能模型。面向對象主要考慮類或對象、結構與連接、繼承和封裝、消息通信，只表示面向對象的分析中幾項最重要特徵。類的對象是對問題域中事物的完整映射，包括事物的數據特徵(即屬性)和行為特徵(即服務)

㈦ 人員需求分析怎麼做

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

1.需求類別確認：

需求類別包含流程類需求、統計分析類需求、介面類需求，一個需求可能為某一類型需求，也可能包含多類需求。

確認需求類別後應對每類需求的數量進行初步分析（比如流程類需求包含幾個流程、統計分析類需求包含幾個報表、介面類需求包含幾個介面）。

2.需求復雜度分析：

一般需求受理工作量在1-5人天的需求復雜度低，工作量在5-15人天的需求復雜度中，工作量在15人天以上需求復雜度高。（工作量表示需求受理全過程需求人員需要付出的工作量）。

3.價值分析：

需求人員收到需求後應根據收集需求內容初步分析需求痛點/目標、需求復雜度、業務重要程度確定需求價值，需求價值分析
二、業務流程/統計查詢/介面分析
針對流程類需求必須進行業務流程分析，統計查詢和介面類需求可不進行詳細的流程分析。

1.業務流程分為部門級、組織級和崗位級

部門級流程關注脈絡需要分析涉及哪些具體崗位、執行活動、每個活動之間的關聯關系，它是需求分析的主線條，也是流程分析的主要產物。
組織級流程關注宏觀一般不會直接繪制，是對部門級流程的概括和抽象。
崗位級流程關注每個業務活動的執行步驟屬需求細節范疇，在流程分析階段不要過度進入細節。
2.需求識別階段確認的流程均為部門級流程