許小史

在我上一個章節有談到 (請參閱 客戶需求收集與界定分析-1)，我們會先將客人描述性的需求轉換成條列式需求，再將條列式需求，分別找出名詞、動詞以及受詞，而在名詞的部分，基本上就會是我們在做 UML 的時候所要找的行為者 (Actor)，在上一個章節中看到的範例，基本上我們就能夠找出以下的行為者：

而在條列式需求中找到的受詞，有大部分的可能它就會是 Database、File、System Output...等這類的重要產出，另外也有能會是其他系統、如果發現你的受詞是系統 (注意，這裡說的系統，是指外部系統例如 MES / EAP / WMS / ERP...等，本系統之外的系統一律為外部系統)，那基本上就可以知道，在這裡會有一個通信接口，也就是我們常聽到的 Interface。

因此在這個時候就可以先對這些 Interface 做定義並賦予一個唯一的編號例如 PE01、PM01、MP01...等，一般我們會將系統的第一個字做為編號的一碼，例如找到 MES 會發送信息給 PAS 系統我們就會用 MP 開頭，MP 開頭找到的第一個接口我們就會定義為 MP01，但二個接口會定義為 MP02... 依此類推，這時候可以不需要有內容，內容大約都是在系統分析設計的階段才會明確定義的，但是這時候必須要有接口編號出來，如圖2. 系統接口編號定義表

因此我們在界定條列式需求的時候，可以直接用接口編號來取代描述定義，這樣系統分析的人員更可以直接從客戶需求文件中，一目了然的清晰了解到這裏有一個需要特別注意的地方，並且透由這樣的整理，客戶也會感覺到專業，因此便可更加的放心。

剛剛有談到從主詞中可以找到行為者 (Actor)、再受詞中可以找到 Database、Result、Interface... 等相關系統作業的產出，那動詞呢? 從動詞中，主要就是要找到客戶的需求邏輯，也就是客戶需求的使用個案 (Use Case)，至於 Use Case 有沒有像 Actor、Table 或 Interface 一樣有一個準則呢? 這部分其實沒有一個標準的定義，Use Case 的大小，其實主要還是靠經驗，但是可以知道的是，一個 Use Case 如果在分解強韌分析圖 (Robustness Diagram) 的時候，沒有辦法切出 Boundary、Controller 與 Entity，那就表示切的 Use Case 是有問題的。

以我們目前對於 Use Case 拆解的定義，其實也是有一套準則，就是當你將需求流程拆到最小的單位時，那他就會是一個 Use Case，所謂的最小單位就是指一個需求流程再拆解下去已經沒有意義時，例如圖3. 使用個案示意圖，以「PPM150 RCCP 粗略產能評估」它的需求就是答交組要去進行RCCP粗略產能評估的作業，來確定客人下達的粗略產能能否滿足，當然在要做這一件事情之前，會有一連串的動作，例如展開工單、展 BOM 表、展 MRP...等這些作業，在業務流程 (注意，是流程哦)上它都會是獨立的，所以它們都會被抓出來作為獨立的 Use Case，但是到了最後要進行 RCCP 產能估算這個流程時，再往下細拆就會變成動作了，它就已經不構成需求流程，因此我們拆到這個階段便可，在往下繼續拆解已經沒有太大的意義，這時候他就會形成我們的 Use Case；

至於什麼樣的流程是最小單位呢? 這個當然要看你的系統來定義啦，就跟物件導向的原理一樣，一棵樹是一個物件、一片葉子是一個物件、一塊木頭也是物件，那到底樹木是物件還是樹葉、樹枝、樹幹又或者是整棵樹是物件? 最終還是要看你的系統是什麼樣的系統，如果我做的系統是森林導覽，那物件的單位就是一棵樹，對於樹葉、樹枝、樹幹它都會是屬性；而如果我做的系統是樹木幹細胞研究系統，那物件的單位就有可能小到非常小，甚至連年輪都會被定義成是物件；因此回到我們討論的主題，流程的最小單位還是要看你的系統是什麼樣的系統，以及業務需求來決定你流程的大小，這部分就還是要看業務顧問的經驗了，沒有一個一定的準則可以依循。

