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

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

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

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

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

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

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

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

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

圖 2、博X來訂購商品與結帳的使用案例圖

為何使用案例是命名為《訂購商品》而不是 放入購物車？ 我會從 參與者 (Actor,本案例為客戶)的角度來看，客戶的目的是訂購商品，而放入購物車只是在訂購程序中的其中一個子程序。同樣地，這裡也是利用《include》來特別凸顯 放入購物車 這個重要且必要的程序； 而在《結帳商品》這個使用案例，客戶的目的的確就是要處理結帳，所以命名上這樣是適合的。但是因為如前所述，這兩個使用案例又有某些關連存在，可否使用《include》來表達這兩個使用案例的關係？ 不可，絕對不可！！ 我很肯定此點，從使用案例圖來看時的一個最大迷思就是，許多 RA 會以為被《include》的那個使用案例是另外一個使用案例，其實不是。 再強調一次，參考如圖2所示，《訂購商品》 “包含 (include)” 《放入購物車》，它們是同一個使用案例！ 要表達兩個完整獨立使用案例的先後順序關係其實很簡單，就是在《結帳商品》這個使用案例敘述的 precondition 欄位中，說明使用該使用案例前，必須先完成《訂購商品》的使用案例即可。或者也可以直接這樣描述：要使用這個使用案例前，在該用戶的購物車內必須要有待結帳的商品。

另外，依照該訂購系統的實際結帳程序來看，我也會在案例圖上特別來凸顯兩個子程序： 選擇付款方式 與 更新基本資料。 前者是必然需要執行的程序，所以是利用《include》來表達；而 更新基本資訊 則是不一定需要執行，所以是利用《extend》來表達它是一個可具選擇性 (option)的子程序。 然後在 選擇付款方式 這個子程序上，因為它可以具有多樣化的付款方式，所以在該子程序的文字敘述上，只會在這個子程序上描述付款的基本行為，然後會在各種的付款案例上再來描述個別的付款行為。利用《extend》來關連主程序會來得有彈性許多，未來若是又有新的付款方式的需求，那麼只要再加上一個特殊化的子案例即可。

利用 “一氣呵成” 這個原則來判斷是否為獨立的使用案例時，要注意的前提是：系統必須是軟體資訊系統，而不能是企業，也就是把企業當作系統來看待。 探究其原因就是對於所謂什麼才叫做是一個完整獨立的交易事件，軟體資訊系統與企業的界定方式並不一樣。 在軟體資訊系統，一個獨立的交易事件可以是幾分鐘到幾小時，但是再長似乎就不適合了 (事實上，對於 EC 系統，連幾個小時都可能不恰當，交易時間仍嫌太長)。而對於企業層級的使用案例，所延續的時間會相當長，甚至可能長達數十天、數個月。例如把「信仁慈善醫院」當系統，《看病》是一個完整的使用案例，但是看病的過程可能包括了掛號、看診、領藥等，這些程序可以綿延好幾天，所以利用 “一氣呵成” 來判斷就不適用了。那麼要如何判斷企業層級的使用案例呢？ 我是以為，從使用案例的 “價值” 來判斷，可能會比較恰當。想想看，雖然是「信仁慈善醫院」，但它仍需要要營收，而營收的主要來源正是病人來看病所得來的，所以 “看病”，會是一個很明顯有價值的企業層級的使用案例。

※ 延伸參考：
　o 再論 博X來「選擇 7-11 門市」功能設計
　o 實在難以忍受的網路購書流程