建立使用案例模型的 80/20 法則

使用案例模型(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)”

文章導覽

   

共有 7 則迴響

  1. Hello CityPig:

    我個人是很滿意於 MediaWiki 的排版功能,目前應該是不會更換 wiki 系統的。(可惜的是其權限控管少了一個對迴響功能權限的設定)
    不過感謝告知這一個訊息。

  2. Hello wordmar:

    感謝提供如此多的想法與意見。

    對於 80/20 法則,並非是所謂聰明人或有權位的人才需如此做的。

    最簡單的說,主要重點在於 “效率” 管理上的關鍵實務。

    至於何者為 20,何者為 80,不是單論事情的多與寡,這只是在提醒自己將主要精力擺在何處。
    什麼事才是最重要的?見仁見智。個人提供了一個字彙參考:”Essential”,或許可以從這方面思考。

  3. 我覺得王兄說得很不錯,但我同時也想到一些問題(其實和王兄的這篇文章也不見得有關),提出來大家參考一下。

    說到80/20法則,我一直有個疑問,就是它是適用於比較聰明或是有權位的人,例如我以前的老闆,他只花20%的時間,做了他認為80%的事,反觀我們,就是花80%的時間,做剩下20%的事,這樣聽起來,我們底下的人似乎都是笨蛋,花一大堆時間,做沒有效率的事、或是所謂的dirty work,可能還會被老闆笑:”我幫你們做好了絕大部份,剩下那麼一點,還需要做那麼久喔?”

    我覺得對於這個想法我目前想到二個問題:
    1、一件事完成的百分比無客觀的認定–人們認為的80%,並不一定在事實上就是80%。
    2、某些事的完成,就是要百分之百,沒有所謂的百分之80,例如一輛車,除了缺少引擘之外,其他都做完了,這樣算不算快要做完?
    或是在寫程式的時候,我們把主要的流程寫完了,算是百分之幾?有人認為是80%,但我認為其餘的例外處理才是80%,例如主程式寫完,只有很小心翼翼的執行才能跑完全程,而隨便亂按就有例外產生,這樣的程式算是百分之幾?

    其實我沒有要否定80/20啦!只是上來抬個摃~~

  4. Hello Jan Yeh:

    原因在於,Blog 並不適於被用來快速的建構文章的架構。
    而這點,是 wiki 的強項。

    事實上,我早已架設好 wiki,只是現在尚未開放而已。 ~_^

  5. 王老師~

    周日上課有提到想用wiki希望別人可以回饋,卻又不想做共筆讓別人編輯,我覺得有點奇怪的是…

    Blog不就是你要的功能了嗎?
    ^_^

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *