中科永聯(lián)高級技術(shù)培訓(xùn)中心（www.）

      Use Case（用例）是一個UML中非常重要的概念，在使用UML的整個軟件開發(fā)過程中，Use Case處于一個中心地位。           
 
      那么，到底什么是Use Case呢？在UML的文檔中，Use Case的定義是：在不展現(xiàn)一個系統(tǒng)或子系統(tǒng)內(nèi)部結(jié)構(gòu)的情況下，對系統(tǒng)或子系統(tǒng)的某個連貫的功能單元的定義和描述。有點拗口，對吧？其實Use Case就是對系統(tǒng)功能的描述而已，不過一個Use Case描述的是整個系統(tǒng)功能的一部分，這一部分一定要是在邏輯上相對完整的功能流程。（唔？Use Case也沒什么特別的嘛！怎么這玩意兒會在開發(fā)中處于一個中心地位呢？）在使用UML的開發(fā)過程中，需求是用Use Case來表達的，界面是在Use Case的輔助下設(shè)計的，很多類是根據(jù)Use Case來發(fā)現(xiàn)的，測試實例是根據(jù)Use Case來生成的，包括整個開發(fā)的管理和任務(wù)分配，也是依據(jù)Use Case來組織的。啊，Use Case，簡直太重要了！好了，Use Case就吹到這兒，具體的使用還要在實踐中去體會，“運用之妙，存乎一心” 也！          
                                                                
      對于每個Actor來說，他都要使用系統(tǒng)的某項功能，所以我們識別和分析Use Case是，要 對于每個Actor來逐個進行。對于ToDo User，我們可以輕易的識別出兩個Use Case：Add Task 和 Remove Task。ToDo User主動使用這兩個Use Case所描述的系統(tǒng)功能，所以在我們的Use Case圖上，ToDo User和這兩個Use Case的關(guān)系是用從ToDo User發(fā)出的箭來表示的。對于FileSystem，我們識別出的也是同樣的兩個Use Case，不過這次箭頭從Use Case指向FileSystem，表示FileSystem是被動的。                             

      Use Case可以用很多方式來描述，我們可以用自然語言（英語，漢語，隨您的便），可以用形式化語言（哇！太酷了吧！），也可以用各種圖示。在UML中，通常用兩種圖來描述Use Case，它們就是順序圖（Sequence Diagram）和協(xié)作圖（Collaboration Diagram）                   

      Use Case 由以下元素組成：
　　　　名稱
　　　　簡單描述
　　　　事件流
　　　　關(guān)系
　　　　活動圖和狀態(tài)圖
　　　　Use Case 圖
　　　　特殊需求
　　　　前條件
　　　　后條件

一、談?wù)剬se case有關(guān)術(shù)語翻譯的看法。

      筆者認為“用例”是目前較好的譯法，這個詞可能來源于大家熟知的“測試用例”。有人認為把use case翻譯成“用例”是錯誤的，理由是：“‘例’是被列舉出來以說明某種情況的個別事物，use case是對一項系統(tǒng)功能使用情況的普遍適應(yīng)的描述，而不是對個別actor或者在個別條件下使用這項功能才適應(yīng)，它也不是通過舉例的方式來描述的”，所以不能叫作“用例”。此種說法不盡全面,而且有些牽強（先不管它正確與否），其實use case到底是個別的，還是群體的（普遍適應(yīng)），取決于我們的視點。雖然對于單個的scenario來說，use case是多個情節(jié)的疊加，是一個整體的復(fù)合概念，但是我們知道，一個系統(tǒng)的功能必定是可數(shù)的、有限的，而每一個功能都可以表示為一個use case，所以在觀察系統(tǒng)提供的所有功能需求的集合這個層面上，use case又是一個一個可數(shù)的個體（“橢圓”），每一個都代表了不同的用戶目標，適用于個別的actor和個別特定的前置條件。同一個事物既是個體的又是整體的，這種現(xiàn)象并不足怪，例如在UML對象-類-類元關(guān)系中，通常對象是類的實例，而類又是類元的實例，對類元來說，類、接口、子系統(tǒng)、use case等等就是一個個個體的概念，類既是其對象實例的集合又是其類元集合的個別元素?？梢?，把use case的“case”譯成“例”并沒有錯。

      有的地方把use case翻譯成“用況”，即“使用的情況”之意，意思的確不錯（use case的另一種說法是“使用的方式”）！可我總感覺這個詞比較突兀、拗口，類似的還有“用案”，把scenario叫作“案況”，大概這些詞讀起來不太符合大家的習(xí)慣（類似地，既然可以叫“用況”，為什么不能叫“用情”呢？），所以現(xiàn)在“用例”的叫法還是越來越多了。

      其實“用例”這個譯法還有個附帶的好處，通過它我們很容易把原本就存在緊密聯(lián)系的use case和test case（test case來自于對scenario的分析，而scenario是用例的一次執(zhí)行）從中文名稱上也方便地統(tǒng)一起來。不過，這里我們需要做一個小小的改進。中文的“測試用例”到底是指test case（帶定語的名詞詞組）呢，還是指對用例進行測試（testing the use cases，動賓詞組）呢？顯然這兩者不易分辨，而且若“用例”和“測試用例”兩個詞同時出現(xiàn)在一啰個句子或一段話中，常常會讓人感覺嗦和便扭。為了消除歧義，干脆以后把test case都叫做“測例”，這樣不但比以前的叫法更加簡潔明了，而且無論字面上還是語義上都很貼切。當(dāng)然，用例和測例是不同層面的“例”。

      現(xiàn)在市面上Actor也有多種譯法，常見的包括“參與者、執(zhí)行者、主角”等等。“參與者、執(zhí)行者”的問題主要是不準確。首先，“參與者” 通常讓大家馬上想到的詞是participant，而且請注意，一個用例的真正參與者決不是只有外部的Actor，它們必然還包括系統(tǒng)本身及其內(nèi)部的各種元素。“執(zhí)行者”的問題與此類似：一個用例的真正執(zhí)行者應(yīng)該是系統(tǒng)本身！因此嚴格地講這樣譯是錯誤的，興許叫作“外部參與者”、“外部執(zhí)行者”才更為恰當(dāng)。“主角”的譯法同樣存在著矛盾。如果把Actor叫作“主角”，那么Primary Actor就應(yīng)該叫作“主主角”了?？磥鞟ctor的譯法中是不能含有“主”的，那么就剩下“角”了，而UML已經(jīng)有了一個專門術(shù)語role（角色），我們又不能把Actor直接叫作“角色”。
目前看來，把Actor意譯成“使用者”是比較妥當(dāng)?shù)摹Ｔ诖蠖鄶?shù)情況下Actor的的確確就是用戶（確切地說是系統(tǒng)用戶所扮演的一種角色），所以我們可以用“使用者”這個詞從字面上與“用戶”（user）進行區(qū)分，但同時又保持兩者語義上的聯(lián)系。我們還可以把為系統(tǒng)服務(wù)的Supporting/Secondary Actor（見下文）叫做“被使用者”（為了簡化可以省略“被”字）或“輔使用者”。除了指系統(tǒng)的用戶之外，“使用者”還有另一層含義，即Actor是use case的使用者（或被使用者），這種關(guān)系在UML用例圖上應(yīng)該可視化地表示為它們之間的連線（關(guān)聯(lián)）。這樣解釋不但說的通，而且更便于不熟悉軟件技術(shù)的業(yè)務(wù)人員理解。
當(dāng)然，我們也不排除將來會找到“use case”、“actor”等術(shù)語更好的譯法。

二、USE CASE的來歷

       Ivar Jacobson在1967年定義愛立信AXE系統(tǒng)的夠架時開始書寫使用場境usage scenarios。

      二十世紀八十年代中期Jacobson花了很多精力來思考過去十多年的工作方法。他造了一個術(shù)語anvendningsfall，大意是“使用情況”（situation of usage）或用況（usage case）。但當(dāng)用英文出版的時候，他發(fā)現(xiàn)“useage case”在英語里說不通，所以寫作用例“use case”

三、創(chuàng)建USE CASE的原則

      用例是短文
      用例可以是一個場景，包括動作和互交。
      用例可以是一組場景，描述不同場景下的行為。這種書寫格式可以在任何時候描述有變體的行為，例如黑盒需求，業(yè)務(wù)流程，系統(tǒng)設(shè)計說明。
      用例里不要有系統(tǒng)設(shè)計
      用例里不要有界面設(shè)計
      用例里不要有特性列表
      用例里不要有測試
      用例應(yīng)該描述行為需求
      用例的主場景不要超過九步?？梢栽谶m當(dāng)?shù)膶哟紊系玫阶幽繕撕鸵瞥O(shè)計說明。
      用例的最大價值不在于主場景，而是在于備選行為。主場景可能只占用例長度的四分之一到十分之一。

四、Use Case 事件流

　　Use Case具有一個基本事件流（可稱為"理想路徑"）、多個例外流，包括：
　　　　基本變化
　　　　特殊情況
　　　　處理錯誤情況的異常事件流

五、Use Case 說明書

　　Use Case 說明書應(yīng)包括以下內(nèi)容：
　　　　功能描述
　　　　可用性
　　　　可靠性
　　　　性能
　　　　可支持性
　　　　設(shè)計約束

六、Use Cases將做成多大？

　　試圖決定Use Case的大小是一個很有趣的話題，處理這件事的一個方法是將Use Case的大小跟它的意圖和范圍關(guān)聯(lián)起來，對于一個真正大的范圍來說，一個Use Case并不要在一個系統(tǒng)中處理那么多，但這些系統(tǒng)都用于同一商業(yè)領(lǐng)域，稱為Business Use Case，它把整個公司看作一個黑盒和Actor關(guān)于公司目標的說明。這些Business Use Case的場景不允許假定任何公司內(nèi)部的結(jié)構(gòu)，一個客戶將向公司下一個定單而不是客戶服務(wù)部門。

　　對于系統(tǒng)發(fā)展而言，Use Case的范圍限制一個單一的系統(tǒng)，這是Use Cases最通常的形式，我們稱之為System Use Case，它把整個系統(tǒng)看作是一個黑盒，它不指定任何內(nèi)部結(jié)構(gòu)并且僅受限于問題域的語言描述。

　　Use Cases的另一范圍是設(shè)計子系統(tǒng)和系統(tǒng)內(nèi)部組件的，稱為Implementation Use Cases，它把組件看作一個黑盒，并且這些Actors是區(qū)分它的成員。例如：可能會用Implementation Use Cases去說明應(yīng)用系統(tǒng)中email組件的需求。

　　給出了這些分類，關(guān)于Use Case的大小話題變得容易了，設(shè)計這些項的范圍來調(diào)整整個大小。幫助系統(tǒng)設(shè)計者，每個Use Case只描述沒有大的分支的行為的單個線索。違背這個規(guī)定，Use Case看起來通常是不準確的或含糊的，作為測試說明的資源和參考，它也是很難使用的。

七、Use Cases的說明

      Use Cases的好處是一些情節(jié)能用不同程度的正規(guī)化的文字說明。每個情節(jié)涉及Use Cases中單一的途徑，細節(jié)是條件組。

      不正規(guī)的文本描述也能使用，不過當(dāng)條件較多和可能失敗的情況下它們很難跟隨下去。開始試圖理解需求時，不正規(guī)的敘述風(fēng)格也是非常有用的，然而隨著Use Cases的進展，使用更加正規(guī)的機制去說明Use Cases才是有用的。

      下面是客戶對Use Case“下定單”的粗略概略：

      “確定客戶，找出需要的并且倉庫里還有的物品并檢查客戶信用額是否夠用”

      結(jié)構(gòu)化敘述的格式已經(jīng)被證明是非常有效的。這個格式所做的事是描述每一個情節(jié)的行為者：目標語句對順序的敘述。在這個順序中，每一個行為者：目標的語句對都假設(shè)前一個的目標是成功的，右面是一個簡單的范例：

      Use Cases認為我們正在設(shè)計的系統(tǒng)是一個單一的黑盒，根本沒有任何內(nèi)部結(jié)構(gòu)被記錄下來，并且它被認為是一個情節(jié)產(chǎn)生的目的及對應(yīng)單一的行為者（Actor）。這些Use Cases沒有表示任何關(guān)于系統(tǒng)內(nèi)部的東東，只是表示系統(tǒng)將達到什么樣的目標及由什么（人或其它系統(tǒng)）操作和負責(zé)。

八、Use Cases使需求有利于回顧

　　Use Cases已經(jīng)得到越來越廣泛的應(yīng)用，它與其它需求捕獲技術(shù)相比，它成功的原因在于：
　　　　1 　Use Cases把系統(tǒng)當(dāng)作一個黑盒
　　　　2 　Use Case 使在需求中看到實現(xiàn)的決定變得更加容易

　　最后一點源于第一點的補充，一個Use Case沒有指定任何這些需求相關(guān)的系統(tǒng)的內(nèi)部結(jié)構(gòu)，所以說，如果這個Use Case中陳述了"提交改變到定單數(shù)據(jù)庫"、"顯示結(jié)果到Web頁面"等的話，那么內(nèi)部結(jié)構(gòu)是顯而易見的，并造成對設(shè)計的潛在約束。

　　為什么這些需求不指定內(nèi)部結(jié)構(gòu)的原因是，說明的內(nèi)部結(jié)構(gòu)給設(shè)計者帶來了額外的約束，沒有這些約束設(shè)計者們能更自由地建立一個正確實現(xiàn)客觀可見行為的系統(tǒng)，并存在出現(xiàn)突破方案的可能性。

九、Use Cases的圖形符號

　　這里是Use Cases的圖形符號描述，UML中一個單一的"Stick-Man"符號標示角色（Actor），用橢圓標示Use Cases，如

（圖一）所示。這些圖對于你想看到Use Cases之間如何關(guān)聯(lián)的"大圖"和獲得系統(tǒng)上下文的大體描述來說是非常重要的。

　　Use Cases圖沒有顯示不同的場景，它們的意圖是顯示角色和Use Cases之間的關(guān)系。所以Use Cases圖需求用結(jié)構(gòu)化敘述文本來補充。UML提供一些可供選擇的圖來顯示不同的場景，這些常規(guī)的圖形有交互圖、活動圖、順序圖、狀態(tài)圖等（本文暫不討論這些圖）。使用這些圖的主要缺點是它們不象文本一樣是緊密的，但它們能用于給出Use Case的整體感覺。

十、Use Case 的評價標準

　　是否每個Use Case 都包括至少一個actor？
　　是否每個Use Case 都獨立于其他Use Case？
　　是否每個Use Case 都有一個簡單的行為或事件流？
　　是否每個Use Case 都有一個唯一的、直觀的、可擴展的名稱，使它不至于在后期被混淆。
　　用戶是否容易理解Use Case 的名稱和描述。

十一、Use Case 模型的評價標準

　　Use Case模型顯示系統(tǒng)中的Use Case與Actor 及其相互關(guān)系。其評價標準有：
　　　　Use Case 模型是可理解的嗎？
　　　　通過對Use Case 模型的研究是否能對系統(tǒng)功能有一個清晰的概念。
　　　　所有的actor都定義了嗎？所有的功能需求都滿足了嗎？
　　　　Use Case 模型是否存在多余的行為。
　　　　從模型到Use Case包的劃分是否是恰當(dāng)?shù)摹?/p>

十二、使用Use Case 的誤區(qū)

　　由于具有簡單的圖形符號、易理解的自然語言說明書，Use Case在文檔系統(tǒng)和軟件需求領(lǐng)域成為一 項越來越受歡迎的技術(shù)。Use Case對開發(fā)小組極具吸引力，即使小組成員對正式的需求文檔沒有經(jīng)驗，但這些簡單性卻具有欺騙性，即使項目小組在開始使用Use Case 時沒有任何麻煩，當(dāng)他們將其應(yīng)用于大項目時常常會遇到許多同樣的問題。

     1 使用 use case 十大誤區(qū)

　　1． 系統(tǒng)的boundary 沒有定義或經(jīng)常改變；
　　2． 從系統(tǒng)觀點而不是actor觀點來定義Use Case；
　　3． Actor的名稱不一致；
　　4． Use Case 定義過多；
　　5． Use Case 和actor之間的關(guān)系象蜘蛛網(wǎng)一樣錯綜復(fù)雜；
　　6． Use Case的說明太長；
　　7． Use Case的說明不清楚；
　　8． Use Case沒有正確的描述功能需求；
　　9． 用戶無法理解Use Case；
　　10． Use Case 無法正常結(jié)束。

       2 如何避免以上問題

      清楚的確定系統(tǒng)的boundary.
　　簡單來說，系統(tǒng)的boundary就像一個加了標簽的盒子，actor在盒子外，而Use Case在盒子內(nèi)。我們稱之為系統(tǒng)的這個盒子究竟是什么呢？一個計算機系統(tǒng)？一個應(yīng)用系統(tǒng)？或一個完整的企業(yè)？…Use Case 可以用來合理地描述任意系統(tǒng)。但一次只能用來描述一個系統(tǒng)，在一個系統(tǒng)中恰當(dāng)定義的actor和Use Case用于另一個不同的系統(tǒng)中就會出現(xiàn)錯誤。

      使用標準模板書寫Use Case 說明書
　　Use Case 圖形符號已經(jīng)被標準化并作為對象管理小組UML的一部分，但自然語言的Use Case 說明書還沒有被標準化。為了成功書寫Use Case 說明書，我們需要一個標準模板來保證Use Case 的一致性。

      關(guān)注actor的真正目的，從actor的觀點而不是系統(tǒng)觀點來命名Use Case
　　面向Use Case 的需求與傳統(tǒng)的功能性系統(tǒng)需求之間最顯著的區(qū)別在于actor ，以面向Use Case的觀點，系統(tǒng)存在是由于actors 要通過該系統(tǒng)實現(xiàn)某些目標，actor與系統(tǒng)進行交互來實現(xiàn)其目標，我們將這些交互行為定義為Use Case 。

      不要將Use Case 說明書與用戶接口設(shè)計相混淆
　　現(xiàn)在有一種很流行的觀點：由于Use Case 是actors 與系統(tǒng)之間的交互，所以將所有的用戶接口設(shè)計圖放在Use Case說明書中是一個好辦法。初看時，這的確很有用，因為它將在說明書中描述的actor/系統(tǒng)之間的交互行為以圖的形式表示出來，非常直觀。但是這樣做的負面影響卻遠遠大于其好處，用戶接口設(shè)計可能會隨著時間而改變，我們不應(yīng)該讓系統(tǒng)需求依賴于用戶接口設(shè)計，相反地，用戶接口設(shè)計應(yīng)該滿足Use Case 需求。如果我們將用戶接口設(shè)計置于Use Case 說明書中，當(dāng)需求需要被認可和定為基線時，很自然地，這些設(shè)計元素可能仍然在改變，這就使得用戶接口設(shè)計成為不完整的、不正確的和/或不一致的。

　　將用戶接口設(shè)計置于Use Case 說明書還會出現(xiàn)另一個問題，為了在Use Case 之間和接口之間建立一對一的通信，我們會選擇反映用戶接口的Use Case塊而不是反映用戶目標的Use Case 塊，這樣，為了表達一個完整的用戶目標，我們使用交互Use Case 關(guān)系，將不同的、基于用戶接口的Use Case 聯(lián)接起來，結(jié)果在Use Case 模型中，我們得到了一幅類似蜘蛛網(wǎng)的關(guān)系圖。實際上，這副圖是用戶接口說明圖，雖然它在系統(tǒng)文檔中是很重要的一部分，但他屬于用戶接口設(shè)計文檔，而不是Use Case 需求文檔。

      實現(xiàn)用戶接口和Use Case 交互之間的松散耦合
