OO系統分析員之路--用例分析系列（1）

--什么是用例

我發現，在OO和UML幾乎一統天下的今天，仍有很多系統分析員對OO和UML一知半解，甚至包括很多已經使用了很久UML的系統分析員。

于是打算寫一個系列文章，將多年來的工作經驗做一個總結。對初學者起個啟蒙作用，也希望拋磚引喻，與各路大蝦共同探討，共同提高。這個系列文章將以我對OO和系統分析的理解為主，從UML基礎開始，闡述面向對象的需求分析方法，過程，并以RUP為例，闡述如何將OO過程與軟件過程有機結合在一起，做一個真正OO應用。

好了，今天是第一篇。想得很遠，真希望我能堅持下去，呵呵。

用例是什么？其原始英文是usecase，直譯過來就成了用例。這也是一個比較貼切的叫法了，從字面的直接理解就是使用的例子。另一種比較流行的定義是用例就是與使用者(actor)交互的，并且給使用者提供可觀測的有意義的結果的一系列活動的集合。

這個定義還是比較費解的，筆者在眾多應聘者中發現很多使用用例來做需求的系統分析員，有的已經使用了兩年以上，但仍不能把握用例的本質，雖然他們號稱精通UML。

最具普遍意義的理解錯誤是認為用例就是功能的劃分和描述，認為一個用例就是一個功能點。在這種理解下，用例變成了僅僅是較早前需求中功能框圖的翻版，很多人用用例來劃分子系統，功能模塊和功能點。如果這樣，用例根本沒有存在的必要。有意思的是，造成這種理解錯誤的相當一部分原因卻是因為對OO思想的理解不夠深入，本質上說，把用例當成功能點的系統分析員腦子里還是面向過程的那一套思想，雖然他們在使用OO的工具，OO的語言，號稱在做面向對象的開發，但過程的影子還沒有從他們腦子里徹底抹去。

如果用例不是功能的話，它是什么呢？從定義上說，能給使用者提供一個執行結果的活動，不就是功能嗎？我的回答是：錯！功能是計算機術語，它是用來描述計算機的，而非定義需求的術語。功能實際描述的是輸入-->計算-->輸出。這讓你想到了什么？DFD圖？這可是典型的面向過程分析模式。因此我說把用例當做功能點的分析員實際在做面向過程的分析。

而用例不是計算機術語，UML除了在計算機行業中應用，它也經常被應用在其它行業中。用例是一種需求方法學，雖然軟件危機和OO的發展促成了它的誕生并被完美的融合進了OO體系，形成了 UML，但它實際上并不是軟件行業的專用品。如果非要從功能的角度解釋，那么用例可以解釋為一系列完成一個特定目標的“功能”的組合，針對不同的應用場景，這些“功能”體現不同的組合方式。實際上，把用例解釋為某個參與者(actor)要做的一件事可能更為合適。

這樣的一件事有以下幾個特征：

一、這件事是相對獨立的。這意味著它不需要與其它用例交互而獨自完成參與者的目的。也就是說這件事從“功能”上說是完備的。讀者可能會想到，用例之間不是也有關聯關系嗎？比如擴展，比如實現，比如繼承，它看上去并不是獨立的嘛。關于這個問題，筆者會在后續的文章里詳細說明。這里稍微解釋一下，用例之間的關系是分析過程的產物，而且這種關系一般的產生在概念層用例階段和系統層用例階段。對于業務用例，這個特征是很明顯的。

二、這件事的執行結果對參與者來說是可觀測的和有意義的。例如，系統會監控參與者在系統里的操作，并在參與者刪除數據之前備份。雖然它是系統的一個必需組成部分，但它在需求階段卻不應該作為用例出現。因為這是一個后臺進程，對參與者來說是不可觀測的，它應該在系統用例分析階段定義。又比如說，登錄系統是一個有效的用例，但輸入密碼卻不是。這是因為登錄系統對參與者是有意義的，這樣他可以獲得身份認證和授權，但輸入密碼卻是沒有意義的，輸入完了呢？有什么結果嗎？

