概要

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

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

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

用例是什么

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

用例的組成

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

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

• 用例名（Title）：<用例目標(biāo)>
• 概述（Goal in Context）：<要描述用例流程和目標(biāo)>
• 范圍（Scope）：<設(shè)計(jì)范圍>
• 級(jí)別（Level）：<概要、用戶目標(biāo)、子功能>
• 主執(zhí)行者（Primary Actort）：<主執(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ā)了用例的事件>
• 主成功場(chǎng)景（Main Success Scenario）：<目標(biāo)完成的主要步驟>
• 擴(kuò)展（Extensions）：<可能出現(xiàn)的其他步驟，包括異常情況>

用例的格式

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

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

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

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

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

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

本文主要觀點(diǎn)均來(lái)自于《編寫有效用例》（Writing Effective Use Cases ）作者是 Alistair Cockburn。有興趣的可以讀一下原著。

需求和用例

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

• 用例確實(shí)是需求。
  不需要將用例轉(zhuǎn)化成其他的需求表達(dá)方式。用例可以完整的描述系統(tǒng)需求。

• 用例不一定是所有需求。
  用例只是需求的一部分，用例并不描述外部接口、數(shù)據(jù)格式、業(yè)務(wù)規(guī)則、性能、可維護(hù)性等需求。

用例組成部分

用例名（Title）

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

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

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

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

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

【舉例】

用例1：購(gòu)買商品
……

范圍（Scope）

用例的范圍能讓我們對(duì)系統(tǒng)的邊界和討論的需求有一個(gè)基礎(chǔ)的語(yǔ)境，不同的設(shè)計(jì)范圍可能會(huì)導(dǎo)致我們需要討論的參與者、場(chǎng)景都會(huì)不一樣。簡(jiǎn)單來(lái)講，就是為我們討論的系統(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í)需要搞清楚，我們的用例的范圍是什么，這樣可以對(duì)用例討論的問(wèn)題達(dá)成一個(gè)共識(shí)。

功能范圍

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

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

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

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

設(shè)計(jì)范圍是在功能范圍確定了之后做的。設(shè)計(jì)范圍指的是我們?cè)诰帉懹美龝r(shí)討論問(wèn)題的邊界和對(duì)象。我們?cè)谟美锩嬲f(shuō)的范圍（Scope）如果沒(méi)有特殊說(shuō)明指的就是設(shè)計(jì)范圍（而不是功能范圍）。

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

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

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

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

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

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

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

【舉例】

用例1：購(gòu)買商品
范圍:電商系統(tǒng)
……

主執(zhí)行者（Primary Actort）

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

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

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

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

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

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

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
范圍：電商系統(tǒng)
……

概述（Goal in Context）

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

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

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

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

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

如：“用戶選擇一件需要購(gòu)買的商品后，可以將商品加入購(gòu)物車，然后在購(gòu)物車?yán)锩嫣峤挥唵巍Ｓ脩粢部梢圆恍枰尤胭?gòu)物車，直接購(gòu)買選中的商品。”概述并不需要描述具體的系統(tǒng)操作，在這里并沒(méi)有描述“點(diǎn)擊加入購(gòu)物車按鈕”等系統(tǒng)的操作細(xì)節(jié)。

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
……

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

概述

項(xiàng)目的相關(guān)人員是指對(duì)系統(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)本身。

主執(zhí)行者

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

輔助執(zhí)行者

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

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

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

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

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

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

1. 系統(tǒng)相關(guān)人員有可能不直接和系統(tǒng)交互。
   例如，公司管理者，可能不會(huì)親自操作系統(tǒng)，可是對(duì)系統(tǒng)運(yùn)行的狀況和其他運(yùn)營(yíng)數(shù)據(jù)卻是十分關(guān)注的。這些相關(guān)人員在系統(tǒng)操作步驟中可能不會(huì)出現(xiàn)，但是用例還是需要描述對(duì)這部分相關(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)人員和利益用以對(duì)應(yīng)列表的方式書寫。

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
……
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
……

級(jí)別（Level）

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

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

用戶目標(biāo)

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

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

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

概要

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

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