　　松散耦合是比較合適的，低逼真度的用戶接口圖有助于理解Use Case ，但要注意不要過度的將基本交互與用戶界面機制相連，用戶界面很有可能會改變。在功能說明書中，要注意actor做些什么（如"提交請求"）而不是交互是怎樣完成的(如"雙擊提交按鈕")。

       不要在Use Case 和用戶接口之間建立通信
　　試圖在Use Case 和用戶接口之間建立通信可能會存在潛在的、不正確的功能操作。Use Case 不僅與只能訪問某個接口的actor相聯(lián)，而且與那些能夠更新該接口的actors相連（這可能是例外流），結(jié)果就造成了不正確的功能操作。我們應(yīng)該在基于實際用戶目標和功能操作的基礎(chǔ)上拆分Use Case ，而不是在基于用戶接口的基礎(chǔ)上組合Use Case ，只有這樣才能得到正確的Use Case 模型。

       回顧Use Case 模型和Use Case 說明書，如果你不能防止所有的誤區(qū)，你應(yīng)該盡早認識問題并確定問題
　　這個觀點并不是什么新東西，有關(guān)代碼檢查的經(jīng)典算法已有大約25年歷史了，但怎樣將其應(yīng)用于Use Case 呢？ 首先，回顧Use Case 模型，回顧一下Use Case 的簡單說明（Use Case 名稱、目標、簡單描述）。這項工作應(yīng)在繪制草圖時盡早執(zhí)行，并在寫詳細的Use Case 說明書之前完成。接著是回顧Use Case 草圖，保證圖是正確的，并且詳細的Use Case說明書是完整的。最后是正式回顧最終的Use Case 圖和Use Case 說明書。

　　我們發(fā)現(xiàn)這種三階段式回顧比單一的"宇宙大爆炸"式回顧有效，在我們花大量的時間寫說明書之前，Use Case圖中存在的許多實質(zhì)性問題可以被發(fā)現(xiàn)，這種方法減少了當(dāng)需求改變時需要做的重復(fù)工作。

十三、Use Cases應(yīng)用當(dāng)中的復(fù)雜性和危險

      主要行為者（Actor）和Use Case之間沒有連結(jié)

      一些情況下，從Use Case中取值的行為者（Actor）和積極參與這個Use Case的行為者（Actor）之間沒有清晰的連結(jié)。如：財務(wù)主管能成為“發(fā)票確認”的行為者（Actor），但他未必是創(chuàng)建發(fā)票的人。這不是什么問題，這個Use Case仍然是正確的，它正說明行為者取值和設(shè)計的系統(tǒng)的范圍外的Use Case發(fā)生的初始化之間的關(guān)系。主要行為者是有用的，因為這個人扮演的角色是當(dāng)你說明Use Case時需要跟他說的人。

      情節(jié)步驟不需要連續(xù)

      情節(jié)中步驟順序的情況是沒問題的，這里有一些機制去突出可能的并行步驟。在UML中活動圖是首選的機制，通過非正式地看Use Case的情節(jié)你可以注意到可能的平行步驟；可以看Use Case內(nèi)一些鄰近的步驟；也可以有相同的行為者（Actor）對步驟負責(zé)。之前我們舉過的例子里，確認數(shù)量和確認信用額可能是平行的。有時候在Use Case的說明文檔中標記這些可能的平行步驟是有用的。

      Use Cases的大小

      當(dāng)開始做Use Cases的時候有個很顯然的危險就是它要么有很多步驟要么就很少步驟。如果在Use Case中有超過15個步驟，它可能包含一些實現(xiàn)明細。如果它只有非常少的步驟則檢查它的目標是否是達到一個沒有很多分支的活動的單一線索。

      較少的人類行為者（Actor）

      如果Use Case有較少的人類行為者，而大多數(shù)行為者是其它系統(tǒng)，通常的做法是修改這個Use Case。尋找系統(tǒng)必須做出反映或公認的事件勝過會見這些行為者。

      需求捕獲和系統(tǒng)復(fù)雜性

      總而言之，這些情節(jié)捕獲到系統(tǒng)復(fù)雜度的同時行為者：目標語句對容許大的系統(tǒng)以相對壓縮的格式說明。Use Case的格式的作用是用戶和開發(fā)者能標志出行為者，然后確認這些行為者工作職責(zé)對應(yīng)（或不對應(yīng)）的目標，代替一個大的很難讀的功能規(guī)格說明書。

      僅僅這樣，用戶和開發(fā)者就有足夠的興趣進而研究那些情節(jié)的細節(jié)。

      系統(tǒng)不僅僅有應(yīng)得的功能性需求

      一些Use Cases并沒有捕獲所有的客觀需求，僅僅是捕獲了系統(tǒng)怎么用的那些功能性需求。然而還有許多方面的需求需要去捕獲的。其中有的非功能性需求使用關(guān)聯(lián)以至于也能隸屬于個別的Use Case，如性能需求和系統(tǒng)容量的需求。另外的一些不是關(guān)聯(lián)的而是要單獨地去捕獲，它們是以下的需求：

      · 系統(tǒng)范圍
      · 系統(tǒng)用戶的目標
      · 用戶界面原型
      · 一般規(guī)則
      · 約束
      · 算法

      運行時期和建立時期的需求比較

      一個重要的因數(shù)要記住，就是系統(tǒng)的贊助者是大過用戶團體的。系統(tǒng)中有許多的風(fēng)險承擔(dān)者，Use Cases僅僅捕獲其中一些風(fēng)險承擔(dān)者的需要，具體說，Use Cases僅僅捕獲系統(tǒng)運行時期的需求而忽略做為系統(tǒng)開發(fā)組織的風(fēng)險承擔(dān)者的需求，開發(fā)組織最有興趣的是對建立時期需求的描述。

      運行時期需求包括：系統(tǒng)范圍、用戶組織對產(chǎn)品的期望和目標、Use Cases、其它非功能性需求。

      建立時期需求包括：減少開發(fā)成本、較少的變更處理、現(xiàn)存組件的重用。

      建立時期的需求可以部分的由Use Cases把握。但許多方面是需要由開發(fā)組織的處理的。

          · 項目范圍和目標：項目必須提交什么。（和系統(tǒng)范圍的區(qū)別是它提交的是所有項目的東西）

          · 增長性和變更請求：這些可以在捕獲為常規(guī)Use Cases格式中的“Change Cases”

          · 開發(fā)負責(zé)人的約束：包括標準、習(xí)慣、工具、品質(zhì)度量標準、品質(zhì)保證原則、及品質(zhì)保證的習(xí)慣。

十四、Use Cases的適用性

      Use Cases首先用于需要響應(yīng)客觀事件的系統(tǒng)。它們能用于提供了一個有很容易理解的目標的清楚的行為者的環(huán)境。當(dāng)結(jié)果不可定義或不清晰時不能用Use Cases。意思是如果目標成功或目標失敗不能有一個明確的定義，那么Use Cases不能用來捕獲需求。

      然而說到這，現(xiàn)在大部分對象方法都使用Use Cases。因為Use Cases被證明是捕獲需求的非常有效的機制。

十五、小結(jié)

　　Use Case 是系統(tǒng)提供的功能塊，換句話來說Use Case演示了人們?nèi)绾问褂孟到y(tǒng)。通過Use Case觀察系統(tǒng)，能夠?qū)⑾到y(tǒng)實現(xiàn)與系統(tǒng)目標分開，有助于了解最重要的部分――滿足用戶要求和期望，而不會沉浸于實現(xiàn)細節(jié)。通過Use Case 用戶可以看到系統(tǒng)提供的功能，先確定系統(tǒng)范圍再深入開展項目工作。