需求分析是互聯網企業的一個重要的工作環節。中培課堂《需求分析與管理最佳實踐》培訓專家劉老師指出需求分析不是一蹴而就的，是一個反復迭代的過程。它將從第一次需求分析開始，一直持續到整個項目生命周期。

在第一次的需求分析階段，我們在一段時期內需要與客戶進行反復地討論，這個過程往往是這樣一個反復循環的過程：需求捕獲->需求整理->需求驗證->再需求捕獲??????

需求捕獲，就是我們與客戶在一起開研討會，討論需求的活動。客戶可能會描述他們的業務流程，這時我們在紙上繪制簡單的流程草圖，及時地記錄下來；客戶在描述業務的同時，可能會反復提到一些業務名詞，詳細詢問這些名詞的含義，以及它們與其它名詞的關系，用類圖或者對象圖繪制簡單的草圖；客戶在描述業務的同時，還會提出今后的軟件希望實現的功能，如能夠展示某個報表、能夠導出文件，以需求列表的形式記錄下來。一個功能，在需求列表中會有多個需求，而每個需求應當能夠用1、2句話，在20個字以內就可以描述清楚。需求列表是客戶提出的最最原始的需求，他不摻雜任何分析設計，是我們的每項功能必須實現的內容。需求列表是需求驗證以及日后的用戶驗收測試的依據，不論我們今后如何分析和設計這些功能，都要能如實地實現這個列表中提出的需求。（需求列表應當如何編寫，將在后面的章節詳細描述。）

需求整理，就是在需求研討會后，需求分析人員對研討內容的分析和整理的過程。首先，需求分析人員應當通過用例模型，劃分整個系統的功能模塊，以及各個模塊的業務流程。用例模型分析是一個由粗到細的過程，這樣一個過程也是符合人類認識世界的思維習慣的一個過程。最先，我們應當對整個系統繪制用例圖，設計用例場景，并依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然，在整體用例分析的同時，我們還應當進行一個整體的角色分析，繪制一個角色分析圖，進行一個流程分析，繪制一個流程分析圖（可以是傳統的流程圖、UML中的行動圖，甚至一個簡單的示意圖，等等）。

然后，我們再在整體用例圖的基礎上，依次對每個用例繪制用例圖。每個用例圖中，會更細致地劃分出多個用例，并依次進行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細化，直到我們認為需求已經描述清楚為止。

在一個系統中，用例需要細化幾次，是由這個用例的業務復雜程度決定的。對于一個簡單的用例，只需要細化一次就夠了；而對于比較復雜的用例，則需要細化2~3次，甚至更多。

用例分析的過程，之所以稱之為分析，它摻入了很多需求分析人員對業務的理解與設計：模塊如何劃分、流程如何設計、業務如何轉換，等等。用例分析，還需要讓需求分析員與架構師、設計師等技術人員共同協作來完成，因為用例分析還包含對業務需求的技術可行性分析。只有一份可行的需求分析，才能為后續的設計開發掃清障礙，有效降低項目風險。最后，需求分析員應當將需求列表中的內容，逐一地與用例進行核對，以避免分析人員忽略用戶的某項業務需求。（后面將詳細描述用例模型的搭建過程。）

在用例分析的同時，需求分析人員還需要對業務中的相關事物，制作領域模型。領域模型，是對用戶業務領域中相關事物、相互關系、相互行為操作的描述，它是以對象圖和類圖的形式表達的。需求人員對領域模型的分析，對業務理解的深度，對日后軟件的設計，以及軟件的功能擴展、升級演化，都起到了至關重要的作用。（后面將更加詳細地講述領域模型。）

最后，當我們完成了一系列的分析整理并形成文檔以后，應當對及時地與客戶進行反饋，確認我們的理解是否正確，也就是需求驗證工作。需求驗證工作應當貫穿整個研發周期，并且在不同時期表現出不同的形式。首先，在需求分析階段，需求驗證工作表現為對需求理解是否正確的信息反饋。需求分析人員與客戶再次坐在一起，一項一項描述我們對需求的整理和理解，客戶則時不時地對一些問題進行糾正，或者更加深入地加以描述。我們則認真地記錄，回來整理，并等待下一次的驗證。在需求分析后期，我們還可以制作一些簡單的原型，更加形象地描述我們對需求的理解，會使我們與客戶的溝通更加順暢。隨后的設計開發階段，我們則應當以迭代開發的形式進行。

每開發完一個迭代周期，將開發的成果與客戶反饋。這樣做的結果是，客戶可以及時地提出我們對需求理解的偏差，或者及時提出對我們設計不滿意的地方，使我們存在的問題得到及時地發現與解決。問題及時的解決，使我們修復問題的代價得以降至最小。之后，當開發進入到驗收測試階段，我們則是與客戶一道，一項一項地驗證我們的軟件是否滿足需求列表中要求的業務需求。最后，當軟件迎來下一次升級開發時，我們將開啟另一次輪回。

因此，需求分析就是按照這樣的過程，每次多理解一些，再多理解一些，更多理解一些，逐漸深入的過程。每深入一步，我們的軟件就更接近客戶的滿意。