[系統開發生命週期]Use Case Diagram概述
本篇主要針對Use Case Diagram 的目的、撰寫注意事項、Use Case不做哪些事情做些說明。
目的
Use Case Diagram 主要是為了增進我們與客戶間的需求雜訊，避免客戶的期望與系統分析師的認知有落差，之前有寫過一篇文章，其實Use Case Diagram 是解決此問題一個很好的方法：[系統分析]談談需求分析(RA)
Use Case Diagram主要是描述一個系統或類別提供給外界之交互作用者的功能。簡單來說就是說明一個系統的功能及其使用者。
Use Case透過很簡單的表達方式，讓我們可以較輕易的向客戶確認需求，以下說明一下Use Case如何撰寫。
撰寫注意事項
Use Case Diagram非常單純，主要分為以下兩個部分：
- Actor：代表使用者與系統使用案例互動的代表，一般而言角色可為：人(human)、硬體設備(hardware device)、其他系統，而非只針對人而已。
- Use Case：使用案例描述系統要完成的成果，而不是如何進行，通常Use Case是一個動作，例如：儲存資料、加入會員等等…
如果以jude這套UML工具來說，Actor與Use Case的圖示分別如下，非常簡單且可愛。
在VS2010中則分別是：
簡單的Use Case範例如下，代表了兩個Use Case，其中一個是Customer觸發了Browse Web Site的Use Case，另一個則是Customer觸發了Buy Merchandise的動作，從這樣的範例中，我們就可以跟客戶說，一個Customer對我們網路購物車，最少會有這兩個可能的Use Case，並詢問客戶是否還有其他動作需要再加的。
上圖中Actor與Use Case間的連接線，我們稱為連結(Association)，它表現出參與者(Actor)與系統使用案例之間的溝通 (communicate )，可以在雙方之間傳送及接收訊息(Message)，其他相關的關連還有：
- Extends：單一Use Case的功能被選擇性地插入到叧一個 Use Case，如下例，客戶瀏覽網站不見得會購買商品。
- Includes：單一Use Case的功能完全包含到叧一個 Use Case，如下例，要寄出訂購的商品前，一定要先填寫訂單才行。
不過以上兩個我們儘量少用，避免我們的Use Case Diagram過度分支而複雜，原則上我們撰寫的Use Case一定要讓客戶跟開發人員都能看懂，否則這個Use Case就不是一個好的Use Case了。
Use Case不做的事情
Use Case並不是將所有的需求都描述進去，以下幾項是不會在Use Case中被撰寫的：
- Implementation details：不要描述實作細節，只講概要功能就好，例如不要說明資料將被存到Oracle資料庫，而說資料將被儲存就好。
- GUI Information：不要講UI上的內容，例如按下『存檔』按鈕，避免到時候畫面作多國語言時，我們還要將Use Case改成多語內容。
- Internal processing unrelated to a stakeholder request：不要講與使用者無關的系統內部作業，這一點跟第一項很像，就是不用講過多的邏輯內容在裡頭。
- Non-functional requirements：不要講非功能性需求，例如系統每個操作要在2秒內回應，同時上線人數要達3000人等。
Use Case Diagram本身並不複雜，最困難的還是在識別出系統的關鍵人員(Actor)跟關鍵應用(Use Case)，只要找出這兩者，圖很快就可以畫出來，並跟客戶做確認了，若有興趣討論這部分我可以再分享一下。
看完這篇後建議再看這篇會更完整：[系統開發生命週期]Use Case Diagram補完
這邊也有一篇相關文章可以參考：[修練營 UML]Use Case Diagram簡介
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
