讀者對使用案例的幾個提問 (針對另文「三論博客來的使用案例分析」)

網友 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
不知您以為我的觀點是否正確
謝謝

關於上述問題的回覆:

  1. 我們要先對使用案例的本質弄清楚。Use Case 確然就是功能分解!! (這點最重要,要先分清楚使用案例的分解方式為何)
  2. 與傳統的模組化功能分解不一樣的是,模組化的功能分解係以功能樹 (functional tree)的方式將大功能分解成小功能,每一個小功能又各自分解更小的功能,直至每一個小功能可以成為一個開發的單位為止。
  3. Use Case 的功能分解,係以目標導向 (Goal-oriented) 的方式,從使用者 (參與者)的角度,在特定的期間 (session) 內,能完成他對系統的操作期望。每一個 Use Case,均可以被視為是一個迷你的系統,是可以被各自獨立來實現 (realize)。
  4. 回至本例,我在圖中係凸顯了系統需滿足使用者兩個主要的功能 (期望),一為訂購商品;另一為結帳商品。 至於為何是分為兩個使用案例,我已在文內有敘述。
  5. 為何我是把主要的 UC 名稱定為「訂購商品」而不是「放入購物車」,原因在於我想凸顯它是 參與者 (Actor) 操作系統的一個重要目的。若用英文命名,會更為恰當。名稱即為 「Place a Order」,如此也比較不至於從字面上引起誤解。 另外,可要注意的是,「訂購商品」正是該資訊系統最重要的交易型使用案例,若把它拿掉,那麼這個資訊系統的價值可就完全不見了。 (其實,我在文內均已有描述這樣的論點,您可以再仔細研讀。)
  6. 「訂購商品」與「訂購業務流程」是兩個完全不同的層次,一個是資訊系統操作層級;另一為業務流程層級。 兩者我其實是各自分開來表達的。前者我利用使用案例圖,後者我是利用業務流程圖的。 可以參考我另外一篇文章:「從企業流程(活動)圖找出資訊系統的使用案例。
  7. 至於為何在圖形上,「訂購商品」會包含 (include) 兩個 Sub-UC (一為查詢商品,另一為放入購物車)? 我在文內其實特別還說明,我是把這兩個 Sub-UC 視為是參與者在「訂購商品」期間內,重要的子程序。
  8. 那麼,「查詢商品」是否可以被視之為另外一個獨立的 Use Case? 答案是 Yes! 但是,可不要把「查詢商品」與在「訂購商品」內所包含的「查詢商品」混在一起。 前述已提,每一個使用案例,是可以被獨立來實現的。 一個獨立的 UC 與另一個被包含的 UC 雖然可能有著相同的程序,但是,在 Use Case 的需求分析階段時,儘量不要去涉及到公用的議題,而是留待到結構分析設計的階段。
  9. 最後,所謂的企業層級的使用案例,與資訊系統層級的使用案例,其實這個就是系統邊界界定的問題了。 幾年前寫過一篇:「從鳥瞰的觀點看 Use Case Diagram」,可以參考之。

三論「博X來」— 訂購商品與結帳是否是同一個使用案例?

這一次倒不是要 “批判” 博X來的訂購系統,而是想藉由該資訊系統,來聊聊需求分析的設計議題...

我們知道,博X來的訂購系統,存在的最大價值,就是提供客戶「訂購商品」的服務,而為了滿足客戶最終能買到所訂購的商品,所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst),那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候,妳會分析出 “多少顆” 使用案例呢 (只涉及到上述討論訂購商品的範圍)?

我經常思考這類的需求分析議題,也曾就該問題與其他資深分析師討論,有人認為是兩個,也有人認為是一個,當然也有人認為是三個、四個…等。 好像是見仁見智,沒有所謂標準明確的答案。 我是在想,能否有一種簡易判斷的 “準則”,來決定使用案例是一個或多個呢? 老實說,從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義,我仍不容易釐出那個準則,所以我是想透過觀察使用案例的行為,來找出那個判斷的原則為何。

先觀察實體書店一般的購物程序:客戶走入書店,瀏覽與選擇欲購買的商品 (書籍),並放入購物籃內 (拿在手裡也算,代表已準備好欲購買的商品),並拿到櫃臺,結帳並付款。

所以幾個使用案例呢? 我肯定是認為一個:《購買商品》,因為客戶來這個系統 (實體書店)的主要目的就是 購買商品,而為了滿足該目的,他必須經常放入購物籃、結帳等程序,而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的,約幾分鐘到幾個小時就可以完成 (注意此點)。關於傳統書店使用案例圖的表達,可以參考下圖1。

圖 1、實體書店購買商品的使用案例圖
圖 1、實體書店購買商品的使用案例圖

在使用案例圖的表達上,看起來好像是三個使用案例,其實本質上只有一個:《購買商品》。這裡利用《include》這個 stereo type,只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。

再回到博X來網路訂購系統來看,那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢? 看起來很像,都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣,放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢? 當客戶瀏覽商品資訊,若是看到打算購買的商品,就把它放入到購物車內,但是客戶並不需要馬上結帳,他可以等過幾天再決定是否結帳。所以很明顯的觀察到,這是兩個可以在不同時間點個別可以獨立完成的交易 (這一點與實體書店不一樣)。 (不過,這兩個交易事件好像又有些關連存在,要 結帳 前必須先有商品 放入購物車,關於此點,留待後述來討論。)

所以,我的觀察與心得是什麼? 我會以為,若是可以獨立在某個時間點可以完成的交易事件,我會把它就視為是一個使用案例。或者再用更通俗的一句話來說,就是參與者在使用這個系統,從上線到離開的過程,可以 “一氣呵成” 地來完成一個功能案例,該功能案例就可以獨立成為一個使用案例。 所以,博X來訂購系統對於 訂購商品 的主要目標上,會有幾個使用案例? 我是會把它切為兩個:《訂購商品》與《結帳商品》,參考下圖2。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal