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

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

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

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

發現和定義涉眾

畫定業務邊界

擷取用例

繪製用例情境圖

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

編製詞彙表

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

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

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

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

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

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

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

業主

業主是系統建設的出資方，投資者，它不一定是業務方。比如可以假設這個圖書館的網路化建設是由一家國際風險投資機構投資的，它本身並不管理圖書館，它只是從資本上擁有這個系統並從借書收入中獲得回報。
瞭解業主的期望是必須和重要的，業主的錢是這個項目存在的原因。若系統建設不符合業主的期望，撤回投資，那麼再好的願望也是空的。
一般來說，業主關心的是建設成本，建設周期以及建成後的效益。雖然這些看上去與系統需求沒什麼大的關係，但是，建設成本、建設周期將直接影響到你可以採用的技術，可以選用的軟體架構，可以承受的系統範圍。一個不能達到業主成本和周期要求的項目是一個失敗的項目，同樣，一個達到了業主成本和周期要求，但卻沒有賺到錢的項目仍然是一個失敗的項目。

業務提出者

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

業務管理者

業務管理者是指實際管理和監督業務執行的人員，一般是指中層幹部，起到將業務提出者的意志付諸實施，並監督底層員工工作的作用。他們的期望也很重要，一般也是系統的主要使用者之一。他們關心系統將如何?他們的管理職能，如何能方便的得知業務執行的結果，他們如何將指令下達，以及如何得到反饋。業務管理者的期望相對比較細節，是需求調研過程中最重要的資訊來源。系統建設的好壞與業務管理者的關係最多，也是系統分析員最需要下功夫的。系統分析員必須要把業務管理者的思路，想法弄清楚，業務建模的結果也必須與業務管理者達成一致。在系統建設過程中，業務管理者的期望可以有所妥協，一個經驗豐富的系統分析員可以給他們灌輸合理的管理方式，提供可替代的管理方法，以規避導致高技術風險或高成本風險的不合理要求。

業務執行者

業務執行者是指底層的操作人員，是與將來的電腦直接互動最多的人員。他們最關心的內容是系統會給他們帶來什麼樣的方便，會怎樣的改變他們的工作模式。他們的需求最細節，系統的可用性，友好性，運行效率與他們關係最多。系統介面風格，操作方式，資料展現方式，錄入方式，業務細節都需要從他們這裡瞭解。他們將成為系統是否成功的試金石。Look and Feel ，表單細節等是系統分析員與他們調研時需要多下功夫的地方。這類人員的期望靈活性最大，也最容易說服和妥協。同時，他們的期望又往往是不統一的，各種古怪的要求都有。他們的期望必須服從業務管理者的期望，因此，系統分析員需要從他們的各種期望中找出普遍意義，解決大部分人的問題，必要時可以依靠業務管理者來影響和消除不合理的期望。

第三方

第三方是指與這項業務而關聯的，但並非業務方的其他人或事。比如在這個案例中，借閱人借書時需要交費，若交費是通過網上銀行支付的，則網上銀行就成為了網上借書系統的一個涉眾。
第三方的期望對系統來說不起決定性意義，但會起到限制作用。最終在系統中，這種期望將體現為標準、協議和介面。
另一種典型的第三方是項目監理，系統分析員也必須弄清楚監理的期望。

承建方

承建方，也就是你的老闆。老闆的期望也是非常重要的。老闆關心的是通過這個項目，能否賺到錢，是否能積累核心競爭力，是否能樹立品牌，是否能開拓市場。老闆的期望將很大的影響一個項目的運作模式，技術選擇，架構建立和範圍確定。比如，老闆試圖通過這個項目開啟一個市場，樹立起品牌，不惜成本，那麼，系統分析員需要儘可能的深入挖掘潛在業務，建立擴充能力很強，但成本較高的業務架構，選擇那些較新，但風險較高的技術。反之，如果老闆只想通過這個項目賺更多的錢，系統分析員就需要引導業務方壓縮業務範圍，選擇風險小的成熟技術，甚至不用考慮業務架構，考慮系統的可維護性，而較少考慮系統擴充能力。
一個業主滿意但老闆不滿意的項目，恐怕也不是一個成功的項目吧？

相關的法律法規

相關的法律法規是一個很重要的，但也最容易被忽視的涉眾。這裡的法律法規，既指國家和地方法律法規，也指行業規範和標準。例如，這個借閱系統中要建立借閱人檔案，就必須保障借閱人的隱私權；要與網上銀行交易，必須遵守資訊安全法等。若遇到業務方提出違反了法律法規的要求時，系統分析員要能給他們指出來，說服無果的情況下要在合約裡留下免責條款。否則一不小心惹上官司可是件鬱悶的事。
另外，有時必須得遵守一些行業規範。例如本案例是網上借閱，網路需求決定了需要遵守HTML規範，才能保證借閱者能正常瀏覽網頁。

使用者

使用者是一個抽象的概念，是指預期的系統使用者。使用者可能包括上述的任何一種涉眾。使用者涉眾模型建立的意義是，每一個使用者將來都可能是系統中的一個角色，是實實在在參與系統的，需要編程實現。而上述的其它涉眾，則有可能只是在需求階段有用，最終並不與系統發生互動。在建模過程中，概念性模型的建立和系統模型的建立都只從使用者開始分析，而不再理會其它的涉眾。在Rose中建模的時候，也只需要建立使用者的模型，其它涉眾則只需要體現在文檔中即可。

這篇文章只能到此為止了，否則太長的話，讀者該不耐煩了。只好在此分節。下一節筆者將一步步將涉眾的期望匯出，並得到需求範圍的大致輪廓。