【原創】需求分析之用例規模

需求分析，看似簡單，拿到需求後卻不知如何下手，如何編寫用例 ？ 是否需要時序圖？ 如何表示業務流程或者系統處理流程？ 太多的疑問在頭上環繞 ，今天我們試著著手做需求分析的第一步--用例分析。

其實需求分析不能僅僅去了解客戶對系統的要求，我們需要站在客戶的角度，客戶所處的環境整體把握需求內容。

客戶的目的

 客戶究竟想幹什麼。我們不要先考慮系統將來怎麼做，我們首先要考慮客戶要幹什麼？客戶的目的是什麼？有哪些必要需求，哪些緊急需求？ 按客戶要求的重點分別討論每一個場景。

呵呵，終於開始考慮編寫用例了，不用急 ，用例到底應該編寫到何種程度才能達到我們的目的，才能知道我們應該怎麼做？ 我們可以從以下角度考慮問題。（用例的編寫方法我們就不做討論了，很多書上都有的）

1、老闆的角度

 拿到原始需求後，我們怎麼彙報才能讓老闆明白我們在做什麼呢？ 其實這個彙報有一定難度，我們要充分了解客戶的需求，並概括為IT、業務都聽的懂的專用術語，簡單，突出重點的完成彙報。這就是我們要做的第一個用例，比如接到CIF系統需求，我們首先就要明確，誰，要做什麼，簡單扼要的回答就是，客戶管理部提出客戶資訊管理系統。over ！如果我們回答：客戶管理部**處需要客戶資訊查詢、檢索、維護等功能，還需要有。。。。 老闆估計沒心思聽這些 。至於客戶管理部有哪些要求，我們需要提供哪些功能，我們客戶一點點的完善。

 

2、業務的角度

  從業務角度編寫用例就得充分了解需求的背景，比如：**國家監管部門要求**行業需要通過系統處理費用資訊，不允許公司出納接手任何現金。 這些背景我們也需要重點關注，避免出現由於客戶理解偏差導致系統需求偏差，需要提醒的是，發現問題一定要與客戶討論、確認問題，萬不可私自篡改需求內容 。

說了一大推廢話，用例該怎麼編寫還沒說呢，其實以上內容是讓需求分析員充分了解客戶在沒有系統支援的情況下業務的處理流程，系統雖然會優化業務的處理流程，但是也是要給予原業務流程，可不能犯了唯心主義錯誤。

這時候我們就可以明細業務的用例場景，按業務流程劃分，什麼角色、什麼時間、幹什麼時 ，為主場景分析 。遇到什麼問題、應該如何處理 ，為替代場景 。但這裡需要注意的是，一定要分清楚哪些是我們重點需要分析的，哪些是第三方可以提供的服務，切不可喧賓奪主。

用例的編寫重點要放在通過語言描述，理清各種場景的業務流程、業務功能，設定清晰的前置條件，後置條件，UML圖可作為協助解釋---圖形可以讓人更容易理解你的想法，特別是在做問題、流程梳理過程中，圖形會帶來意想不到的效果 。以上內容出爐後，結果是讓業務很清晰的告知你，業務需要的就是你所描述的，也讓模組負責人清晰的告訴你，他明白需求的關鍵點了。

以上所指的uml圖形，指用例圖、職責流程圖、業務序列圖等，重點是業務描述

 

3、IT的角度

     從IT的角度，不光要理解業務的功能點，我們需要知道準備要怎麼做，第二點我們只是對業務的流程和功能做了梳理，系統需要怎樣解決我們還不清楚，所以我們要搞清楚這點 。

  對應業務的用例分析，我們要有系統功能用例描述、系統職責流程、類描述、類關係描述、類序列描述、資料結構。 以上內容只表達一個目的----系統如何處理？

 這裡需要提醒的一點是，對於專案中的技術難點、技術風險都需要做好防範及預先處理準備。

 

以上只是常規的需求分析過程，對於面對不同的業務部門，不同性格的業務人員，我們需要靈活掌握，我們的目的就是做好分析，做好系統。

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7389553/viewspace-625020/，如需轉載，請註明出處，否則將追究法律責任。