企業流程(Business Process)，在於描述企業內部各個部門工作者(Worker)協同合作，以完成某一項任務，觸發這個任務的事件(Event)經常是來自於客戶所交付的需求。
而利用圖形來描述企業流程，稱之為企業流程圖。傳統上，我們將之簡稱為 "流程圖(Flow-chart)"。

UML 的規格中，很早就將表達企業流程的流程圖納於其內，並做了一些改良，稱之為活動圖(Activity Diagram)。活動圖與傳統的企業流程圖本質是一樣的，主要的差異在於活動圖針對圖形的語法做了一些改進，使之可以表達並行(Parallel)的流程行為。

活動圖表達了企業高階管理階層所關注的：可以一窺全貌，瞭解某項業務是由哪些部門工作者負責執行哪些活動(Activity)；領域專家(Domain Expert)，可以協助企業在某項任務上，減少所耗費的工時與節省成本，這稱之為 "企業流程再造(BPR, Business Process Re-engineering)"。

事實上， 資訊系統(Information System)，也是屬於 BPR 的範疇，可以協助工作者節省人工作業的時間，或者可以讓某項原本是人工作業的活動成為自動化(Automation)。

為了讓資訊系統協助或取代工作者所做的事，需求分析師需要將原本是屬於人工作業的活動，其內必然有許多的工作事項(Work Item)，據此轉為由資訊系統來承擔其作業，亦即，系統需提供服務或功能來讓操作系統的工作者使用。

直接由活動圖加上需求訪談記錄來開發系統，不是一個好方法，原因在於：

• 無法明確地區別哪些活動是純人工作業、哪些活動是由工作者來操作使用系統、哪些活動完全不需人工介入，已經全由系統自動化了。
• "實現(Realize)" 某項活動是由 "哪一個系統" 來負責。也就是說，可能有多個資訊系統服務於企業內部，卻無法很明確可以指出該活動是由哪一個資訊系統(也有可能是多個系統的合作)來負責的。
• 無法有效釐清操作系統的使用者是誰，也無法看出是否有支援性(Supporting)的系統也參與其內。

活動圖確實可以有效地表達出企業高階經理人的觀點，但是卻不容易據此成為系統的需求，以表達出工作者操作系統的角度。系統層次(System-level) 的使用案例，正是能最有效表達出系統的範圍、操作系統的使用者、使用者使用系統的目的。活動圖與使用案例圖，可以達成最好的互補—活動圖表達企業流程；使用案例圖表達系統層次的操作。

經由一些原則與步驟，其實可以很容易地從活動圖中的活動，找出資訊系統的使用案例。因為使用案例可以明確地釐清系統範圍、系統操作的使用者、使用者操作系統的目的，所以，使用案例可以成為實現系統功能需求的最佳前導工具。

藉由一個 "臨時調高信用卡額度" 的案例來說明如何從活動圖找出系統的使用案例。

先瞭解該案例的簡單描述：

客服人員接到信用卡客戶要求臨時調高信用額度，客服人員詢問調整原因並向客戶詢問身份字號、出生日、聯絡住址等登錄之基本資料以確認是否本人，並調閱繳款記錄是否異常。然後詢問客戶打算調高之額度為何及調整之期間多久。確認完畢後，即送出案件，啟動客服流程。

案件送出，即通知客服後勤人員處理，客服後勤人員從工作駐列(Queue)中取得案件後，判斷臨時調高之信用額度是否為客服人員被授權的額度內，若是，則以電話聯絡客戶再確認是否有提出申請，確認完畢即結束流程。

若臨時調高之額度高於客服人員之授權，則後勤人員以電話聯絡客戶後，向客戶確認是否申請並解釋他被授權所能調整之額度，若客戶仍需超過額度，則後勤人員將案件轉呈客服主管處理，客服主管收到案件後，回電客戶確認資料並決定授權金額，確認完畢後即結束流程。

步驟一：利用活動圖，表達該案例的業務流程

圖一、「臨時調高信用額度」的企業流程活動圖

步驟二：找出潛在資訊系統的使用案例

將活動圖中的每一個活動(Activity)當成是系統使用案例的候選者(Candidate)，然後，針對每一個活動詢問以下幾個問題：

1. 誰是工作者(Worker)？
2. 需要系統提供服務嗎？若是，是由哪一個系統負責？
3. 系統提供什麼服務？
4. 系統是否需要支援的參與者(Supporting Actor)？若需要，是哪一個參與者？

*** P.S. ***
當利用活動分割(Partition)將活動圖切開，以界定活動是由那個部門或工作者所負責的，若是相鄰的兩個活動都是位於同一個活動分割內，且處理的時間是非常接近時，有時候會將相鄰的兩個活動視為是同一個活動再詢問以上的問題。

從步驟一的活動圖，利用步驟二所提供的問題詢問方式，來找出本案例中，哪些活動會成為系統的使用案例。

步驟三：畫出系統的使用案例圖

依據步驟二所分析出的結果，所繪出的使用案例圖如下：

圖二、「臨時調高信用額度」的系統使用案例圖