2018/10/23
一個使用個案(Use Case)是一個使用情境而不是一個功能或一個單一需求，例如，選課是個使用個案，選課的情境中需要看到選課清單，需要加選課程，需要退選課程，以這樣的狀況就不應該將選課分為三個不同的使用個案，而是將看到選課清單，需要加選課程，需要退選課程列為選課中的三個步驟。在這個階段，需要知道的是系統有哪些重要的行為者，他們使用系統的情境為何，所以，不應該列出系統的基本功能(如:登入、登出、修改個人資料)。一般而言，當系統超過9個個案的話，就應該考慮將系統切割為不同的系統了(細節請參考Ashrafi & Ashrafi, 2009,pp.233-238)。
每個使用個案只能有一個主要行為者(primary actor)，可以有多個次要行為者(secondary actor / supporting actor)，行為者是個角色不一定是人，也有可能是另一個系統(細節請參考Ashrafi & Ashrafi, 2009,pp.187-188)。每一個使用個案只會有一個主要行為者，如果發現有超過一個主要行為者，而且不同行為者扮演的角色一樣(如:組長和組員在「互評」及「查詢互評結果」中的角色一樣)，則以一般化來表示 (如:組員是組長的一般化) (細節請參考Ashrafi & Ashrafi, 2009, pp.223-224)。有時候，我們會分不清楚角色與身份，例如，櫃台也可以為自己的親朋好友購買產品，但是，這時候，他或她的角色便是購買者，而不是櫃台。就像有些老師也可能同時是學校的學生，每個人都有可能扮演不同的角色，當扮演不同角色時，就會有對應的使用個案。
將行為者分為會員、非會員、管理者(或者分為使用者、管理者)，這樣的分法似乎沒什麼錯，但是卻誤會了行為者的意義，因為行為者主要談的是角色，要由使用者扮演的角色去分析，所以，以房屋買賣為例，應該分為：購屋者、售屋者、仲介，有一些人會說，購屋者也可以是售屋者，然而，行為者談的是角色，是每一個使用個案所對應的角色，售屋者的角色是刊登房屋資訊，購屋者則是利用購屋需求尋找房屋，他們在買賣的過程中提供及需要不同的資訊，所以，不應該將購屋者及售屋者混為會員(或使用者)。
每一個使用個案會有一個對應的個案情境說明，說明各使用個案之名稱、行為者、目標、前提(pre-condition)、結束狀態(post-condition)、系列事件(正常程序、替代程序與例外程序)。如果有多個行為者，必須註明主要行為者。使用個案的前提一般是註明啟動此使用個案的條件，如：學生必須是在學狀態才可以選課，或者，賣家已經將產品下架及登錄買家，買家才可對賣家進行評分。如果沒有前提，可以留空白。使用個案的結束狀態一般是註明完成此使用個案之後的狀態，如：學生完成網路初選。系列事件是在描述使用者與系統的互動，通常是顧客所進行的動作(如:輸入哪些資料)及所應得到的訊息(如:應該看到什麼樣的計算結果，或得到資料的欄位)，在使用個案中應注重所需要的資料(細節請參考Ashrafi & Ashrafi, 2009,pp.209-223)。
其實不使用替代程序與例外程序也是可以表達整個流程，只是，使用替代程序與例外程序會比較容易閱讀。一般而言，替代程序與例外程序概念類似，然而，完成替代程序可以達到目標，但是，例外程序則不能，例如遇到存貨不足無法購買出版品的處理方式。通常完成替代程序與例外程序後會回到正常程序的下一個步驟，若不回到正常程序，則會在最後說明「完成後結束」或接下來的步驟，如：「完成後執行步驟6」。
Use case其實有不同的寫法 ，不同的教科書採用不同的做法，各有優缺點，未來就請大家依照自己的專題指導老師習慣的想法來寫。一般而言，有三種寫法 (詳參:http://www.wirfs-brock.com/PDFs/Art_of_Writing_Use_Cases.pdf) 。第一種寫法是述說式的 (Narrative)，是以寫文章的方式寫。第二種做法是情境式的 (Scenario)，(Ashrafi & Ashrafi (2009)及大部分的教科書是採取這種方式)，會一個步驟一個步驟寫，每個步驟就是使用者所採取的動作或預期的結果。第三種做法是對話式的 (Conversation) (Satzinger, et al (2012)是以這種方式)，會描述使用者所採取的動作及系統的處理動作及系統提供的反應。
第二種做法又會因為步驟的複雜程度，在處理替代流程(alternative flow)或例外流程(exception)時又有不同的表達方式。
以下的表達方式，跟Ashrafi & Ashrafi, 2009的做法類似，但alternative flow的表達方式稍微不同，建議大家依照需求的複雜程度，選擇各位認為容易理解的方式，如果怕別人看不懂，請附上參考資料來源。
第一種做法: 會列出基本流程，當部分步驟(如:第四步)會有替代流程時，第一個替代流程就編為4a，第二個替代流程就編為4b，如果在4a裡有多個步驟就編為4a1,4a2。當替代流程執行完，除非有特別標示，否則就是繼續執行下一個步驟 (如: 5) (詳參: http://pmblog.accompa.com/2009/10/08/use-case-template-example-requirements-management-basics/)
第二種做法，與第一種做法類似，會列出基本流程，每個替代流程會被分割，差別在於如果在4a裡有多個步驟時，因為都是放在4a裡，就只編1, 2。當替代流程執行完，除非有特別標示，否則就是繼續執行下一個步驟 (如: 5) (詳參: http://www.dummies.com/WileyCDA//how-to/content/how-to-create-use-case-description-for-your-busine.html)。
第三種做法，與前兩種類似，只是每個替代流程會被分割 (詳參: http://www.usability.gov/how-to-and-tools/methods/use-cases.html )。
當替代流程非常複雜的時候，上面的做法會很難看得懂，所以，有些人就認為應該將情境個別分開寫，這樣的寫法比較接近使用者的觀點(類似user story)及測試的觀點，但是，對於開發者來說就比較難看到全貌，會需要利用活動圖來描述整個使用個案 (詳參: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/use_case_spec_CD5DD9B1.html)
也可以用另一種表達方式，與前面做法不同的是在基本流程中註記分支點 (詳參: http://www.batimes.com/articles/use-case-goals-scenarios-and-flows.html)。