到底什麼是 Use Case？

01-14

用例的本質？

用戶目標

用例分析是以產品用戶為中心（user centered）、出發點的需求技術，每一個用例都反映了一個有價值的（valuable）用戶目標（user goal），每一個用例名稱都以動詞片語的形式說明了用戶想要（通過系統）做什麼，完成什麼任務。

其中，用例「提問」的文本如下（採用 @張恂老師的 UUCM 模版）：

用例名稱：提問

層次：!（用戶目標層）
範圍：問答網站（以下簡稱系統）

主用角：
註冊用戶（以下簡稱用戶）
其他干係者：
...

後態：
前態：
用戶已登錄。
觸發事件：
用戶選擇提問。
基本流：

1. 系統顯示新建問題框。
輸入問題 {
2. 用戶輸入問題陳述（字數限制？）；
系統即時驗證用戶輸入的有效性，並提示若干已有答案的類似問題（數量？）以免用戶重複提問。
3. 用戶設定該問題的相關話題。
4. optional
用戶可補充輸入問題說明（背景、條件等詳細信息）。
5. optional
用戶可選擇是否匿名創建問題（預設為非匿名）。

6. 用戶提交問題。
}
7. 系統驗證該問題的有效性。
8. 系統發布該問題，並顯示該問題頁面。
END
擴展流：
用戶未設定話題:7 {

...
}
用戶放棄提問:
...

交互腳本

用例文本是描述軟體用戶與 IT 系統、系統與系統之間的交互腳本，類似於描述各種人物角色之間對話、互動、場景的影視劇腳本（Screenplays or scripts）。其實你把 use case 叫作 use script（使用腳本）也可以。

流與場景

用例的實質內容是用戶使用一個系統功能，從開始（前態），觸發，到一系列的交互步驟，再到結束（後態）的一個完整流程（flow）。這個使用的流程可以叫工作流（work flow）、動作流（action flow）或事件流（event flow）等等。

需求程序

每一個用例的文本描述都是一段「需求程序」（Requirement Program）。

用例的主體內容包括基本流與擴展流，形式上很像編程語言中的一個函式、常式或方法。而擴展流中包括了若干擴展條件，以及針對每個擴展條件的處理流，擴展條件與擴展流很像編程語言中的異常（exceptions）和異常處理程序。

所以，編寫用例文本的過程就像在寫一段需求程序。當然，這個程序不是用大家所熟悉的編程語言編寫的電腦程序，而是用（半）結構化的自然語言編寫的人機交互（或機機交互、系統交互）程序，這個程序（腳本）常常是由用戶與系統共同參與來交互執行，最終實現有價值的用戶目標。

用例文本能否演進成一種專用於描述產品、系統需求的 DSL 呢？有可能。

需求故事

。。。

Use case 是用戶與系統交互的具體文字描述。它在邏輯上跟流程圖有點像，但是流程圖是用圖, 而 use case 是用文字，能表述更多信息。

Use case 和任務分析也有點像，但是 use case 更偏系統，會具體描述用戶與系統的交互行為和系統如何響應。這一點匿名用戶的答案好像是錯的。

在我的理解中，use case是一件事的描述，就是所謂的場景描述。

在產品設計裡面，所有的角色是必須要有一定的場景支撐的，舉個失敗的例子，部分智能家居，如防盜門鎖，就是只考慮特定的場景，而沒有考慮真正的生活場景。

那麼用例是什麼？最大化的模擬角色所處的場景，考慮產品的適用性；

這裡面有幾個誤區：

1、是不是產品要滿足所有的場景？錯，首先想明白產品本質，圍繞本質去想場景，盡量多的滿足，不需要全部滿足。

2、是不是要滿足極端情況？錯，最重要的是防止極端情況發生，比如用戶名輸入個80位這種無意義的。

3、是不是每個用例都要個性化？錯，用例就是為了共性。

設計需要以角色身份去想case，測試則需要通過產品設定的流程去想case與實際的碰撞。

用例Use Case是對一組有目的性的動作序列的抽象描述，用戶為實現自身意圖去和系統發生交互，故而說需求來源於用例。而流程圖則是以圖文的形式更詳細的展現了用戶實現目標的流程步驟以及過程中可能出現的其他干擾情況，他們邏輯相似，表達形式不同卻互為補充。

用例在整個項目團隊的作用不言而喻，它可作為需求依據在產品前期為PM提供思路，亦可在開發和後期測試中作為產品的功能實現效果為他們指明方向..

在UML中，用例是一個圈圈，裡面放一句話，表明一項獨立完整的功能。這是展示給客戶和甲方的，簡單明了。

在軟體工程實踐中，用例其實是用文本方式記錄的，是系統分析師和客戶詳細溝通之後梳理出來的東西。一個用例，簡單的說，就是目標系統執行一項簡單功能的流程，主要描述成功的流程，失敗的流程是補充。UML裡面的一個用例圈圈，對應了下面的一大段描述。

推薦看《Writing Effective Use Case》，我貼其中的一個用例內容作為例子：

USE CASE 1: BUY STOCKS OVER THE WEB

Primary Actor: Purchaser

Scope: Personal Advisors / Finance package ("PAF")

Level: User goal

Stakeholders and Interests:

Purchaser - wants to buy stocks, get them added to the PAF portfolio automatically.

Stock agency - wants full purchase information.

Precondition: User already has PAF open.

Minimal guarantee: sufficient logging information that PAF can detect that something went

wrong and can ask the user to provide details.

Success guarantee: remote web site has acknowledged the purchase, the logs and the user"s

portfolio are updated.

Main success scenario:

1. User selects to buy stocks over the web.

2. PAF gets name of web site to use (E*Trade, Schwabb, etc.) from user.

3. PAF opens web connection to the site, retaining control.

4. User browses and buys stock from the web site.

5. PAF intercepts responses from the web site, and updates the user"s portfolio.

6. PAF shows the user the new portfolio standing.

Extensions:

2a. User wants a web site PAF does not support:

2a1. System gets new suggestion from user, with option to cancel use case.

3a. Web failure of any sort during setup:

3a1. System reports failure to user with advice, backs up to previous step.

3a2. User either backs out of this use case, or tries again.

4a. Computer crashes or gets switched off during purchase transaction:

4a1. (what do we do here?)

4b. Web site does not acknowledge purchase, but puts it on delay:

4b1. PAF logs the delay, sets a timer to ask the user about the outcome.

4b2. (see use case Update questioned purchase)

5a. Web site does not return the needed information from the purchase:

5a1. PAF logs the lack of information, has the user Update questioned purchase.

簡單來說，Use Case就是指用戶通過與系統交互完成特定任務的概述。User Case是設計很前期進行的，不要提及界面內容，它的引入是為了讓設計團隊清楚系統大概是如何實現用戶目標的。

以滴滴打人為例：

1. 我通過應用查找附近保鏢。

2. 我預定了一個保鏢。

3. 獲得保護。

4. 付錢。

那麼這個流程的use case diagram就是這樣的：

聲明：不是抖機靈

這個名詞沒有本質一說。用的人不會去看什麼標準再用這個詞。基本上你所在的團隊用它來指什麼就是什麼。可能是需求，可能是驗收標準，可能是用戶體驗流程，等等。