OO系統分析員之路--用例分析系列（3）--業務建模之涉眾

從這一篇開始，筆者將藉助一個虛擬執行個體來闡述擷取用例的方法，以及如何判斷用例擷取是否完備，粒度選擇是否合適。事實上，在做這些工作時，我們進行中需求分析的第一個階段，即業務建模階段。藉助這個例子，筆者同樣會闡述業務建模到底應該做什麼，做到什麼地步才能說明業務需求已經完整，可以稱為一份完整的需求規格說明書了。

一般來說，只有當以下工作都完成，才能說業務模型建立完成，它們是：

發現和定義涉眾

畫定業務邊界

擷取用例

繪製用例情境圖

繪製業務實體模型（領域模型）

編製詞彙表

下面筆者開始就一個案例來說明如何完成這些工作，這隻是一個虛擬案例，它的合理性和真實性請讀者不必追究。

現在我們接到一個項目，是一個網上圖書借閱系統，初步跟客戶接觸，網上圖書館的業務負責人這樣告訴我：

我們原本是一個傳統的圖書館，傳統的借書方式要求讀者親自來到圖書館，這顯得非常不方便，而且隨著藏書的增加和讀者群的增長，尤其而且大量的讀者到圖書館，使得圖書館的場地不足，工作人員也不夠了。所以想到藉助網路，讓讀者通過網路借/還書，這樣可以省掉大量的場地維護和工作人員成本支出，同時電腦可以方便的檢索目錄，讓讀者可以足不出戶借到需要的書。為了把書送到借閱人手裡，我們已經聯絡了A特快專遞公司和B城市物流公司，初步達成協議，由他們往返借閱人和圖書館之間把圖書送出和收回。讀者在網上出示和驗證借書卡，找到他們需要的書，提交申請，圖書管理員確認後，就會通知物流公司來取書，當讀者拿到書之後，物流公司需要把讀者的簽單拿回來以證明讀者已經拿到了書。當然這個過程中，讀者是需要付費的。還書也是基本同樣的過程。

好了，通過這番談話，我們已經基本上瞭解了系統目標。一些著急的系統分析員已經準備開始著手詢問借書的流程，借閱人的資格認證問題了，甚至有的人已經憑藉多年的開發經驗在腦海中繪製出了一幅網頁，考慮如何?這個系統了。

筆者要說的是，請您千萬不要著急往下走。因為我們得到的僅僅是一個由非電腦專業人員規划出的很粗略的構想，其可行性如何都尚未得到證實，在這樣的基礎下就開始細化，將來出現反覆甚至失敗的危險是很大的。

在瞭解了系統目標以後，系統分析員最先要做的事情不是去瞭解業務的細節，而是去發現與這個目標相關的人和物。英文把這種人和物稱為Stakeholder，在Rose中，這類模型的類型被定義為Business Actor 。有的資料翻譯為干係人，筆者則更喜歡涉眾這種翻譯方法。這就談到了業務建模的第一步：發現和定義涉眾。

什麼是涉眾？涉眾是與要建設的業務系統相關的一切人和事。首先要明確的一點是，涉眾不等於使用者，通常意思的user是指系統的使用者，這僅是涉眾中的一部分。如何理解與業務系統相關的一切人和事？筆者可以給大家分享的經驗是通過以下大類去尋找：

業主

業主是系統建設的出資方，投資者，它不一定是業務方。比如可以假設這個圖書館的網路化建設是由一家國際風險投資機構投資的，它本身並不管理圖書館，它只是從資本上擁有這個系統並從借書收入中獲得回報。

瞭解業主的期望是必須和重要的，業主的錢是這個項目存在的原因。若系統建設不符合業主的期望，撤回投資，那麼再好的願望也是空的。

一般來說，業主關心的是建設成本，建設周期以及建成後的效益。雖然這些看上去與系統需求沒什麼大的關係，但是，建設成本、建設周期將直接影響到你可以採用的技術，可以選用的軟體架構，可以承受的系統範圍。一個不能達到業主成本和周期要求的項目是一個失敗的項目，同樣，一個達到了業主成本和周期要求，但卻沒有賺到錢的項目仍然是一個失敗的項目。

業務提出者

業務提出者是商務規則的制定者，一般是指業務方的高層人物，比如CEO，資深經理等。他們制定商務規則，圈定業務範圍，規劃營運目標。他們的期望十分十分的重要，實際上，系統建設正是業務提出者經營和管理意志的體現。他們的期望一般比較原則化和粗略化，但是卻不能違反和誤解，否則系統將有徹底失敗的危險。業務提出者一般最關心系統建設能夠帶來的社會影響，效率改進和成本節約。換句話說，他們只關心統計意義而不關心具體細節，但是，如果建設完成的系統不能給出他們滿意的統計結果，這必定是一個失敗的項目。在系統建設過程的溝通中，他們的意志一般是極少妥協的，系統分析員不必太費心去試圖說服他們接受一個與他們意志相左的方案。實際上，由於他們的期望是非常原則化和粗略的，因此留給了系統建設者很大的調整空間和規避風險的餘地。