久久综合图片,97碰碰碰人妻视频无码,欧美人与动牲交大全免费

搜索

APP

起點課堂會員權益

職業(yè)體系課特權

線下行業(yè)大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業(yè)技能直播

會員專屬社群

榮耀標識

發(fā)布

注冊 | 登錄

一種需求的描述方法-用例（Use Case）

林海舟

2024-10-01

0 評論 8986 瀏覽 57 收藏

40 分鐘

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

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

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

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

01 用例是什么

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

02 用例的組成

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

各個組成部分的意義如下：

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

03 用例的格式

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

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

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

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

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

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

04 需求和用例

用例用于表述需求，但是有兩點要注意的：

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

05 用例組成部分

1. 用例名（Title）

用例名用于標識一個用例，便于匯總和閱讀。

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

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

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

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

【舉例】

用例1：購買商品

……

2. 范圍（Scope）

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

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

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

1）功能范圍

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

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

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

2）設計范圍

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

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

設計范圍的大小

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

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

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

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

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

【舉例】

用例1：購買商品

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

……

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

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

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

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

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

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

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

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

4. 概述（Goal in Context）

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

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

盡量使用自然的語言闡述用戶要完成目標時，用戶會做什么事情。

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

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

如：“用戶選擇一件需要購買的商品后，可以將商品加入購物車，然后在購物車里面提交訂單。用戶也可以不需要加入購物車，直接購買選中的商品?！备攀霾⒉恍枰枋鼍唧w的系統(tǒng)操作，在這里并沒有描述“點擊加入購物車按鈕”等系統(tǒng)的操作細節(jié)。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

5. 相關人員和利益（Stakeholders and Interests）

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

所以能成為項目相關人員的有可能是：

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

1）主執(zhí)行者

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

2）輔助執(zhí)行者

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

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

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

4）被設計的系統(tǒng)

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

對于相關人員，有幾點需要說明：

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

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

……

項目相關人員和利益：

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

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

……

6. 級別（Level）

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

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

1) 用戶目標

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

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

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

2) 概要

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

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

3) 子功能

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

子功能用例的存在是為了用戶目標用例增加可讀性而存在的。在實際編寫過程中，不到迫不得已，不要設計子功能層出用例。

規(guī)則：層次只有三個選項：概要、用戶目標、子功能。

用例的層次只能是概要、用戶目標、子功能三個之中的一個層次。

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

級別：用戶目標

項目相關人員和利益：

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

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

……

7. 前置條件（Precondition）

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

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

級別：用戶目標

項目相關人員和利益：

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

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

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

……

8. 最小保證（Minimal Guarantees）

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

級別：用戶目標

項目相關人員和利益：

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

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

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

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

……

9. 成功保證（Success Guarantees）

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

級別：用戶目標

項目相關人員和利益：

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

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

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

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

成功保證：

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

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

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

……

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

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

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

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

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

級別：用戶目標

項目相關人員和利益：

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

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

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

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

成功保證：

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

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

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

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

……

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

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

主成功場景應該包括以下信息：

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

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

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

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

主語……謂語動詞……前置短語……賓語。

例如：

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

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

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

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

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

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

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

讀取用戶密碼，確認密碼正確。

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

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

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

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

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

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

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

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

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

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

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

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

如:

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

這個步驟也可以描述成兩個步驟：

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

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

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

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

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

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

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

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

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

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

當用戶選擇直接提交訂單時，……。

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

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

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

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

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

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

級別：用戶目標

項目相關人員和利益：

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

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

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

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

成功保證：

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

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

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

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

主成功場景：

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

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

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

4. 用戶完成付款。

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

……

12. 擴展（Extensions）

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

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

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

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

擴展是針對主成功場景的，所以我們寫編寫擴展的時候，需要用編號來表明擴展的對應關系：

主成功場景如下：

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

擴展如下：

…… 2a 密碼輸入錯誤：…… 2b 密碼輸入超時：…… ……

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

…… * 用戶關閉登陸頁面： ……

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

…… 2-5* 用戶關閉登陸頁面： ……

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

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

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

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

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

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

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

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

【舉例】

用例1：購買商品

主執(zhí)行者：用戶

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

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

級別：用戶目標

項目相關人員和利益：

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

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

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

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

成功保證：

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

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

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

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

主成功場景：

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

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

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

4. 用戶完成付款。

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

擴展：

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

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

4a: 用戶余額不足：

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

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

4b: 用戶支付密碼錯誤：

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

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

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

4c: ……

……