這是上一期「系統分析設計與實作」課程的一位美女學員-Isis 的案例作品。她對 Use Case (使用案例)用於系統需求分析情有獨鍾，而且相當積極的學習與詢問問題。
不過可能待在業界許久，一開始對 Use Case 這類講究目標導向的分析方法並不容易理解，總是不自覺就鑽入到細節，或是聯想到實作面議題。所以就不容易抓到 Use Case 的分析主軸-界定參與者 (actor)使用系統的操作目的，以及實現該目的的操作程序。
我使用了幾種方法，包括如何從企業流程的分析找出使用案例，或要求綜覽閱讀 Use Case 的經典名著「Writting Effective Use Case」(再針對她提問的問題回應)，甚至乾脆從某一個實際的專業問題領域 (problem domain)著手，但效果仍不彰。
畢竟大部分軟體人員少對所謂的「抽象 (abstraction)」技能下功夫。抽象是需要經由思考、閱讀、觀察等長期日積月累才得以鍛鍊而成的。
所以換一種較具象的方法，從現實各網站的使用者操作畫面中，完成下列的系統分析工作：
- 界定系統範圍 (system boundary)，並給予系統命名。
- 規劃功能模組 (functional module)，這是邏輯性的功能分類。
- 從每一張畫面表單，透過所提供的資訊，以及要求使用者輸入的資料欄位中，藉以分析其背後的操作目的，也就是使用案例。
我先給她系統規模較小的 Twitter 案例，要她完成上述三項重點工作，而先不用撰寫使用案例陳述 (use case description)。雖然使用案例陳述才是實現系統功能的主要程序，但可以先等系統功能的界定有了初步釐清與共識後再來描述相對的實現步驟，這對使用 Use Case 分析的 SA 而言，比較能有循序的分析節奏，才不致亂了套。
耶!!這方法還真對 IS 的性向，不到兩天就完成了我看了也覺得很有創意的分析。經由她的首肯，我就把她的案例作品分享上來。
圖、範例-從Twitter畫面操作找出 Use Cases
IS 會針對每一張表單畫面，只要有提供資訊或輸入欄位的地方，先用紅筆標上編號，然後再據以分析，來找出使用者操作該表單畫面背後所隱含的操作目的 (也就是 Use Case)。
圖、範例-從Twitter畫面操作找出 Use Cases
圖、範例-從Twitter畫面操作找出 Use Cases
把操作畫面標註上編號並在旁列出可能是 Use Case 的候選名單後，再整理成一張表格，整理出主要的功能模組所對應的使用案例 (use case)。
圖、範例-從Twitter畫面操作找出 Use Cases
最後可以透過 UML 工具完成初步的使用案例模型的規劃。
圖、範例-從Twitter畫面操作找出 Use Cases
從 GUI 的操作畫面來找出使用者的操作目的 (Use Case)，藉此以作化繁為簡 (從繁雜的欄位細節界定系統功能)的需求分析整理，這未嘗不是一種好方法！
透過這樣先從大量各網站的 UI 畫面，藉以分析並整理 Use Case，慢慢地對所謂的「抽象」有了感覺與相當體會後，就不需要時刻透過這樣具象的畫面來分析；甚而可以反過來，從各類資訊 (使用者訪談、業務流程等)就可以抓到系統功能，然後再據此設計使用者的表單畫面操作。系統功能 (Use Case)與表單的畫面操作，其實可以形成很好的互補，兩者沒有絕對先後的開發次序 (甚而可以平行開發)，但可以相互印證。
如果系統分析師 (SA)可以從繁雜的表單畫面操作跳離出來，如此就不需再汲汲去窮究探討包括欄位與商務邏輯的細節，這些細節初期本來就不容易釐清楚。但要掌握相關這些細節背後的操作目的，卻是相對容易許多。這就是 Use Case 的價值所在-由使用者的操作目的來包容 (其實這也就是封裝 (encapsulation)的應用)相對細節 (欄位/邏輯)的變動性；這也是符合 CMMI 其一標的所要求的-作好需求的變動管理。