子功能

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

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

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
級(jí)別：用戶目標(biāo)
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
……

前置條件（Precondition）

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

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
級(jí)別：用戶目標(biāo)
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
前置條件：用戶已經(jīng)登陸系統(tǒng)。
……

最小保證（Minimal Guarantees）

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
級(jí)別：用戶目標(biāo)
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
前置條件：用戶已經(jīng)登陸系統(tǒng)。
最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。
……

成功保證（Success Guarantees）

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
級(jí)別：用戶目標(biāo)
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
前置條件：用戶已經(jīng)登陸系統(tǒng)。
最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。
成功保證：
1. 系統(tǒng)成功創(chuàng)建用戶訂單。
2. 系統(tǒng)收到用戶支付貨款。
3. 用戶的訂單操作和付款信息被記錄成日志。
……

觸發(fā)事件（Trigger）

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

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

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
級(jí)別：用戶目標(biāo)
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
前置條件：用戶已經(jīng)登陸系統(tǒng)。
最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。
成功保證：
1. 系統(tǒng)成功創(chuàng)建用戶訂單。
2. 系統(tǒng)收到用戶支付貨款。
3. 用戶的訂單操作和付款信息被記錄成日志。
觸發(fā)事件：用戶選中需要購(gòu)買的物品。
……

主成功場(chǎng)景（Main Success Scenario）

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

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

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

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

規(guī)則：使用簡(jiǎn)單語(yǔ)法。

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

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

例如：

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

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

執(zhí)行步驟需要準(zhǔn)確描述步驟執(zhí)行過(guò)程中，執(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ī)則：顯示過(guò)程向前推移。

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

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

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

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

用例過(guò)多描述了系統(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ā)送短信給用戶，告知用戶訂單號(hào)。

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

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

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

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

主成功場(chǎng)景的步驟描述的是成功的步驟。例如:

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

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

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

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

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

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

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

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

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

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

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

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
級(jí)別：用戶目標(biāo)
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
前置條件：用戶已經(jīng)登陸系統(tǒng)。
最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。
成功保證：
1. 系統(tǒng)成功創(chuàng)建用戶訂單。
2. 系統(tǒng)收到用戶支付貨款。
3. 用戶的訂單操作和付款信息被記錄成日志。
觸發(fā)事件：用戶選中需要購(gòu)買的物品。
主成功場(chǎng)景：
1. 用戶輸入需要購(gòu)買的商品規(guī)格和數(shù)量。
2. 系統(tǒng)確認(rèn)商品規(guī)格和數(shù)量。
3. 系統(tǒng)顯示購(gòu)買價(jià)格。
4. 用戶完成付款。
5. 系統(tǒng)確認(rèn)收款后，提示用戶下單成功。
……

擴(kuò)展（Extensions）

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

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

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

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

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

主成功場(chǎng)景如下：

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

擴(kuò)展如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

【舉例】

用例1：購(gòu)買商品
主執(zhí)行者：用戶
概述：用戶選中商品后，通過(guò)系統(tǒng)下訂單購(gòu)買商品并支付貨款。不包括管理員處理訂單。
范圍：電商系統(tǒng)
級(jí)別：用戶目標(biāo)
項(xiàng)目相關(guān)人員和利益：
用戶：希望通過(guò)系統(tǒng)下訂單購(gòu)買需要他需要的商品。
系統(tǒng)：記錄用戶購(gòu)買的訂單，以便給訂單管理員處理。
前置條件：用戶已經(jīng)登陸系統(tǒng)。
最小保證：系統(tǒng)記錄用戶操作進(jìn)度的日志。
成功保證：
1. 系統(tǒng)成功創(chuàng)建用戶訂單。
2. 系統(tǒng)收到用戶支付貨款。
3. 用戶的訂單操作和付款信息被記錄成日志。
觸發(fā)事件：用戶選中需要購(gòu)買的物品。
主成功場(chǎng)景：
1. 用戶輸入需要購(gòu)買的商品規(guī)格和數(shù)量。
2. 系統(tǒng)確認(rèn)商品數(shù)量。
3. 系統(tǒng)顯示購(gòu)買價(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: ……
……

總結(jié)

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

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