三、這件事必須由一個參與者發起。不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例。用例總是由一個參與者發起，并且滿足特征二。例如從ATM 取錢是一個有效的用例，ATM吐鈔卻不是。因為ATM是不會無緣無故吐鈔的，否則，我從此天天守在ATM旁，生活無憂矣。

四、這件事必然是以動賓短語形式出現的。即，這件事必須有一個動作和動作的受體。例如，喝水是一個有效的用例，而“喝”和“水”卻不是。雖然生活常識告訴我們，在沒有水的情況下人是不會做出喝這個動作的，水也必然是喝進去的，而不是滑進去的，但是筆者所見的很多用例中類似“計算”，“統計”，“報表”，“輸出”，“錄入”之類的并不在少數。

除去以上的特征，筆者覺得用例的含義還要更深些。首先，用例的背后是一種需求方法論。其核心是以參與者為中心（區別于以計算機系統為中心），從參與者的角度來描述他要做的日常工作（區別于以業務流程描述的方式），并分析這些日常工作之間是如何交互的（區別于數據流的描述方式）。換句話說，用例分析的首要目標不是要弄清楚某項業務是如何一步一步完成的，而是要弄清楚有多少參與者？每個參與者都做什么？業務流程分析則是后續的工作了。

其次，用例簡直就是為OO而生的，其思想完美的符合OO。用例分析方法試圖找到問題領域內所有相對獨立的參與者和事件，并把業務流程當成是這些參與者和事件之間的交互結果（在UML用活動圖或序列圖來描述）。因此，用例方法被吸納到OO之后，UML得以以完備的形式出現，用例成為了真正的OO核心。在 RUP里，這種核心作用被發揮到極致，產生了用例驅動（usecase driven）的軟件過程方法，在RUP里，軟件生產的所有過程和產物都是圍繞著用例形成的。

可以說，用例分析是OO的第一步。如果用例分析本身出了問題，對業務架構，軟件架構的影響是很大的，將大大削弱OO的優勢--復用、擴展。筆者認為軟件復用可以分為三個層次，最低層次的復用是代碼級復用，這是由OO語言特性提供支持的，例如繼承，聚合，多態；較高層次的復用是組件級復用，這是由設計模式提供支持的，例如Factory模式, Builder模式；最高層次的復用則是服務級復用，這在很大程度上是由應用服務器和通訊協議來提供支持的，例如最近炒得火熱的SOA（面向服務的應用）架構。用例分析的好壞也許對代碼級和組件級的復用影響不太大，但對服務級的復用影響卻是巨大的。筆者認為服務級復用是OO的最高境界，而結構良好的用例分析則是達到這一境界的基礎。

閑話：今天你OO了嗎？

如果你的分析習慣是在調研需求時最先弄清楚有多少業務流程，先畫出業務流程圖，然后順藤摸瓜，找出業務流程中每一步驟的參與部門或崗位，弄清楚在這一步參與者所做的事情和填寫表單的結果，并關心用戶是如何把這份表單傳給到下一個環節的。那么很不幸，你還在做面向過程的事情。

如果你的分析習慣是在調研需求時最先弄清楚有多少部門，多少崗位，然后找到每一個崗位的業務代表，問他們類似的問題：你平時都做什么？這件事是誰交辦的？做完了你需要通知或傳達給誰嗎？做這件事情你都需要填寫些什么表格嗎？....那么恭喜你，你已經OO啦！

OO系統分析員之路--用例分析系列（2）

--用例的類型與粒度

在正式討論如何獲取用例之前，筆者覺得有兩個問題還是先解釋清楚為好，這對正確獲取用例有很大幫助。這兩個問題也是初學者最為困惑，也是最難掌握的。一個是各種用例類型之間的區別和用法，另一個是用例的粒度。

先說說用例類型的問題。

用例類型，有的資料翻譯為版型，英文原文是stereotype。在Rose中默認的類型有business usecase , business usecase realization和use case realization三種。相應的，就是指

業務用例：

業務用例實現：

用例實現：

若不指定類型，則它就是通常意義上的use case ：

Rose中定義了上述默認類型，但是也可以自定義用例類型。初學用UML建模的人常常在這些類型中迷失，搞不清楚這些類型是什么含義，什么時候該使用什么類型。簡單說，需求分析中的各個階段要描述和分析的目標不同，為表達不同的視角和分析目標，需要使用不同的用例類型。筆者的觀點是，用例類型的區分是為了形式上的統一，但用例類型既然可以自定義，它就是一個很靈活的用法，不必墨守成規，大可在工作中根據實際情況定義適合自己項目特點和軟件過程的用例類型。不過，默認的用例類型已經幾乎可以滿足需求分析的各個階段，自定義的必要性并不大，并且UML的意義就是使用統一的形式描述需求，因此最好使用默認的類型。

說到需求分析階段，那么需求分析都有些什么階段呢？一般來說，需求分析要經過業務建模，用例分析和系統建模三個階段才能完成需求工作，這三個階段分別做什么筆者會在以后的文章的詳細闡述，這里為了說明用例類型的含義和使用，先簡單介紹一下。

1、業務建模的目標是通過用例模型的建立來描述用戶需求，需求規格說明書通常在這個階段產生。這個階段通常使用業務用例和業務用例實現兩種類型；

2、用例分析是系統分析員采用OO方法來分析業務用例的過程，這個階段又稱為概念模型階段。這個階段通常使用無類型的用例。用例分析是一個過渡過程，但筆者認為其非常重要，業務架構通常在這個階段產生。

3、系統建模是將用戶的業務需求轉化為計算機實現的過程。這個階段通常使用無類型的用例和用例實現兩種類型。系統范圍，項目計劃，系統架構通常在這個階段形成雛形（在系統分析階段確定）。

所謂business usecase，是用來描述用戶原始需求的，它的含義是站在用戶的角度，使用用戶的業務術語來描述用戶在其業務領域所做的事情。業務用例命名，描述都必須采用純業務語言，而不能出現計算機術語。因為業務模型是系統分析員與用戶討論需求，達到一致理解的基礎，必須使用用戶熟悉的，不會有歧義的專業術語以避免系統分析員與用戶對同一事件的理解誤差。business usecase realization是達到需求可追溯要求的一個連接點，是用戶在其業務場景中如何做這一件事的載體。

筆者自己在用例分析和系統建模階段不區分用例類型，都使用無類型的use case，但在這兩個階段，用例的含義還是有所差別的。用例分析階段，用例主要是從 業務模擬的概念上，從OO的視角來分解、組合業務用例，粗略的建立一個業務架構。而在系統建模階段，用例主要是從計算機視角描述需求，規定開發范圍，作為項目計劃的依據，為系統設計做準備。usecase realization的含義可從business use case realization推知。

再來說說用例的粒度問題。

粒度是令人迷惑的。比如在ATM取錢的場景中，取錢，讀卡，驗證賬號，打印回執單等都是可能的用例，顯然，取錢包含了后續的其它用例，取錢粒度更大一些，其它用例的粒度則要小一些。到底是一個大的用例合適還是分解成多個小用例合適呢？這個問題并沒有一個標準的規則，筆者可以給大家分享的經驗是根據階段不同，使用不同的粒度。在業務建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜。即一個用例可以描述一項完整的業務流程。這將有助于明確需求范圍。例如取錢，報裝電話，借書等表達完整業務的用例，而不要細到驗證密碼，填寫申請單，查找書目等業務中的一個步驟。在用例分析階段，用例的的粒度以每個用例能描述一個完整的事件流為宜。可理解為一個用例描述一項完整業務中的一個步驟。需要注意的是，這個階段需要采用OO方法，歸納，抽象業務用例中的概念模型。例如，寬帶業務需求中有申請報裝，申請遷移地址用例，在用例分析時，可歸納和分解為提供申請資料，受理業務，現場安裝等多個業務流程中都會使用的概念用例。在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個用例能夠描述操作者與計算機的一次完整交互為宜。例如，填寫申請單，審核申請單，派發任務單等。可理解為一個操作界面，或一個頁面流。在RUP中，項目計劃要依據系統模型編寫，因此另一個可參考的粒度是一個用例的開發工作量在一周左右為宜。

上述的粒度劃分方法筆者是用相對比較具體化的一些依據來說明。實際上，用例粒度的劃分依據（尤其是業務用例）最標準的方法是一個用例的粒度是否合適，是以該用例是否完成了參與者的某個目的為依據的。這個說法比較籠統，也比較難以掌握。，舉個例子，某人去圖書館，查詢了書目，出示了借書證，圖書管理員查詢了該人以前借閱記錄以確保沒有未歸還的書，最后借到了書。從這段話中能得出多少用例呢？請記住一點，用例分析是以參與者為中心的，因此用例的粒度以能完成參與者目的為依據。這樣，實際上適合用例是：借書。只有一個，其它都只是完成這個目的過程--這里討論的用例指的是業務用例--這個例子是比較明顯的能夠區分出參與者完整目的的，在很多情況下可能并沒有那么明顯，甚至會有沖突。讀者可以從自己實際的情況去找出這種例子。以后的文章中筆者會做一些討論。

但是上述的粒度選擇并不是一個標準，只是在大多數情況下這樣的粒度選擇是比較合適的。筆者的意思也不是告訴讀者上述哪一種是最好的，而只是把一些常用的比較，劃分方法告訴讀者，期望的是幫助讀者在工作實踐中自己總結出一套適合自己的方法來。現實情況中，一個大型系統和一個很小的系統用例粒度選擇會有較大差異。這種差異是為了適應不同的需求范圍。比如， 針對一個50人年的大型項目應該選擇更大的粒度，如果用例粒度選擇過小，可能出現上百甚至幾百個業務用例，造成的后果是需求因為過于細碎和太多而無法控制，較少的用例有助于把握需求范圍，不容易遺漏。而針對一個10人月的小項目應該選擇小一些的粒度，如果用例粒度選擇過大，可能只有幾個業務用例，造成的后果是需求因為過于模糊而容易忽略細節。一般來說，一個系統的業務用例定義在多于10個，少于50個之間，否則就應該考慮一下粒度選擇是否合適了。

不論粒度如何選擇，必須把握的原則是在同一個需求階段，所有用例的粒度應該是同一個量級的。這應該很好理解，在描述一棟建筑時，我們總是把高度，層數，單元數等合在一起介紹，而把下水道位置，插座數量等合在一起介紹。如果你這樣介紹一棟樓：這棟樓有10層，下水道在廚房東南角，預留了15個插座，共有5個單元，聽眾一定會覺得云山霧罩，很難在腦子里形成一個清晰的影像。

如果對上面兩個問題讀者還有疑惑，不用著急，在以后的文章中應該會逐步加深理解。

預告：下一篇文章將通過一個例子，闡述獲取用例的一般方法和如何判斷用例的粒度是否合適。

Q&A

--------------------------------------------------------------------------

Q：由 pushboy 發布
在業務建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜。即一個用例可以描述一項完整的業務流程。"
"在系統建模階段，用例視角是針對計算機的，因此用例的粒度以一個用例能夠描述操作者與計算機的一次完整交互為宜。"
那么，這樣一個場景 —— 用戶管理，有增刪改查
這里，是把 用戶管理 作為一個用例，還是把增刪改查分別作為用例呢？
他們每一個都是一個完整的業務流程和一次完整交互，而且也都是一個actor發起的動作；怎么來確認呢？
我們的前提是一個普通的比如說財務系統，而不是一個用戶管理系統

A：這個問題很好，用例的粒度總是在這樣左也可右也可之間難以決定。對這個問題來說，我的觀點是業務用例應當用“管理用戶”或“維護用戶”作為合適的粒度，而增，刪，改，查則在作為系統用例。我的理由是：
增刪改查不能做為一個完整的業務來理解。作為一個管理業務，數據只有先增，才會有改，才會有刪。增刪改查結合起來才能完成actor的管理目的，只刪或只增加都不是業務的全部。是否是一項完整業務，要看actor的目標，而不是事情是否完整。這個例子中，actor的目標是為了增加一個用戶嗎？是為了刪除一個用戶嗎？都不是，而是為了管理用戶，這個目標包括了用戶這個實體的整個生命周期。

再討論深一些，如果業務要求對用戶除了增刪改查，還有別的要求，例如權限升級，用戶在組織機構中復雜的關系變更，用戶與外部系統的交互....實際的情況可能會更多，那么，如果將每個都作為一個業務用例，很容易造成一個結果，這些原本與用戶這個實體緊密關聯，共同組成用戶實體生命周期的業務，被割裂成多個獨立的業務，因為定義了多個用例（請參看本人第一篇中的用例特征第一條）。要知道，在RUP中，用例驅動的含義是，一個用例就是一個分析單元，設計單元，開發單元，測試單元甚至部署單元。相信讀者都知道，把緊密關聯的業務分成多個獨立部分去實施是高成本的，高風險的。

另外，為什么我要說在系統用例階段要把增，刪，改，查又分出來呢？原因在于，系統用例的目的是為了將actor的業務用計算機模擬出來。我們都知道，一般情況下，增，刪，改，查對一個actor來說是不會同時發生的，每次actor只會完成其中的一個行為。分開來，有利于詳細分析模擬這一行為的細節而不至于混淆。另一方面，對WEB應用來說，針對數據的增，刪，改，查等，很容易形成所謂的“模板”，增加用戶用這個模板，增加其它基礎數據可能也用同一個模板，無非是操作的數據（實體）不同而已。因此，在很多情況下，這些模板是可以復用的。對這個例子來說，在系統用例階段，我們可以用“管理用戶” include “增加用戶”來表示這個實現關系，同時，讓“增加用戶”，“增加XX數據”等等用例來繼承自一個抽象出來的“增加數據”用例，這樣，可復用的模板體現在“增加數據”用例上，而具體業務，則體現在“增加XX數據”上。實際上，這也是一種OO思想的體現。

只有一個查詢是比較特殊的，查詢一般不一定只局限于一個actor，也不一定局限這個用例，一般都是所謂的綜合查詢，是可能跨用例的。所以根據實際情況，查詢可以作為一個業務用例出現。

OO系統分析員之路--用例分析系列（3）--業務建模之涉眾2008-12-10 15:27從這一篇開始，筆者將借助一個虛擬的實例來闡述獲取用例的方法，以及如何判斷用例獲取是否完備，粒度選擇是否合適。事實上，在做這些工作時，我們正在進行需求分析的第一個階段，即業務建模階段。借助這個例子，筆者同樣會闡述業務建模到底應該做什么，做到什么地步才能說明業務需求已經完整，可以稱為一份完整的需求規格說明書了。 一般來說，只有當以下工作都完成，才能說業務模型建立完成，它們是：

發現和定義涉眾

畫定業務邊界

獲取用例

繪制用例場景圖

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

編制詞匯表

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

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

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

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

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

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

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

業主

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

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

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

業務提出者

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

業務管理者

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

業務執行者

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

第三方

第三方是指與這項業務而關聯的，但并非業務方的其他人或事。比如在這個事例中，借閱人借書時需要交費，若交費是通過網上銀行支付的，則網上銀行就成為了網上借書系統的一個涉眾。

第三方的期望對系統來說不起決定性意義，但會起到限制作用。最終在系統中，這種期望將體現為標準、協議和接口。

另一種典型的第三方是項目監理，系統分析員也必須弄清楚監理的期望。

承建方

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

一個業主滿意但老板不滿意的項目，恐怕也不是一個成功的項目吧？

相關的法律法規

相關的法律法規是一個很重要的，但也最容易被忽視的涉眾。這里的法律法規，既指國家和地方法律法規，也指行業規范和標準。例如，這個借閱系統中要建立借閱人檔案，就必須保障借閱人的隱私權；要與網上銀行交易，必須遵守信息安全法等。若遇到業務方提出違反了法律法規的要求時，系統分析員要能給他們指出來，說服無果的情況下要在合同里留下免責條款。否則一不小心惹上官司可是件郁悶的事。

另外，有時必須得遵守一些行業規范。例如本事例是網上借閱，網絡需求決定了需要遵守HTML規范，才能保證借閱者能正常瀏覽網頁。

用戶

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

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

未完待續.......