在軟件開發(fā)和產(chǎn)品管理領(lǐng)域，用例（Use Case）是一種常用的需求分析和描述方法。它通過描述用戶與系統(tǒng)之間的交互來定義系統(tǒng)的功能和行為。這篇文章，我們來學(xué)習(xí)一下。

用例（Use Case）是一種描述需求的方法。運(yùn)用用例這種方法來描述需求稱之為用例建模。用例也是UML規(guī)范中的一種標(biāo)準(zhǔn)化的需求表達(dá)方式，其中比較有名的RUP（Rational Unified Process，統(tǒng)一軟件開發(fā)過程）就是以用例來驅(qū)動(dòng)的。

值得一提的是，雖然RUP被認(rèn)為是一種重量級的軟件管理過程，而越來越多的軟件開發(fā)開始采用敏捷方法來響應(yīng)瞬息萬變的需求變化。但是用例作為一種描述需求的方式，其理念和方法論對我們分析需求還是有一定的幫助。

從表達(dá)方式上看，用例相對時(shí)序圖、流程圖等需求表達(dá)方式，更加面向?qū)ο蠛兔嫦蛟O(shè)計(jì)。通常情況下，用例比較容易讓沒有受過專業(yè)培訓(xùn)的人員接受。用例可以作為一種跟用戶或者行外人員陳述需求的方式。

01 用例是什么

用例是一種描述需求的方法，用例描述了在不同的條件下，系統(tǒng)對參與者的請求做出的響應(yīng)。用例通常通過一個(gè)參與者（Actor）（誰？）向系統(tǒng)做出請求（要做什么？），系統(tǒng)根據(jù)參與者的請求，在不同的條件下，執(zhí)行某一行為序列（系統(tǒng)怎么滿足？）。每一個(gè)行為序列可以稱之為一個(gè)場景（Scenario），一個(gè)用例包含多個(gè)場景。場景也可以稱之為用例的一個(gè)實(shí)例（Instance）。

02 用例的組成

正式的用例應(yīng)該包括：用例名、概述、范圍、級別、主參與者、項(xiàng)目相關(guān)人員和利益、前置條件、最小保證、成功保證、觸發(fā)事件、主成功場景、擴(kuò)展場景和相關(guān)信息等等。

各個(gè)組成部分的意義如下：

• 用例名（Title）：<用例目標(biāo)>
• 概述（Goal in Context）：<要描述用例流程和目標(biāo)>
• 范圍（Scope）：<設(shè)計(jì)范圍>
• 級別（Level）：<概要、用戶目標(biāo)、子功能>
• 主執(zhí)行者（Primary Actor）：<主執(zhí)行者或角色>
• 項(xiàng)目相關(guān)人員和利益（Stakeholders and Interests）：<項(xiàng)目相關(guān)人和主要利益列表>
• 前置條件 （Precondition）：<已經(jīng)達(dá)到的條件>
• 最小保證（Minimal Guarantees）：<用例必須執(zhí)行的信息>
• 成功保證（Success Guarantees）：<目標(biāo)完成時(shí)執(zhí)行的信息>
• 觸發(fā)事件（Trigger）：<觸發(fā)了用例的事件>
• 主成功場景（Main Success Scenario）：<目標(biāo)完成的主要步驟>
• 擴(kuò)展（Extensions）：<可能出現(xiàn)的其他步驟，包括異常情況>

03 用例的格式

用例可以用于不同的目的，如：

• 描述需求，便于和用戶溝通需求。
• 描述業(yè)務(wù)的過程，指導(dǎo)項(xiàng)目開發(fā)。
• 記錄需求討論過程，并最終文檔化。

不同的編寫目的導(dǎo)致了用例在編寫過程中有可能出現(xiàn)不同的側(cè)重點(diǎn)。

在不同的團(tuán)隊(duì)情況也可能導(dǎo)致用例書寫的不一樣。比如在一個(gè)大型的開發(fā)項(xiàng)目組里，就需要嚴(yán)格的按照用例范例進(jìn)行描述，而在一個(gè)小型的溝通頻繁的項(xiàng)目組里，則可以采用一種比較簡單的描述方式。

上文提到的是比較常見的組成部分。事實(shí)上，用例的格式并沒有硬性規(guī)定，在必要時(shí)可以增減里面的信息。具體用例需要包括哪些信息，有不同的流派。有興趣可以查看相關(guān)資料，這里不展開講。

一句話概括： 你的用例不是我的用例，只有適合的用例才是最好的。

04 需求和用例

用例用于表述需求，但是有兩點(diǎn)要注意的：

• 用例就是需求。 不需要將用例轉(zhuǎn)化成其他的需求表達(dá)方式。用例可以完整的描述系統(tǒng)需求。
• 用例不一定是所有需求。 用例只是需求的一部分，用例并不描述外部接口、數(shù)據(jù)格式、業(yè)務(wù)規(guī)則、性能、可維護(hù)性等需求。

05 用例組成部分

1. 用例名（Title）

用例名用于標(biāo)識(shí)一個(gè)用例，便于匯總和閱讀。

規(guī)則：使用主動(dòng)語態(tài)的動(dòng)賓短語來描述。

一般情況下，建議使用主動(dòng)語態(tài)的動(dòng)賓短語來描述用例的目標(biāo)。如：“查找商品”、“加入購物車”。在某些情況下，如需要更準(zhǔn)確的表示出一個(gè)用例，可以加入定語進(jìn)行修飾，如：“用戶清除購物車”、“管理員清除購物車”。

規(guī)則：以主參與者為對象進(jìn)行描述。

用例的描述需要以主參與者為對象進(jìn)行描述，如可以使用“支付訂單”（以主參與者為對象），而不是“收取訂單費(fèi)用”(以系統(tǒng)為對象)。

【舉例】

用例1：購買商品

……

2. 范圍（Scope）

用例的范圍能讓我們對系統(tǒng)的邊界和討論的需求有一個(gè)基礎(chǔ)的語境，不同的設(shè)計(jì)范圍可能會(huì)導(dǎo)致我們需要討論的參與者、場景都會(huì)不一樣。簡單來講，就是為我們討論的系統(tǒng)劃定一個(gè)范圍確定我們討論的界線。

例如我們要討論一個(gè)用戶的下單行為。如果以整個(gè)企業(yè)為范圍，其項(xiàng)目的相關(guān)人員為用戶、第三方服務(wù)者（如快遞等）。但如果以系統(tǒng)為范圍，其項(xiàng)目相關(guān)人員還應(yīng)該包括企業(yè)內(nèi)部的系統(tǒng)管理員、客服等。

所以，在編寫用例時(shí)需要搞清楚，我們的用例的范圍是什么，這樣可以對用例討論的問題達(dá)成一個(gè)共識(shí)。

1）功能范圍

在討論用例的設(shè)計(jì)范圍時(shí)，需要先確定系統(tǒng)的功能范圍。Cockburn在《編寫有效用例》里面推薦了一個(gè)確定功能范圍的方式“內(nèi)/外列表”。

確定功能范圍的好處是顯而易見。如，系統(tǒng)外部已經(jīng)有了一個(gè)打印訂單的系統(tǒng)，如果不明確區(qū)分系統(tǒng)的功能范圍，部分開發(fā)人員有可能會(huì)對打印訂單功能進(jìn)行設(shè)計(jì)和實(shí)現(xiàn)。而事實(shí)上，這些功能是不需要設(shè)計(jì)的。

明確了功能范圍后，還可以確認(rèn)系統(tǒng)的執(zhí)行人員。如上面的例子，打印訂單系統(tǒng)將作為“打印訂單”用例的輔助執(zhí)行者。

2）設(shè)計(jì)范圍

設(shè)計(jì)范圍是在功能范圍確定了之后做的。設(shè)計(jì)范圍指的是我們在編寫用例時(shí)討論問題的邊界和對象。我們在用例里面說的范圍（Scope）如果沒有特殊說明指的就是設(shè)計(jì)范圍（而不是功能范圍）。

下面來看一個(gè)例子，ECom公司打算做一個(gè)ESys的系統(tǒng)，系統(tǒng)里面包括了ESubSys等多個(gè)子系統(tǒng)。

設(shè)計(jì)范圍的大小

如果以ECom為設(shè)計(jì)范圍來討論用例，我們關(guān)心的是用戶對公司的需求是什么，公司以什么樣的形式滿足用戶的請求。如果有外部公司，則還要考慮外部公司與公司之間往來的業(yè)務(wù)是什么。

如果以ESys為設(shè)計(jì)范圍來討論用例，我們更關(guān)心用戶向系統(tǒng)發(fā)起的請求和系統(tǒng)對請求的響應(yīng)。同時(shí)，如果以ESys做范圍的時(shí)候，企業(yè)內(nèi)部的員工也成了用例的執(zhí)行者，我們還應(yīng)該考慮員工對系統(tǒng)的請求。

確定用例范圍，能很好的對其我們要討論的問題是什么，界定我們討論問題的范圍，給用例一個(gè)語言環(huán)境。

規(guī)則：設(shè)計(jì)范圍是一個(gè)簡單的專有名稱。

用例的范圍應(yīng)該是一個(gè)簡單的專用名詞，簡單說明一下用例討論的范圍界線。如，上面的例子中范圍可以直接用“ECom”、“ESys”、“ESubSys”來表示。

【舉例】

用例1：購買商品

范圍:電商系統(tǒng)

……

3. 主執(zhí)行者（Primary Actor）

主執(zhí)行者是系統(tǒng)相關(guān)人員中，請求系統(tǒng)做出響應(yīng)的人或物。主執(zhí)行者是對系統(tǒng)請求的發(fā)起者，主執(zhí)行者可以不是直接操作系統(tǒng)的相關(guān)人員。

其中一種情況下是主執(zhí)行者通過另一個(gè)系統(tǒng)操作相關(guān)人員對系統(tǒng)進(jìn)行操作。如，客戶致電客服查詢異常訂單的場景?？蛻舨]有直接通過系統(tǒng)進(jìn)行查詢。

另一種情況是定時(shí)觸發(fā)任務(wù)。如客戶希望系統(tǒng)定時(shí)執(zhí)行一個(gè)任務(wù)，那么最終執(zhí)行系統(tǒng)的相關(guān)人員是系統(tǒng)本身。

雖然識(shí)別出主執(zhí)行者很重要，可是在有些時(shí)候主執(zhí)行者也沒那么重要。

在編寫用例時(shí)，識(shí)別出主執(zhí)行者，可以從執(zhí)行者角度出發(fā)，充分梳理系統(tǒng)需求。我們還可以主執(zhí)行者的特點(diǎn)來設(shè)計(jì)系統(tǒng)的交互。如下表，主執(zhí)行者概括表：

在多數(shù)情況下，我們開始編寫用例開始后，主執(zhí)行者就變得沒那么重要了。例如，當(dāng)我們在設(shè)計(jì)查詢訂單用例時(shí)，無論是管理員、經(jīng)理、客服甚至是其他的公司職位，在查詢訂單這個(gè)用例上并沒有特別的差異。這個(gè)時(shí)候，主執(zhí)行者具體是誰已經(jīng)不重要了。

規(guī)則：用例的主執(zhí)行者可以是執(zhí)行者或者執(zhí)行者角色。

在上述情況下，我們會(huì)將部分主執(zhí)行者一般化的方式，創(chuàng)建一個(gè)“角色-執(zhí)行者對應(yīng)表”。在上述用例里，我們將管理員、經(jīng)理等一般化為一個(gè)操作角色——訂單管理者。我們在描寫用例時(shí)，以角色作為主執(zhí)行者即可。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

范圍：電商系統(tǒng) ……

4. 概述（Goal in Context）

概述主要用于描述用例的目標(biāo)，也就是用戶需要完成的目標(biāo)。

規(guī)則：使用自然語言描述。

盡量使用自然的語言闡述用戶要完成目標(biāo)時(shí)，用戶會(huì)做什么事情。

規(guī)則：描述用例實(shí)現(xiàn)什么，而不描述系統(tǒng)步驟。

只需要講清楚用例需要完成的事情即可，這里不需要描述系統(tǒng)步驟或者用戶的具體操作流程。

如：“用戶選擇一件需要購買的商品后，可以將商品加入購物車，然后在購物車?yán)锩嫣峤挥唵巍Ｓ脩粢部梢圆恍枰尤胭徫镘?，直接購買選中的商品?！备攀霾⒉恍枰枋鼍唧w的系統(tǒng)操作，在這里并沒有描述“點(diǎn)擊加入購物車按鈕”等系統(tǒng)的操作細(xì)節(jié)。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。 范圍：電商系統(tǒng) ……

5. 相關(guān)人員和利益（Stakeholders and Interests）

項(xiàng)目的相關(guān)人員是指對系統(tǒng)有特定利益的參與者。相關(guān)人員不一定是人，也可以是一個(gè)外部系統(tǒng)、一個(gè)組織等。

所以能成為項(xiàng)目相關(guān)人員的有可能是：

• 使用或關(guān)注系統(tǒng)的外部人或物。
• 用例的主執(zhí)行者。
• 用例的輔助執(zhí)行者。
• 系統(tǒng)內(nèi)部執(zhí)行者。
• 被設(shè)計(jì)的系統(tǒng)本身。

1）主執(zhí)行者

主執(zhí)行者是發(fā)起執(zhí)行用例的相關(guān)人員。

2）輔助執(zhí)行者

輔助執(zhí)行者是為被設(shè)計(jì)的系統(tǒng)執(zhí)行服務(wù)的的外部執(zhí)行人員。輔助執(zhí)行者可以是另外一個(gè)系統(tǒng)、也可以是一個(gè)人或組織。如，一臺(tái)打印機(jī)，為系統(tǒng)打印各種票據(jù)。再如，快遞公司，為系統(tǒng)提供快遞服務(wù)，并提供物流信息。

