備選流，又稱備選事件流，英文是Alternative Flow。在RUP和UML中，備選流的解釋如下：備選事件流包括與正常行為相關的可選或異常特徵的行為，同時也包括正常行為的各種變形。您可以將備選事件流看作是基本事件流的“繞行道”，有些備選事件流將返回到基本事件流，而有些將結束此用例的執行。 

分析RUP對於備選流的定義，可以看到備選流可以分成兩類：

1，不同做法但仍然達成用例目標；

2，異常情況，無法達成用例目標。

在實際用例分析中，由於備選流可能存在兩種情況，導致備選流存在2種主要寫法：

1．在備選流中說明基本流以外的異常情況的處理，可能仍然回到基本流，也可能導致用例結束。

在備選流中說明基本流以外的其它正常和異常情況的處理，覆蓋了其它功能。

第1種寫法的例子比較常見，下文將出現，這裡不再贅述。

第2種寫法的例子如下：

用例名稱：填寫請購單

簡要說明

　　員工線上填寫圖書請購單，內容包括：圖書名稱、出版社、作者、價格、訂購人（系統自動識別）、訂購部門、訂購日期等，填好後提交給圖書管理員稽核。

　　填寫請購單的主角是員工。

事件流

　　員工選擇“填寫請購單”，用例開始。

基本流

員工選擇“填寫請購單”，提交“填寫請購單”請求；

顯示“填寫請購單”視窗並列表顯示請購單資訊（已填寫未提交、已提交稽核未通過）， 兩種狀態的請購單資訊通過選擇分別列出，稽核未通過的原因只能檢視不能修改；

請購單資訊包括：請購單編碼（系統自動生成）、訂購部門、訂購人、訂購日期、訂購原因、備註，和圖書明細包括：圖書名稱、出版社、作者、單價、數量等，圖書明細包括：新增，修改，刪除；

請購單資訊輸入操作見備選流；

新增：系統具體執行見“備選流 新增”

修改：系統具體執行見“備選流 修改”

刪除：系統具體執行見“備選流 刪除”

選擇“提交”，系統把選中的請購單提交給圖書管理員稽核，此用例結束。

 備選流

　　填寫請購單基本流中抽取出三個備選流：

　　　　請購單資訊：新增、修改、刪除；

新增

（一）員工在“填寫請購單”資訊區選擇“新增”，提交“新增”請求；

（二）系統彈出“新增請購單”空白模式視窗；

（三）請購單資訊包括：圖書名稱、出版社、作者、單價、數量等；

（四）請購單資訊輸入完畢後，選擇“儲存”提交，系統驗證資料有效性，如驗證不成功，針對所提示錯誤資訊修正輸入資料，驗證成功關閉“新增請購單”視窗；

若繼續新增請購單，則重複㈠㈡㈢㈣步驟。

修改

（一）員工在“填寫請購單”資訊區列表選中要修改的請購單，提交“修改”請求；

（二）系統彈出“修改請購單”模式視窗，並顯示當前請購單資訊；

（三）修改相應資料後，選擇“儲存”提交，系統驗證資料有效性，如驗證不成功則根據錯誤提示重新輸入，驗證成功後儲存資料並關閉“修改請購單”模式視窗同時重新整理請購單資訊列表；

若繼續修改，則重複㈠㈡㈢步驟。

刪除

（一）員工在“填寫請購單”資訊區列表選中要刪除的請購單，提交“刪除”請求；

（二）若選中的請購單屬於稽核未通過，系統提示“不能刪除稽核未通過的請購單”；

（三）刪除後重新整理請購單列表資訊同時系統提示“編號為XXX的請購單已刪除！”；

若繼續刪除，則重複㈠㈡㈢步驟。

特殊需求

　　無

前置條件

　　員工登入系統。

後置條件

　　無

---例子結束----

第2種寫法中，在備選流中說明了基本功能，用例篇幅已經變長，如果備選流中出現異常，備選流將顯得更加臃腫。因此第2種寫法比較少見。

為了解決備選流的不同情況，人們識別率異常流來解決上述問題。