使用案例模型(Use Case Model)係由 使用案例圖(Use Case Diagram) + 使用案例敘述(Use Case Description) 所組成的。
任何事物，若是運用 80/20 法則，將主要精力集中於 20% 的重點上，可以節省及避免耗費太多的精力於錯誤的細節上。
一開始，先利用使用案例圖，找出最接近本質性(Essential)的元素：使用案例(橢圓型圖示)、參與者(棒形人偶圖示)及系統範圍(套件圖示)。
一開始就做對的事情，免得因太早落入細節的使用案例描述，結果回頭才發現團隊對系統範圍、目的等有見解上的分歧，而耗費太多不必要的精力與時間。
對系統全貌有了共識，再由需求分析師針對使用案例來描述參與者與系統之間溝通的對話。
需求分析師最重要的一個心態，在於描述對話的過程期間，謹記要把系統當黑盒子，只能看到系統的外觀。如此才能避免不知不覺會描述到系統內部的實做細節。
仍然利用 80/20 法則，先利用散文、簡潔易讀的文筆來書寫使用案例敘述，專心把最常發生(most of time)的情景描述下來，成為使用案例敘述內的基本事件流程(Basic course of event)。
凡事總有例外(Exception)及意外(Accident)發生，最重要、必須防範處理的例外，需要有相對應的措施處理。將許多必要的例外情況記錄在使用案例敘述的替代(alternative)及例外處理的流程欄位上。
可以想得到而先採取防範措施的情況，稱之為 “例外”；而完全無法預料的，稱之為 “意外”。
不要也不可能想要窮盡紀錄所有的例外情節，因為，總是會有意想不到的 “意外” 發生。
反而，在無常的情況中，如何讓系統有 “應變” 的能力，這會比較重要。
有了表達全貌的使用案例圖、一份簡潔易讀的使用案例敘述，需求分析師的工作暫時告一段落，由系統分析師接手，來負責實現(Realize)該使用案例。
實現(Realize)使用案例就是代表了要開始做系統內部的結構分析與設計。
此時系統分析師的角色，會很像電影導演的角色，要安排劇本，找適當的演員來演一齣戲(Use Case)。
這又是另外一段故事了．．．
基本的心得，建立使用案例模型，從低精確度逐漸地至高精密的細節，在階段過程中，用最少的精力，找出最重要的精華與本質，一開始把焦點集中在對的目標(Goal)上，勝過於忙忙碌碌，結果花在太多沒有必要的工作上。
- 建立使用案例圖—界定系統範圍、找出參與者、找出使用案例
- 利用自然語言記錄使用案例敘述—將系統當黑盒子，描述參與者與系統之間的操作對話過程。關心的是，系統 “做什麼(What to do)”
- 實現(Realize)使用案例。開始探討系統要 “如何做(how to do)”
Hello CityPig:
我個人是很滿意於 MediaWiki 的排版功能，目前應該是不會更換 wiki 系統的。(可惜的是其權限控管少了一個對迴響功能權限的設定)
不過感謝告知這一個訊息。
WikkaWiki 有權限管理的功能，可由頁面的擁有者來設定文章權限，請參考
http://www.vixual.net/wikka/wikka.php?wakka=Archive2005021701
Hello wordmar:
感謝提供如此多的想法與意見。
對於 80/20 法則，並非是所謂聰明人或有權位的人才需如此做的。
最簡單的說，主要重點在於 “效率” 管理上的關鍵實務。
至於何者為 20，何者為 80，不是單論事情的多與寡，這只是在提醒自己將主要精力擺在何處。
什麼事才是最重要的？見仁見智。個人提供了一個字彙參考：”Essential”，或許可以從這方面思考。
我覺得王兄說得很不錯，但我同時也想到一些問題(其實和王兄的這篇文章也不見得有關)，提出來大家參考一下。
說到80/20法則，我一直有個疑問，就是它是適用於比較聰明或是有權位的人，例如我以前的老闆，他只花20%的時間，做了他認為80%的事，反觀我們，就是花80%的時間，做剩下20%的事，這樣聽起來，我們底下的人似乎都是笨蛋，花一大堆時間，做沒有效率的事、或是所謂的dirty work，可能還會被老闆笑：”我幫你們做好了絕大部份，剩下那麼一點，還需要做那麼久喔？”
我覺得對於這個想法我目前想到二個問題：
1、一件事完成的百分比無客觀的認定–人們認為的80%，並不一定在事實上就是80%。
2、某些事的完成，就是要百分之百，沒有所謂的百分之80，例如一輛車，除了缺少引擘之外，其他都做完了，這樣算不算快要做完？
或是在寫程式的時候，我們把主要的流程寫完了，算是百分之幾？有人認為是80%，但我認為其餘的例外處理才是80%，例如主程式寫完，只有很小心翼翼的執行才能跑完全程，而隨便亂按就有例外產生，這樣的程式算是百分之幾？
其實我沒有要否定80/20啦！只是上來抬個摃~~
的確是…
那不知您架設的wiki有提供設為readonly的功能嗎？ 如果有的話，就很方便啦～
Hello Jan Yeh:
原因在於，Blog 並不適於被用來快速的建構文章的架構。
而這點，是 wiki 的強項。
事實上，我早已架設好 wiki，只是現在尚未開放而已。 ~_^
王老師～
周日上課有提到想用wiki希望別人可以回饋，卻又不想做共筆讓別人編輯，我覺得有點奇怪的是…
Blog不就是你要的功能了嗎？
^_^