在使用個案圖 (Use Case Diagram) 中，可以看到那條件上有寫到「include」，有時候還能看到「Extends」這是什麼意思?

• Include：是要把另外一個 Use Case 包含進來，也就是我要達到我這個 Use Case 之前，我必須要完成另外一個 Use Case 我才有辦法執行我本身的這個 Use Case，這時候就是要用 Include，且 Include 線的箭頭是要往內把另外一個 Use Case 拉進來，以圖5. 為例，PP150 要執行前就需要先 Include PP140、PP460、PP450、PP430才有辦法展開 PP150 的流程。
  舉例：我要去執行買東西這個流程前，我必須要先執行賺錢，或是必須要去執行借錢這個流程，我才有辦法去買東西的這個流程。
• Extends：跟 Include 很像，不過它是延伸的概念，有可能會必須要做，但不是必要會去做的我們會用 Extends，而 Extends 線的箭頭是要往外去延伸，舉例：我要去執行買便當的流程時，有可能我會順便去買飲料，因此買飲料的這個流程，對買便當的流程而言就會是一個 Extends 的延伸關係。

另外還有一般化 (Generalization)，這會比較偏向繼承的概念，在 Use Case 的概念會比較像是標準化的意思，我有一個標準化的流程，有可能在 A、B、C 這三個 Use Case 都會有，這時候我們可以定義一個標準化的 Use Case，讓其他的 Use Case 都 Generalization 這個標準化的 Use Case，這類的 線我比較少用，因為在使用個案中加入這類的線，很容易讓使用者聽得一頭霧水，基本上解釋到最後會讓我有想罵客戶的衝動，所以我這裡基本上是很少用這條的線。

我們設計完 Use Case 之後，針對一個 Use Case 我們應該都要有一個對應的活動圖 (Activity Diagram)，如果我們做的是一個網站或是 UI 系統的化，會再多一個雛形來讓使用者更能夠明白我們在說的東西與內容，一般來說要使用者去看 Use Case 那會是一個很痛苦的過程，對於使用者來說，他們也會覺得你是浪費它的時間，因此對於 Use Case 我們會跟使用者說，它是一個讓你知道你要做甚麼的指引，重點還是要來看 Use Case 裡面的商業流程與 UI，Use Case 我們會比較快速的帶過，讓他先有一個映像便可，等到商業流程與 UI 說明完之後，再回過頭來在說明一次 Use Case 這時候的使用者，他會比較有感覺，抵觸或反彈就不會那麼的大。

因此剛剛也有提到一個 Use Case 基本上會有一個對應的活動圖，這個活動圖主要就是要來描述這個 Use Case 的動作，上面有提到，Use Case 的拆分就是拆解到流程的最小單位，在細拆下去就會變成動作，而這個動作就是活動圖中所要描述的內容，他主要是要描述這個最小單位的流程他有什麼樣的商業流程 (Business Process)，因此他基本上很像流程圖如圖4. 活動圖示意圖，使用者一般也是會用流程圖的角度去理解他。

對於這種流程圖，使用者一般會非常的孰悉，他也可以立即告知你，你的流程尚有什麼樣的問題，這時如果搭配上一個系統雛形的畫面，對於使用者來說，他基本上可以有 80% 的機會可以 Get 到你的信息或你想要表達的內容。所以才會說一個 Use Case 必須要搭配一個活動圖與一個 UI 雛形一起描述，如圖5. 系統雛形示意圖

雛型不一定要是系統介面，也可以透過類似 Microsoft Visio / Power Point 來呈現出你的 UI 畫面，如圖6. 非系統畫面的雛型示意圖，重點是要能表達出你的想法，並且將流程結合起來，這樣使用者一下就能明白你的意思，圖6 的畫面是一個我透由 Microsoft Visio 完成的 UI 雛形。