首先是業務用例實現檢視。並非所有的業務用例都一定要最終在系統中實現，因此，這個檢視的含義是表達由需求範圍到系統範圍的對映關係。這個檢視沒什麼技巧，也可以省略，不過筆者建議不要省略。需求應當保持過程的連續和可追溯性，這是軟體過程可控的重要保證。
業務用例實現檢視：
看不清楚？這裡檢視原圖（大圖）。
應當在業務用例實現裡新增活**用以描述用例場景，下圖為示例，用活**繪製。如果有多個場景，則應當繪製多個場景圖。
業務用例場景(借書過程)：
看不清楚？這裡檢視原圖（大圖）。
用例場景有另乙個重要意義，是幫助系統分析員發現和定義業務實體。業務實體一般來說就是調研時使用者所提供的各類表單或報表，但在很多情況下，並非每乙份表單就是乙個業務實體，所有業務表單也不一定涵蓋全了所有業務實體。很多系統分析員聲稱業務實體的發現過程是全憑經驗的，到底有哪些業務實體，靠經驗進行提取。筆者要說，經驗固然重要，但經驗有乙個最大的缺陷---不能重複和驗證。即，這些實體是怎麼從業務中提取出來的？它們是怎樣參與業務的？這些實體已經足夠支援業務了嗎？憑經驗分析者無法通過文件將這個提取過程記錄下來，而腦子裡的東西是無法共享和傳承的，越大的團隊，越複雜的專案，尤其是橫向結構的專案組結構下，這個缺陷越嚴重。很多人覺得用uml和rup描述的需求總是一塊塊分離的，不知道是怎麼出來的，覺得很亂，原因就在於此。實際上，rup做需求，每一步都是可驗證和回溯的。用例實現檢視是乙個例子，這裡也是乙個例子。
讓我們看看上面的業務場景檢視，每乙個活動都有類似的命名：出示借閱證、查詢需要的圖書、放入借書欄.....看出什麼來了嗎？每個活動都是乙個動作加上乙個動作的受體。受體正是我們要尋找的業務實體，這些名詞就是實體的**。在需求階段，系統分析員不要去考慮什麼抽象，什麼模式，別急，那是系統模型做的事情。抽象了，還弄一堆什麼factory模式，builder模式之類的出來，使用者能看懂嗎？別忘了我們正在做的是需求文件，是做給使用者看的。
觀察上面的用例場景，分析出現的名詞，我們得到乙個個業務實體，再根據場景分析這些業務實體之間的關係。實際上就是大家都熟悉的er模型，但是與資料庫建模的視角還是有所差別的。資料庫er模型要受到資料關係正規化的限制，而業務實體er模型則不必理會這種限制。只要與現實物體符合就ok。好了，羅嗦了一大堆，我們終於得到了我們的成果。
借閱圖書過程業務實體檢視：
看不清楚？這裡檢視原圖（大圖）。
上圖中畫那麼多虛線連線到業務用例實現是用來表示業務實體與業務用例實現之間的追溯關係的，這些線雖然麻煩，但是筆者強烈建議不要圖省事。因為業務實體通過它們可以追溯到原始需求，再次重申，軟體過程要可控，需求可追溯是需要時時謹記的。當然，如果嫌麻煩，您也可以用下面的這種形式，是不是簡潔得多呢？
經過以上的過程，我們得到了什麼呢？往下看之前筆者建議您回想一下，總結一下。
第一、我們通用用例實現檢視，從業務用例中找出了那些我們將在系統中實現的用例，並且記錄了要在系統中實現的用例是如何對映到原始需求的。這提供了需求可追溯的驗證。
第二、針對每個用例實現，我們引入了計算機，將實際的業務從人-機互動的角度模擬了執行過程。不僅得到了乙個業務怎樣在計算機環境下執行的概念模型，同時也給使用者描述了他們將怎麼和計算機互動以達到他們的目標。筆者提醒大家，用例場景非常非常的重要，後續工作就得靠它們了！！絕對要認真對待，深入調研，不可漏掉乙個場景，也不可模糊不清。
第三、通過對場景的分析，給了我們重要的線索去發現業務實體。而我們發現了業務實體之後，又通過用例場景來驗證這些實體是否支援了用例的實現。
現在請讀者思考一下，如果記不清了，可以翻翻之前的文章。到現在為止，我們的需求是不是一步一步推出來的？從粗到細，從模糊到清晰，從原始需求到計算機的引入，是不是每一步都是可以追溯的呢？每一步的分析結果是不是都有方法來驗證正確性和完備性呢？如果您之前迷惑於需求的各個階段無法關聯，也說不清分析結果是否是正確的，那麼建議您再從頭看看筆者目前已經完成的文章，找出這些線索來，相信您會對uml和rup的理解提高乙個層次的。
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...
UML核心模型 用例模型
學uml就是為了建模，uml的語法和詞彙已經差不多了解了。所以開始學模型了。用例模型是需求工作的結果，用例模型有業務用例模型，概念用例模型和系統用例模型。他們擁有軟體開發的不同生命週期階段，它們三者是在不同的抽象層次上的，它們之間是一種精化關係。業務用例模型 業務用例模型位於統一過程的先啟階段。從業...