3）內(nèi)部執(zhí)行者

內(nèi)部執(zhí)行者是在系統(tǒng)內(nèi)部關(guān)注系統(tǒng)利益的相關(guān)人員。

4）被設(shè)計(jì)的系統(tǒng)

被設(shè)計(jì)的系統(tǒng)本身有時(shí)候?qū)ψ约阂彩怯刑囟ɡ娴摹?/p>

對于相關(guān)人員，有幾點(diǎn)需要說明：

1. 系統(tǒng)相關(guān)人員有可能不直接和系統(tǒng)交互。 例如，公司管理者，可能不會(huì)親自操作系統(tǒng)，可是對系統(tǒng)運(yùn)行的狀況和其他運(yùn)營數(shù)據(jù)卻是十分關(guān)注的。這些相關(guān)人員在系統(tǒng)操作步驟中可能不會(huì)出現(xiàn)，但是用例還是需要描述對這部分相關(guān)人員的利益。
2. 關(guān)注“沉默的”相關(guān)人員。 系統(tǒng)相關(guān)人員有時(shí)候并不是那么明顯。比如上文提到的，有些相關(guān)人員并不是直接操作系統(tǒng)的人員。往往是這些“沉默”的相關(guān)人員考慮不足，正是系統(tǒng)后期需求頻繁改動(dòng)的原因之一。

規(guī)則：相關(guān)人員和利益用以對應(yīng)列表的方式書寫。

使用”<相關(guān)人員>：<利益>”的方式，描寫相關(guān)人員和其關(guān)注的利益。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。 范圍：電商系統(tǒng)

……

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

……

6. 級別（Level）

在編寫用例過程中，我們有時(shí)會(huì)具體描述一個(gè)用戶的需求（如用戶購買商品），有時(shí)候會(huì)描述一個(gè)系統(tǒng)的具體功能（如用戶登陸），有時(shí)候會(huì)描述一個(gè)流程（如購買商品并獲得商品的流程）。在編寫用例的時(shí)候，知道用例所處的位置，對我們編寫和理解用例有很大的幫助。

我們將用例級別從總到分劃分成了三個(gè)層次：概要、用戶目標(biāo)、子功能。

1) 用戶目標(biāo)

用戶目標(biāo)是指主執(zhí)行者使用系統(tǒng)期望獲得的目標(biāo)。用戶目標(biāo)是我們編寫用例的重點(diǎn)。用戶目標(biāo)描述了主執(zhí)行者通過系統(tǒng)“做一件什么事”，以及做完這件事后“用戶能獲取什么利益”。

用戶目標(biāo)應(yīng)該是主執(zhí)行者一次執(zhí)行系統(tǒng)獲取利益的過程。所以，不是一次執(zhí)行所能完成的目標(biāo)，或者用戶不能獲得利益的需求不能稱為用戶目標(biāo)。

如，購買一個(gè)商品的流程，這個(gè)從下訂單到快遞需要幾天的過程，所以不能稱為一個(gè)用戶目標(biāo)。再如，用戶登陸，用戶登陸并不能獲取什么利益，所以也不能稱為一個(gè)用戶目標(biāo)。用戶下單這個(gè)操作，可以作為一個(gè)用戶目標(biāo)。

2) 概要

概要層次可以包含多個(gè)用戶目標(biāo)，概要目標(biāo)執(zhí)行周期比用戶目標(biāo)更長，可以是一個(gè)幾天、幾個(gè)月甚至更長的過程。概要目標(biāo)有三個(gè)目的：

• 為用戶目標(biāo)提供一個(gè)運(yùn)行的語境。如，明確用戶目標(biāo)是在討論下單流程。
• 顯示用戶目標(biāo)之間的前后順序。如，明確下單用例、查詢快遞用例、簽收訂單用例之間的前后順序。
• 作為多個(gè)用戶目標(biāo)的匯總。如，下單流程匯總了多個(gè)相關(guān)的用戶目標(biāo)。

3) 子功能

子功能層次是用戶目標(biāo)在執(zhí)行過程中會(huì)執(zhí)行到的目標(biāo)。如，一次登陸，一次訂單打印等。也有可能存在多個(gè)用戶目標(biāo)共用一個(gè)子功能，如查找商品、查找訂單等。

子功能用例的存在是為了用戶目標(biāo)用例增加可讀性而存在的。在實(shí)際編寫過程中，不到迫不得已，不要設(shè)計(jì)子功能層出用例。

規(guī)則：層次只有三個(gè)選項(xiàng)：概要、用戶目標(biāo)、子功能。

用例的層次只能是概要、用戶目標(biāo)、子功能三個(gè)之中的一個(gè)層次。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。 范圍：電商系統(tǒng)

級別：用戶目標(biāo)

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

……

7. 前置條件（Precondition）

前置條件是我們在用例執(zhí)行之前期望必須成功的條件。在用例編寫過程中，可以不對該條件進(jìn)行檢查和討論。如，“下訂單”必須依賴于“用戶已經(jīng)登陸”這個(gè)前置條件。

規(guī)則：前置條件必須是用例執(zhí)行前我們期望一定成功的條件。

要預(yù)防將那些并不是必須條件的條件寫入前置條件。如，取消訂單并不依賴于用戶下單成功，事實(shí)上，用戶可以將下單不成功（例如支付失?。┑挠唵稳∠?。而訂單下單是否成功這個(gè)條件是需要在用例里面對這個(gè)條件進(jìn)行檢查并執(zhí)行不通過動(dòng)作的。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。 范圍：電商系統(tǒng)

級別：用戶目標(biāo)

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

前置條件：用戶已經(jīng)登陸系統(tǒng)。

……

8. 最小保證（Minimal Guarantees）

最小保證是用例執(zhí)行無論是否成功都會(huì)被執(zhí)行的保證。雖然，用例無論執(zhí)行成功與否，最小保證總會(huì)被執(zhí)行。但是，最小保證更多的是為用例執(zhí)行失敗情況下，為用例相關(guān)人員提供的利益保證。最小保證可以有多個(gè)。

一個(gè)常見的最小保證例子是“系統(tǒng)將用戶執(zhí)行記錄日志”，就算用例執(zhí)行失敗，用戶的操作也將會(huì)被記錄到日志里面。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。 范圍：電商系統(tǒng)

級別：用戶目標(biāo)

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

前置條件：用戶已經(jīng)登陸系統(tǒng)。

最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。

……

9. 成功保證（Success Guarantees）

成功保證是指用例執(zhí)行成功后，用戶所能得到的利益保證。相關(guān)人員的利益能否得到保證，是用例執(zhí)行成功的判定條件。成功保證可以有多個(gè)。

例如，在下訂單用例中，用戶下單成功后，必須保證“訂單被創(chuàng)建，并提交到后臺(tái)處理?！?/p>

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。 范圍：電商系統(tǒng)

級別：用戶目標(biāo)

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

前置條件：用戶已經(jīng)登陸系統(tǒng)。

最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。

成功保證：

1. 系統(tǒng)成功創(chuàng)建用戶訂單。

2. 系統(tǒng)收到用戶支付貨款。

3. 用戶的訂單操作和付款信息被記錄成日志。

……

10. 觸發(fā)事件（Trigger）

觸發(fā)事件是指用例啟動(dòng)的事件，用例將通過觸發(fā)事件，開始一步一步執(zhí)行。

規(guī)則：觸發(fā)事件是跟系統(tǒng)交互的第一個(gè)操作。

以用戶下單用例為例子，用戶決定要購買商品后，在系統(tǒng)中查找商品并下單。那么“用戶決定要購買商品”并不能作為用例的觸發(fā)事件，事實(shí)上，用戶更系統(tǒng)的交互是從“查找商品”開始的，所以“用戶查找商品”才是用例的觸發(fā)事件。

我們討論用戶跟系統(tǒng)交互時(shí)，還應(yīng)該注意我們討論的系統(tǒng)的范圍。特別是當(dāng)主執(zhí)行者不是直接操作軟件系統(tǒng)的場景時(shí)，更應(yīng)該明確系統(tǒng)范圍。如，“用戶致電客戶經(jīng)理下單”這樣的場景下，我們的系統(tǒng)范圍并不能限定在軟件系統(tǒng)范圍內(nèi)，這是系統(tǒng)范圍是公司。所以，“用戶致電客戶經(jīng)理”跟我們系統(tǒng)交互的第一步，所以可以成為“觸發(fā)事件”。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。

范圍：電商系統(tǒng)

級別：用戶目標(biāo)

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

前置條件：用戶已經(jīng)登陸系統(tǒng)。

最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。

成功保證：

1. 系統(tǒng)成功創(chuàng)建用戶訂單。

2. 系統(tǒng)收到用戶支付貨款。

3. 用戶的訂單操作和付款信息被記錄成日志。

觸發(fā)事件：用戶選中需要購買的物品。

……

11. 主成功場景（Main Success Scenario）

主成功場景是用例從觸發(fā)事件開始，一步一步執(zhí)行，最終滿足用例利益的步驟集合。

主成功場景應(yīng)該包括以下信息：

• 兩個(gè)執(zhí)行者之間的交互。如，用戶提交了訂單。
• 為保證主成功場景得以繼續(xù)的確認(rèn)。如，系統(tǒng)確認(rèn)用戶密碼。
• 主成功場景推進(jìn)過程中的內(nèi)部變化。如，系統(tǒng)扣除用戶賬戶余額。

執(zhí)行步驟應(yīng)該有一些簡單的規(guī)則：

規(guī)則：使用簡單語法。

使用簡單語法結(jié)構(gòu)：

主語……謂語動(dòng)詞……前置短語……賓語。

例如：

系統(tǒng)……扣除…一定數(shù)量的…用戶賬戶余額。

規(guī)則：準(zhǔn)確描述執(zhí)行者之間的切換。

執(zhí)行步驟需要準(zhǔn)確描述步驟執(zhí)行過程中，執(zhí)行者之間的切換。如，“用戶致電客戶代表”，我們可以知道步驟已經(jīng)從用戶切換到了客戶代表。

但是，有時(shí)候在執(zhí)行者明確的情況下，也有可能不會(huì)出現(xiàn)在句子中。如，“用戶輸入密碼”，我們也可以知道這個(gè)步驟的執(zhí)行者已經(jīng)從用戶切換到了系統(tǒng)。我們不必使用“用戶向系統(tǒng)輸入密碼”這種冗余的描述方式。

規(guī)則：從系統(tǒng)外去描述步驟。

不應(yīng)該從系統(tǒng)內(nèi)部，或者全部以系統(tǒng)角度去考慮而已。而應(yīng)該從系統(tǒng)外去描述步驟。

如果從系統(tǒng)內(nèi)部去描述步驟，可能會(huì)寫成：

讀取用戶密碼，確認(rèn)密碼正確。

如果在系統(tǒng)外部去描述步驟，則表述成：

用戶輸入密碼。 系統(tǒng)確認(rèn)用戶密碼正確。

規(guī)則：顯示過程向前推移。

一些小的步驟只能完成少數(shù)工作，有時(shí)候這些工作并不能很好的描述過程在向前推移。如，“用戶點(diǎn)擊了確定按鈕”。這個(gè)步驟并不能很好的描述過程在向前推移，用戶的真實(shí)目的是登陸系統(tǒng)，隨著用戶登陸系統(tǒng)，用例步驟可以繼續(xù)往下執(zhí)行。

規(guī)則：顯示執(zhí)行者的意圖，而不是動(dòng)作。

執(zhí)行者通常是通過操作系統(tǒng)執(zhí)行一個(gè)動(dòng)作的，在描寫用例時(shí)，容易將用戶動(dòng)作和執(zhí)行者的意圖搞混。

例如： 1. 系統(tǒng)要求用戶輸入身份信息 2. 用戶輸入用戶名密碼 3. 用戶點(diǎn)擊確定按鈕 4. 系統(tǒng)確認(rèn)用戶身份信息 ……

用例過多描述了系統(tǒng)操作界面和用戶的動(dòng)作，如“要求用戶輸入身份信息”，這個(gè)并執(zhí)行者的意圖，而只是一個(gè)交互動(dòng)作。

我們可以縮減描述用戶動(dòng)作的步驟，將用例改成：

1.用戶輸入用戶名密碼 2.系統(tǒng)確認(rèn)用戶身份信息。

規(guī)則：包含合理的活動(dòng)集。

描述步驟的時(shí)候，并不一定要求每個(gè)步驟之包括一個(gè)活動(dòng)。根據(jù)需要可以將部分活動(dòng)集合在一個(gè)步驟里面。

如:

用戶下單成功。系統(tǒng)發(fā)送短信給用戶，告知用戶訂單號。

這個(gè)步驟也可以描述成兩個(gè)步驟：

用戶下單成功。 系統(tǒng)發(fā)送短信給用戶，告知用戶訂單號。

用例的描述方式以簡單，有效為主，有時(shí)候并不拘泥于具體的方式。事實(shí)上很多開發(fā)團(tuán)隊(duì)都形成了自己的用例編寫規(guī)范。

規(guī)則：步驟描述成功的場景，而不要體現(xiàn)可能的失敗。

主成功場景的步驟描述的是成功的步驟。例如:

系統(tǒng)判斷用戶信息是否正確。

如果這樣編寫步驟，我們將要繼續(xù)考慮“如果判斷正確……”，“如果判斷失敗……”。但是在主成功場景的步驟中，是不體現(xiàn)失敗的步驟的。所以，需要將步驟改成

系統(tǒng)確認(rèn)用戶信息。

如果如果系統(tǒng)驗(yàn)證失敗怎么辦？這部分信息放到擴(kuò)展里面描述。下文會(huì)詳細(xì)說明，這里不展開。

規(guī)則：當(dāng)步驟不連續(xù)執(zhí)行是，可以加入時(shí)間限制。

多數(shù)情況下，步驟是一步接一步執(zhí)行的。可在某些時(shí)候，可以這樣描述：

當(dāng)用戶選擇直接提交訂單時(shí)，……。

規(guī)則：一個(gè)步驟可以涉及多個(gè)相關(guān)人員。

我們有時(shí)候需要通過一個(gè)系統(tǒng)向另一個(gè)系統(tǒng)發(fā)起一個(gè)執(zhí)行動(dòng)作，可以寫成：

用戶通過系統(tǒng)向物流系統(tǒng)獲取物流數(shù)據(jù)。

規(guī)則：可以反復(fù)執(zhí)行一個(gè)或多個(gè)步驟。

有時(shí)用戶會(huì)反復(fù)執(zhí)行其中一個(gè)或多個(gè)步驟，這時(shí)候需要在步驟中增加一定的描述。如：

1. 用戶查找一個(gè)商品
2. 用戶將商品加入到購物車中。用戶可以重復(fù)1~2步，直至用戶完成商品選購。
3. 用戶選中購物車中的商品下單
……

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。

范圍：電商系統(tǒng)

級別：用戶目標(biāo)

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

前置條件：用戶已經(jīng)登陸系統(tǒng)。

最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。

成功保證：

1. 系統(tǒng)成功創(chuàng)建用戶訂單。

2. 系統(tǒng)收到用戶支付貨款。

3. 用戶的訂單操作和付款信息被記錄成日志。

觸發(fā)事件：用戶選中需要購買的物品。

主成功場景：

1. 用戶輸入需要購買的商品規(guī)格和數(shù)量。

2. 系統(tǒng)確認(rèn)商品規(guī)格和數(shù)量。

3. 系統(tǒng)顯示購買價(jià)格。

4. 用戶完成付款。

5. 系統(tǒng)確認(rèn)收款后，提示用戶下單成功。

……

12. 擴(kuò)展（Extensions）

擴(kuò)展是主成功場景的分支，是指主成功場景在一些其他條件下會(huì)完成的不同動(dòng)作。請注意，使用“擴(kuò)展”而非“異常”或“錯(cuò)誤”，事實(shí)上擴(kuò)展包括了成功和失敗兩種可能的條件。其基本的邏輯是，在執(zhí)行主成功場景時(shí)，如果系統(tǒng)……（檢測到意外），那么，……（做一些事情）。

常見的有可能出現(xiàn)擴(kuò)展的場景如下：

• 另一種可能出現(xiàn)的成功路徑。（如：用戶設(shè)置了自動(dòng)登陸）
• 執(zhí)行者操作錯(cuò)誤。（如：用戶輸入的密碼錯(cuò)誤）
• 執(zhí)行者無任何操作。（如：用戶輸入超時(shí)）
• 需要系統(tǒng)確認(rèn)的場景。（如：系統(tǒng)確認(rèn)用戶余額足夠）
• 輔助執(zhí)行者或其他相關(guān)人員反饋失敗。（如：打印機(jī)執(zhí)行打印錯(cuò)誤）
• 檢測到內(nèi)部錯(cuò)誤，并可能產(chǎn)生外部可見的結(jié)果。（如：寫數(shù)據(jù)失?。?/li>
• 關(guān)鍵性能指標(biāo)不達(dá)標(biāo)。（如：系統(tǒng)超過15秒沒有返回成功）

在這些場景出現(xiàn)后，我們應(yīng)該在擴(kuò)展中描述這些場景處理方式，然后回到主成功場景或者退出用例。

擴(kuò)展是針對主成功場景的，所以我們寫編寫擴(kuò)展的時(shí)候，需要用編號來表明擴(kuò)展的對應(yīng)關(guān)系：

主成功場景如下：

…… 2 系統(tǒng)確認(rèn)用戶密碼正確。 ……

擴(kuò)展如下：

…… 2a 密碼輸入錯(cuò)誤：…… 2b 密碼輸入超時(shí)：…… ……

如果是每個(gè)步驟都可能會(huì)觸發(fā)的擴(kuò)展，可以用”*“號來表示，如：

…… * 用戶關(guān)閉登陸頁面： ……

或者如果是某些步驟觸發(fā)的共有條件，可以加上步驟來表示，如：

…… 2-5* 用戶關(guān)閉登陸頁面： ……

規(guī)則：從系統(tǒng)檢測到的角度去描述擴(kuò)展條件。

擴(kuò)展條件應(yīng)該是系統(tǒng)能檢測到的條件，而不是發(fā)生了什么。如，用戶忘記密碼了，系統(tǒng)不可能檢測到用戶是否密碼或者是其他的什么原因。從系統(tǒng)檢測到的角度去描述，系統(tǒng)只能檢測到用戶輸入錯(cuò)誤的密碼或者用戶輸入超時(shí)。

規(guī)則：合理化合并擴(kuò)展條件。

擴(kuò)展條件事實(shí)上無需枚舉出所有的可能出現(xiàn)的場景，和合理的范圍內(nèi)，我們可以將一些擴(kuò)展條件合并成等價(jià)項(xiàng)。判斷等價(jià)項(xiàng)，有兩個(gè)標(biāo)準(zhǔn)：

• 系統(tǒng)可以檢測到的條件。
• 系統(tǒng)必須完成的條件。

例如，用戶輸入密碼的步驟里面，用戶可以忘記密碼輸入錯(cuò)誤，也可以手誤輸入錯(cuò)誤或者其他的可能性，這些條件都是系統(tǒng)不可以檢測的條件。首先，將這些條件轉(zhuǎn)換成系統(tǒng)可以測試的條件：密碼輸入錯(cuò)誤。轉(zhuǎn)換后，所有條件就可以合并成一個(gè)了。

在來看一下系統(tǒng)可以完成的條件，如，密碼輸入錯(cuò)誤、用戶名錯(cuò)誤、用戶名不存在等，我們系統(tǒng)的處理都是“提示用戶名或密碼錯(cuò)誤或不存在”。這時(shí)候可以將條件合并成“系統(tǒng)檢測到用戶名或密碼輸入錯(cuò)誤”。

還有一種情況，如果在低層級（如子功能級別）用例已經(jīng)完整描述了擴(kuò)展，那么在其高級別（如用戶目標(biāo)級別）用例，可以不用重復(fù)冗余描述。比如，在子功能級別用例“保存數(shù)據(jù)”里面已經(jīng)完整描述了保存過程中可能出現(xiàn)的各種擴(kuò)展條件，那么在其上級用例里就可以不用描述了。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

概述：用戶選中商品后，通過系統(tǒng)下訂單購買商品并支付貨款。不包括管理員處理訂單。

范圍：電商系統(tǒng)

級別：用戶目標(biāo)

項(xiàng)目相關(guān)人員和利益：

用戶：希望通過系統(tǒng)下訂單購買需要他需要的商品。

系統(tǒng)：記錄用戶購買的訂單，以便給訂單管理員處理。

前置條件：用戶已經(jīng)登陸系統(tǒng)。

最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。

成功保證：

1. 系統(tǒng)成功創(chuàng)建用戶訂單。

2. 系統(tǒng)收到用戶支付貨款。

3. 用戶的訂單操作和付款信息被記錄成日志。

觸發(fā)事件：用戶選中需要購買的物品。

主成功場景：

1. 用戶輸入需要購買的商品規(guī)格和數(shù)量。

2. 系統(tǒng)確認(rèn)商品規(guī)格和數(shù)量。

3. 系統(tǒng)顯示購買價(jià)格。

4. 用戶完成付款。

5. 系統(tǒng)確認(rèn)收款后，提示用戶下單成功。

擴(kuò)展：

2a: 數(shù)量不足：

2a1: 提示用戶數(shù)量不足，返回步驟1等待用戶重新輸入。

4a: 用戶余額不足：

4a1: 提示用戶余額不足，要求用戶更換付款方式。

4a2: 用戶更換付款方式繼續(xù)付款。

4b: 用戶支付密碼錯(cuò)誤：

4b1: 提示用戶余額不足，提示用戶重新輸入密碼。

4b2: 用戶重新輸入密碼，完成支付。

4b3: 用戶連續(xù)輸入3次錯(cuò)誤密碼，系統(tǒng)凍結(jié)用戶付款賬戶12個(gè)小時(shí)。

4c: ……

……

06 總結(jié)

用例還能以用例圖的方式來表示。本文主要是通過用例的關(guān)注點(diǎn)和用例的組成來探討一下一種需求的描述方式，所以就不對用例圖召開介紹了。有興趣的同學(xué)可以自行參考其他資料了解。

在敏捷開發(fā)越來越受到推崇的今天，用例這種相對較“重”的需求分析和表達(dá)模式越來越少的被人使用。當(dāng)是我們通過研究用例的關(guān)注點(diǎn)和分析方式，其很多思想還是可以借鑒到我們?nèi)粘５男枨蠓治霎?dāng)中的。

更詳細(xì)的內(nèi)容可以查看《編寫有效用例》（Writing Effective Use Cases ）作者是 Alistair Cockburn。