網友 Thomas，在我個人發表過的一篇文章：「三論「博X來」— 訂購商品與結帳是否是同一個使用案例？」，提問了對使用案例分析的幾個相當不錯的問題與觀點。 老實說，這讓我精神為之振奮起來，已經許久沒有人與我討論使用案例分析的議題了。 我曾提及，使用案例是易學難精，沒有把握基本精要與原則，很難把圖給畫好 (不容易界定出系統範圍)，更何況是用純文字來寫出需求陳述。而且，使用案例如同學習圍棋一樣，每一個階段的學習與思考，又能再有著對其本質更深一層的體悟。 相對來說，應用在實務的需求分析上，也會來得更為得心應手。
這裡就 Thomas 所提問的問題，獨立出來另以本文來回覆。 同時也算是對上述該篇文章的補充論述。
您好:
對與你的無私與熱心真的令人佩服
看了你這篇文章感覺上有一個地方有點不解之處,想跟您請教一下
一般來說 使用 Use Case 時最怕受傳統結構化的影響,而將 Use Case 畫成功能分解,但看了你的 Use Case Diagram 的圖,其中訂購商品這個 Use Case 又去 include 查詢商品資訊及放入購物車,坦白講感覺有點像是功能分解的方式,要是我畫這張圖,我可能只會有查詢商品資訊及放入購物車,不會有一個訂購商品這個 Use Case,查詢商品是使用者一進來就會使用的功能,對使用者來講是一個獨立的價值,他就是喜歡逛逛而已,而放入購車又可視為一個獨立的需求,至於訂購商品應該是一個企業流程,這個企業流程包含很多有價值的事情,實在不適合當成一個 Use cASE 反而比較適合成為此 uSE Case 的系統邊界,除非你這張 use case 的層級是在討論企業層級的 use case,而不是在討論 系統層級的 use case
不知您以為我的觀點是否正確
謝謝
關於上述問題的回覆：
- 我們要先對使用案例的本質弄清楚。Use Case 確然就是功能分解！！ (這點最重要，要先分清楚使用案例的分解方式為何)
- 與傳統的模組化功能分解不一樣的是，模組化的功能分解係以功能樹 (functional tree)的方式將大功能分解成小功能，每一個小功能又各自分解更小的功能，直至每一個小功能可以成為一個開發的單位為止。
- Use Case 的功能分解，係以目標導向 (Goal-oriented) 的方式，從使用者 (參與者)的角度，在特定的期間 (session) 內，能完成他對系統的操作期望。每一個 Use Case，均可以被視為是一個迷你的系統，是可以被各自獨立來實現 (realize)。
- 回至本例，我在圖中係凸顯了系統需滿足使用者兩個主要的功能 (期望)，一為訂購商品；另一為結帳商品。 至於為何是分為兩個使用案例，我已在文內有敘述。
- 為何我是把主要的 UC 名稱定為「訂購商品」而不是「放入購物車」，原因在於我想凸顯它是 參與者 (Actor) 操作系統的一個重要目的。若用英文命名，會更為恰當。名稱即為 「Place a Order」，如此也比較不至於從字面上引起誤解。 另外，可要注意的是，「訂購商品」正是該資訊系統最重要的交易型使用案例，若把它拿掉，那麼這個資訊系統的價值可就完全不見了。 (其實，我在文內均已有描述這樣的論點，您可以再仔細研讀。)
- 「訂購商品」與「訂購業務流程」是兩個完全不同的層次，一個是資訊系統操作層級；另一為業務流程層級。 兩者我其實是各自分開來表達的。前者我利用使用案例圖，後者我是利用業務流程圖的。 可以參考我另外一篇文章：「從企業流程(活動)圖找出資訊系統的使用案例。」
- 至於為何在圖形上，「訂購商品」會包含 (include) 兩個 Sub-UC (一為查詢商品，另一為放入購物車)？ 我在文內其實特別還說明，我是把這兩個 Sub-UC 視為是參與者在「訂購商品」期間內，重要的子程序。
- 那麼，「查詢商品」是否可以被視之為另外一個獨立的 Use Case？ 答案是 Yes！ 但是，可不要把「查詢商品」與在「訂購商品」內所包含的「查詢商品」混在一起。 前述已提，每一個使用案例，是可以被獨立來實現的。 一個獨立的 UC 與另一個被包含的 UC 雖然可能有著相同的程序，但是，在 Use Case 的需求分析階段時，儘量不要去涉及到公用的議題，而是留待到結構分析設計的階段。
- 最後，所謂的企業層級的使用案例，與資訊系統層級的使用案例，其實這個就是系統邊界界定的問題了。 幾年前寫過一篇：「從鳥瞰的觀點看 Use Case Diagram」，可以參考之。
克明兄:
我當然知道 Use Case 裡面寫的東西是 what,不是 How-to,可能我舉的例子不太適當,感謝提醒.也許我應說,同樣去高雄,會有不同的路徑去到達,而不要指出採用那一種工具會比較好,我的原意是希望表達一件事,在不同的情境下,會有不同的做法.就我們公司實際的經驗來說,往往在客戶提出一個需求後,SA 往往就從技術面來思考如何達成這個需求,而沒有考慮到在這個需求底下使用者可能的各種使用方式,我稱為在此需求底下的一組使用者意圖,每一個意圖都是一個系統需求,也都是需要成本才能完成的,如果系統分析時漏掉這些,那時間成本估的就會不準.以我們公司來講,成案前會估一個 fUNCTION POINT,SA 後要估另一個 functin point,此時的 FP 更形重要,如果漏估那人力和時程安排肯定會出更大的錯
至於你提出可以約個時間見面聊聊,真是令我受寵若驚,現在這個忙碌的社會,難得還有人這麼熱心,況且對於使用案例我還真的有太多太多的疑問須要澄清實際的作法,我是求道者,您是解惑者,時間當然由您決定,我樂於配合。我會好好準備我要問的東西,做一點功課^_^
Hello~
我已回信給您了，個人非常樂意一同交流討論軟體設計的諸多議題。 🙂
據目前您這樣的描述來看，也是很有可能，貴單位係採用 “Waterful” 的開發模式。 一開始就把需求期望做得詳細、完整。 這也算是許多大公司的生態吧，其中一個重要的原因可能就是報價的問題了。 ^^
另，”在不同的情境下,會有不同的做法”，這可能是 “Alternative Flow” 的規劃問題了； 您用了一個 “意圖” 這個字眼，相當地有意思，極具意涵，我也學到了。 🙂
克明兄:
感謝您熱心的解惑.Use Case 確然就是功能分解！ 這到是我第一次聽到的高見.但對於初學者來講,可能要傷腦筋去思考其中的不同點了.目標是使用者的一個 need,為了滿足此 need 我們將如何達成?假如我們要去高雄,可以坐巴士,自己開車或撘高鐵,採用那一種方法,完全取決於限制及我們自己的意圖,但我們一樣都可以去高雄.此時 use case 是在探索在同一個目標底下,到底會有幾種方法去完成同一件事,因為不同的做事方法會有不同的時間成本.功能分解聽起來的意思比較像是為了完成一件事,將做事的方法分解成好幾個步驟,而不像 use case 的定義:描寫某一情境下的需求
不知您認為這些觀點是否為正確
Hello~
功能分解可不是我的高見，所以 Thomas 寫說第一次聽到，我也蠻訝異的。
我發現到，Thomas 似乎誤解了我所提的 功能分解 以為是指對某一個使用案例內的功能細分？ 當然不是！
「 探討某一個使用案例，是在描述某一情境的需求」，這定義是對的，沒有問題的。 但是，我所說的 功能分解 是指對於一個系統的需求分析，採何種思維來區分有幾個使用案例。 所以，我在主文中，特別去凸顯我對其的結論，分析一個系統會有幾個使用案例，是採 功能分解 的方式，這個觀點這幾年來一直都沒變的。 當然，有可能您有不同於此的觀點，個人也蠻想聽聽您的高見的。 ^^
您在文中所舉的例子，我更發現到，我們對使用案例內的需求陳述，很有可能更是有相當大的見解歧異。 我在許多文章一直強調，UC 不談 How-to (不是不作，而是留待到系統內部的結構分析設計階段才涉及實做細節)。 但您例子似乎在 UC 已描述至如何實現的細節？ 以我對 UC 敘述的認知而言，我以為需求陳述是指參與者與系統的對話過程 (希望您能瞭解我所指的對話過程的意思)。 同樣地，這個論述以及 UC 敘述的例子，在我其它文章都可以參考到。
對了，對於 UC 所謂參與者與系統的互動對話，是有假設點的。 是僅限於資訊系統層級的使用案例；至於把企業當系統的企業層級使用案例，老實說，因為範圍太過廣大，我不認為是全然可以僅用純文字來敘述的。(這不好談，是一個很大的議題)
為何我常說，使用案例是易學難精？ 與我團隊內部的 Cowork Partner，對於使用案例的本質與應用，也常有不同的看法。 如何越能逐層體悟使用案例的本質、如何讓使用案例更能被應用得順暢，經常都是在不斷地腦力激盪與互辯討論當中，慢慢地取得共識的。 而這個共識，可不是最後的結論，只是，對於使用案例的本質觀，比較不容易改變罷了 (應用作法當然是會調整的)。
很難得這幾年來極少有人提出、論及到使用案例的觀點分析問題。 🙂
關於使用案例的觀點、作法與應用等議題，實在是很難僅用片段的文字互動、回覆討論而能敘述清楚的 (或者說，很容易引起誤解)。 我非常樂意能與 Thomas 見個面、喝個下午茶。 對於聊這些軟體設計 (尤其是使用案例)相關議題，我可是一直有極高度的興趣。 ^^