六、我們應當怎樣做需求調研：迭代
阿新 • • 發佈：2018-12-24
前面我一直在反覆強調這樣一個觀點，需求分析不是一蹴而就的，是一個反覆迭代的過程。它將從第一次需求分析開始，一直持續到整個專案生命週期。為什麼這樣說呢？讓我們一起來分析分析。
在第一次的需求分析階段，我們在一段時期內需要與客戶進行反覆地討論，這個過程往往是這樣一個反覆迴圈的過程：需求捕獲->需求整理->需求驗證->再需求捕獲••••••
需求捕獲，就是我們與客戶在一起開研討會，討論需求的活動。客戶可能會描述他們的業務流程，這時我們在紙上繪製簡單的流程草圖，及時地記錄下來；客戶在描述業務的同時，可能會反覆提到一些業務名詞，詳細詢問這些名詞的含義，以及它們與其它名詞的關係，用類圖或者物件圖繪製簡單的草圖；客戶在描述業務的同時，還會提出今後的軟體希望實現的功能，如能夠展示某個報表、能夠匯出檔案，以需求列表的形式記錄下來。一個功能，在需求列表中會有多個需求，而每個需求應當能夠用1、2句話，在20個字以內就可以描述清楚。需求列表是客戶提出的最最原始的需求，他不摻雜任何分析設計，是我們的每項功能必須實現的內容。需求列表是需求驗證以及日後的使用者驗收測試的依據，不論我們今後如何分析和設計這些功能，都要能如實地實現這個列表中提出的需求。（需求列表應當如何編寫，將在後面的章節詳細描述。）
需求整理，就是在需求研討會後，需求分析人員對研討內容的分析和整理的過程。首先，需求分析人員應當通過用例模型，劃分整個系統的功能模組，以及各個模組的業務流程。用例模型分析是一個由粗到細的過程，這樣一個過程也是符合人類認識世界的思維習慣的一個過程。最先，我們應當對整個系統繪製用例圖，設計用例場景，並依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然，在整體用例分析的同時，我們還應當進行一個整體的角色分析，繪製一個角色分析圖，進行一個流程分析，繪製一個流程分析圖（可以是傳統的流程圖、UML中的行動圖，甚至一個簡單的示意圖，等等）。
然後，我們再在整體用例圖的基礎上，依次對每個用例繪製用例圖。每個用例圖中，會更細緻地劃分出多個用例，並依次進行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細化，直到我們認為需求已經描述清楚為止。
在一個系統中，用例需要細化幾次，是由這個用例的業務複雜程度決定的。對於一個簡單的用例，只需要細化一次就夠了；而對於比較複雜的用例，則需要細化2~3次，甚至更多。
用例分析的過程，之所以稱之為分析，它摻入了很多需求分析人員對業務的理解與設計：模組如何劃分、流程如何設計、業務如何轉換，等等。用例分析，還需要讓需求分析員與架構師、設計師等技術人員共同協作來完成，因為用例分析還包含對業務需求的技術可行性分析。只有一份可行的需求分析，才能為後續的設計開發掃清障礙，有效降低專案風險。最後，需求分析員應當將需求列表中的內容，逐一地與用例進行核對，以避免分析人員忽略使用者的某項業務需求。（後面將詳細描述用例模型的搭建過程。）
在用例分析的同時，需求分析人員還需要對業務中的相關事物，製作領域模型。領域模型，是對使用者業務領域中相關事物、相互關係、相互行為操作的描述，它是以物件圖和類圖的形式表達的。需求人員對領域模型的分析，對業務理解的深度，對日後軟體的設計，以及軟體的功能擴充套件、升級演化，都起到了至關重要的作用。（後面將更加詳細地講述領域模型。）
最後，當我們完成了一系列的分析整理並形成文件以後，應當對及時地與客戶進行反饋，確認我們的理解是否正確，也就是需求驗證工作。需求驗證工作應當貫穿整個研發週期，並且在不同時期表現出不同的形式。首先，在需求分析階段，需求驗證工作表現為對需求理解是否正確的資訊反饋。需求分析人員與客戶再次坐在一起，一項一項描述我們對需求的整理和理解，客戶則時不時地對一些問題進行糾正，或者更加深入地加以描述。我們則認真地記錄，回來整理，並等待下一次的驗證。在需求分析後期，我們還可以製作一些簡單的原型，更加形象地描述我們對需求的理解，會使我們與客戶的溝通更加順暢。隨後的設計開發階段，我們則應當以迭代開發的形式進行。每開發完一個迭代週期，將開發的成果與客戶反饋。這樣做的結果是，客戶可以及時地提出我們對需求理解的偏差，或者及時提出對我們設計不滿意的地方，使我們存在的問題得到及時地發現與解決。問題及時的解決，使我們修復問題的代價得以降至最小。之後，當開發進入到驗收測試階段，我們則是與客戶一道，一項一項地驗證我們的軟體是否滿足需求列表中要求的業務需求。最後，當軟體迎來下一次升級開發時，我們將開啟另一次輪迴。
因此，需求分析就是按照這樣的過程，每次多理解一些，再多理解一些，更多理解一些，逐漸深入的過程。每深入一步，我們的軟體就更接近客戶的滿意。
在第一次的需求分析階段，我們在一段時期內需要與客戶進行反覆地討論，這個過程往往是這樣一個反覆迴圈的過程：需求捕獲->需求整理->需求驗證->再需求捕獲••••••
需求捕獲，就是我們與客戶在一起開研討會，討論需求的活動。客戶可能會描述他們的業務流程，這時我們在紙上繪製簡單的流程草圖，及時地記錄下來；客戶在描述業務的同時，可能會反覆提到一些業務名詞，詳細詢問這些名詞的含義，以及它們與其它名詞的關係，用類圖或者物件圖繪製簡單的草圖；客戶在描述業務的同時，還會提出今後的軟體希望實現的功能，如能夠展示某個報表、能夠匯出檔案，以需求列表的形式記錄下來。一個功能，在需求列表中會有多個需求，而每個需求應當能夠用1、2句話，在20個字以內就可以描述清楚。需求列表是客戶提出的最最原始的需求，他不摻雜任何分析設計，是我們的每項功能必須實現的內容。需求列表是需求驗證以及日後的使用者驗收測試的依據，不論我們今後如何分析和設計這些功能，都要能如實地實現這個列表中提出的需求。（需求列表應當如何編寫，將在後面的章節詳細描述。）
需求整理，就是在需求研討會後，需求分析人員對研討內容的分析和整理的過程。首先，需求分析人員應當通過用例模型，劃分整個系統的功能模組，以及各個模組的業務流程。用例模型分析是一個由粗到細的過程，這樣一個過程也是符合人類認識世界的思維習慣的一個過程。最先，我們應當對整個系統繪製用例圖，設計用例場景，並依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然，在整體用例分析的同時，我們還應當進行一個整體的角色分析，繪製一個角色分析圖，進行一個流程分析，繪製一個流程分析圖（可以是傳統的流程圖、UML中的行動圖，甚至一個簡單的示意圖，等等）。
然後，我們再在整體用例圖的基礎上，依次對每個用例繪製用例圖。每個用例圖中，會更細緻地劃分出多個用例，並依次進行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細化，直到我們認為需求已經描述清楚為止。
在一個系統中，用例需要細化幾次，是由這個用例的業務複雜程度決定的。對於一個簡單的用例，只需要細化一次就夠了；而對於比較複雜的用例，則需要細化2~3次，甚至更多。
用例分析的過程，之所以稱之為分析，它摻入了很多需求分析人員對業務的理解與設計：模組如何劃分、流程如何設計、業務如何轉換，等等。用例分析，還需要讓需求分析員與架構師、設計師等技術人員共同協作來完成，因為用例分析還包含對業務需求的技術可行性分析。只有一份可行的需求分析，才能為後續的設計開發掃清障礙，有效降低專案風險。最後，需求分析員應當將需求列表中的內容，逐一地與用例進行核對，以避免分析人員忽略使用者的某項業務需求。（後面將詳細描述用例模型的搭建過程。）
在用例分析的同時，需求分析人員還需要對業務中的相關事物，製作領域模型。領域模型，是對使用者業務領域中相關事物、相互關係、相互行為操作的描述，它是以物件圖和類圖的形式表達的。需求人員對領域模型的分析，對業務理解的深度，對日後軟體的設計，以及軟體的功能擴充套件、升級演化，都起到了至關重要的作用。（後面將更加詳細地講述領域模型。）
最後，當我們完成了一系列的分析整理並形成文件以後，應當對及時地與客戶進行反饋，確認我們的理解是否正確，也就是需求驗證工作。需求驗證工作應當貫穿整個研發週期，並且在不同時期表現出不同的形式。首先，在需求分析階段，需求驗證工作表現為對需求理解是否正確的資訊反饋。需求分析人員與客戶再次坐在一起，一項一項描述我們對需求的整理和理解，客戶則時不時地對一些問題進行糾正，或者更加深入地加以描述。我們則認真地記錄，回來整理，並等待下一次的驗證。在需求分析後期，我們還可以製作一些簡單的原型，更加形象地描述我們對需求的理解，會使我們與客戶的溝通更加順暢。隨後的設計開發階段，我們則應當以迭代開發的形式進行。每開發完一個迭代週期，將開發的成果與客戶反饋。這樣做的結果是，客戶可以及時地提出我們對需求理解的偏差，或者及時提出對我們設計不滿意的地方，使我們存在的問題得到及時地發現與解決。問題及時的解決，使我們修復問題的代價得以降至最小。之後，當開發進入到驗收測試階段，我們則是與客戶一道，一項一項地驗證我們的軟體是否滿足需求列表中要求的業務需求。最後，當軟體迎來下一次升級開發時，我們將開啟另一次輪迴。
因此，需求分析就是按照這樣的過程，每次多理解一些，再多理解一些，更多理解一些，逐漸深入的過程。每深入一步，我們的軟體就更接近客戶的滿意。