＊＊ 本文同步發表於 FB社群-軟體設計鮮思維 ＊＊
前兩個星期有位上過前一期「軟體架構師」課程的學員，他在某大金融單位擔任技術職PM，特地利用週末時間到我家附近，請教我關於他利用 UML 所繪製的設計圖問題。相當認真，所以我很願意陪他一同討論軟體相關議題，順道一同在肯德基吃午餐。總共花了約兩個來小時吧，該學員還要去參加他的讀書會，真是有夠認真啊，不過起碼有討論出一個比較具代表性的使用案例其實現的主要程序描述。
畫出來是否正確或合理與否是一回事，至少他肯利用 UML 表現出他的設計思維就很值得肯定，這才有機會可以指指點點與討論的。
他只畫了使用案例圖與某一結構設計的類別圖，因爲有公司機密問題，這裏就不方便貼出他的原稿。我只就他的設計給予一些建議與修正，並利用他在 Mac 所使用的 UML 工具繪製出來。
這是上一期「系統分析設計與實作」課程的一位美女學員-Isis 的案例作品。她對 Use Case (使用案例)用於系統需求分析情有獨鍾，而且相當積極的學習與詢問問題。
不過可能待在業界許久，一開始對 Use Case 這類講究目標導向的分析方法並不容易理解，總是不自覺就鑽入到細節，或是聯想到實作面議題。所以就不容易抓到 Use Case 的分析主軸-界定參與者 (actor)使用系統的操作目的，以及實現該目的的操作程序。
我使用了幾種方法，包括如何從企業流程的分析找出使用案例，或要求綜覽閱讀 Use Case 的經典名著「Writting Effective Use Case」(再針對她提問的問題回應)，甚至乾脆從某一個實際的專業問題領域 (problem domain)著手，但效果仍不彰。
畢竟大部分軟體人員少對所謂的「抽象 (abstraction)」技能下功夫。抽象是需要經由思考、閱讀、觀察等長期日積月累才得以鍛鍊而成的。
所以換一種較具象的方法，從現實各網站的使用者操作畫面中，完成下列的系統分析工作：
我先給她系統規模較小的 Twitter 案例，要她完成上述三項重點工作，而先不用撰寫使用案例陳述 (use case description)。雖然使用案例陳述才是實現系統功能的主要程序，但可以先等系統功能的界定有了初步釐清與共識後再來描述相對的實現步驟，這對使用 Use Case 分析的 SA 而言，比較能有循序的分析節奏，才不致亂了套。
耶!!這方法還真對 IS 的性向，不到兩天就完成了我看了也覺得很有創意的分析。經由她的首肯，我就把她的案例作品分享上來。
圖、範例-從Twitter畫面操作找出 Use Cases
上個月我在「工研院」授課時，其中一位較為資深的程式開發人員問的問題： 我感覺不到寫好使用案例 (Use Case) 有什麼好處？
別誤會，這位年輕的開發人員並沒有惡意，我也認識他一陣子了。他的確是有感而發，覺得在工作上，從以前透過一般的需求規格書，到現在開發時導入 使用案例 的分析需求技術，但是，他並沒有感受到因為這樣而有加快程式撰寫的速度，反而還覺得縛手綁腳，經常需要受到規範。
這個問題，可比想像得還難以回答。 是為了可以有效保存需求分析的資產？ 還是為了系統的彈性 (flexibility)？ 前者似乎有道理，但如此對現在正進行的開發專案好像沒有說服力，甚至開發人員還覺得為了要補足這些需求文件，反而拖累了開發的速度；後者的系統彈性問題，我則是很確定與寫得好需求分析文件沒什麼直接的關係，彈性度的考量，與軟體的結構設計 (structure desgin)才是更主要的關鍵。
思考許久，我是以為，寫的好使用案例最直接的關鍵是： 影響到專案開發整個流程的節奏！
以使用案例為導向 (use case driven)的開發模式，我的體會是越來越能感受到那個所謂的 "driven" 這個字眼。 短線專案的特性，幾乎是偏以需求為優先。而使用案例的分析，其本質上仍是屬於功能 (functional)性的分析。只是有別於模組化的功能樹分析模式，後者的功能模組，耦合性 (coupling) 太重，容易牽一髮而動全身，所以在需求分析階段，會耗費許多時間在分析共用模組的考量；而使用案例，是一種目標導向 (goal-oriented)的功能分析方式。 每一個使用案例，都可以看待成是系統在某一段期間 (session)，可以滿足使用者使用系統的目的。 所以每一個使用案例，是可以個別被獨立開發，也就是說，UC-A 與 UC-B 甚至可以交付給不同團隊並行開發。而至於兩者若有共用性的議題的考量，則是延宕到結構設計階段再來討論即可。因為在需求分析階段，不用花太多時間在共用議題的考量上，所以可以很快速地實現 (realize)功能需求。
能抓得好與定義得好一個一個的橢圓使用案例，就能以該使用案例為開發單位。 這麼說好了，甚至可以把該使用案例就當成是一個迷你系統，然後來串連出整個開發的程序與產出。 例如，針對一個使用案例，就會設計一個位於中間層 (middleware)的控制型物件 (control object)，並從使用案例的敘述 (use case description)中，找出該物件應承擔的行為 (behavior)，然後再轉化成更詳細規格、程式語言的方法 (method)。 定義好控制物件與其應有的行為，就可以知道需求分析是容易並可以無縫式地轉移到實做階段，並快速地界定出程式碼的骨架 (sketletion)，再來就是補足細節、實做邏輯、連結資料庫或外部系統 等等…。
網友 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
不知您以為我的觀點是否正確
謝謝
這一次倒不是要 “批判” 博X來的訂購系統，而是想藉由該資訊系統，來聊聊需求分析的設計議題．．．
我們知道，博X來的訂購系統，存在的最大價值，就是提供客戶「訂購商品」的服務，而為了滿足客戶最終能買到所訂購的商品，所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst)，那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候，妳會分析出 “多少顆” 使用案例呢 (只涉及到上述討論訂購商品的範圍)？
我經常思考這類的需求分析議題，也曾就該問題與其他資深分析師討論，有人認為是兩個，也有人認為是一個，當然也有人認為是三個、四個…等。 好像是見仁見智，沒有所謂標準明確的答案。 我是在想，能否有一種簡易判斷的 “準則”，來決定使用案例是一個或多個呢？ 老實說，從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義，我仍不容易釐出那個準則，所以我是想透過觀察使用案例的行為，來找出那個判斷的原則為何。
先觀察實體書店一般的購物程序：客戶走入書店，瀏覽與選擇欲購買的商品 (書籍)，並放入購物籃內 (拿在手裡也算，代表已準備好欲購買的商品)，並拿到櫃臺，結帳並付款。
所以幾個使用案例呢？ 我肯定是認為一個：《購買商品》，因為客戶來這個系統 (實體書店)的主要目的就是 購買商品，而為了滿足該目的，他必須經常放入購物籃、結帳等程序，而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的，約幾分鐘到幾個小時就可以完成 (＊注意此點)。關於傳統書店使用案例圖的表達，可以參考下圖1。
圖 1、實體書店購買商品的使用案例圖
在使用案例圖的表達上，看起來好像是三個使用案例，其實本質上只有一個：《購買商品》。這裡利用《include》這個 stereo type，只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。
再回到博X來網路訂購系統來看，那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢？ 看起來很像，都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣，放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢？ 當客戶瀏覽商品資訊，若是看到打算購買的商品，就把它放入到購物車內，但是客戶並不需要馬上結帳，他可以等過幾天再決定是否結帳。所以很明顯的觀察到，這是兩個可以在不同時間點個別可以獨立完成的交易 (＊這一點與實體書店不一樣)。 (不過，這兩個交易事件好像又有些關連存在，要 結帳 前必須先有商品 放入購物車，關於此點，留待後述來討論。)
所以，我的觀察與心得是什麼？ 我會以為，若是可以獨立在某個時間點可以完成的交易事件，我會把它就視為是一個使用案例。或者再用更通俗的一句話來說，就是參與者在使用這個系統，從上線到離開的過程，可以 “一氣呵成” 地來完成一個功能案例，該功能案例就可以獨立成為一個使用案例。 所以，博X來訂購系統對於 訂購商品 的主要目標上，會有幾個使用案例？ 我是會把它切為兩個：《訂購商品》與《結帳商品》，參考下圖2。