如何編寫有效的用例
已發表: 2015-08-21如何編寫有效的用例
用例被廣泛用於記錄業務邏輯和系統流程。 但是對於它們是否有用以及應該如何構建它們有很多意見。 在某些項目中，開發人員從不看用例說它們很冗長，或者他們真的不太了解它們。 業務分析師可以做些什麼來使用例真正有效？
我們大多數人都知道，用例描述了業務流程，並且是系統與特定目標參與者之間交互的規範。 用例文檔不同於需求文檔，也不同於設計文檔。
讓我們看一下需求用例的兩個示例。 你認為他們中的哪一個更好。
示例 – 1
| 用例詳情 | 註釋 |
|---|---|
用例名稱 - 訂單票 | 名字不錯。 它清楚地表明了用例是什麼 |
目標 –客戶成功在網站上預訂足球比賽的門票 描述- 演員訪問網站，查看 | 明確提到了目標和描述。 |
演員——客戶、客戶服務代表 | 所有其他用例細節，例如演員， | 主要流程 - 步驟
包含的用例 - 付款 – 生成預訂 ID 擴展用例 – 生成付款失敗說明 – 打印票 | 主要流程中的步驟很清楚，但 |
備用流程 -取消門票
異常流 - 門票不適用於指定比賽/指定座位 1.系統顯示錯誤信息 | 詳細說明了備用流和異常流。 |
* 用例可以在引用、備用和異常流方面更詳細。 這個例子是為了強調一個寫得很好的用例應該包含什麼。 | |
示例 – 2
| 用例詳情 | 註釋 |
|---|---|
用例名稱——票務訂購  | 該名稱不是從用戶的角度來看的，它看起來像是一個業務流程定義。 |
描述– 演員訪問網站、查看賽程、選擇比賽和座位、預訂門票並支付足球比賽費用 | 缺少用例的目標。 設計人員、測試分析師和開發人員不會理解為什麼必須開發此功能。 |
演員——客戶、客戶服務代表 | 缺少前置條件。 |
主要流程步驟
包含的用例 | 在用例步驟中，有一些對實際 UI 元素的引用可能會使讀者感到困惑。 備用流程寫在主要流程中，這使得很難理解整個流程。 |
這個用例缺乏清晰度和細節，不會幫助團隊正確開發功能。 | |
| 用例中應該包含什麼 | 什麼不應該出現在用例中 |
|---|---|
|
. |
編寫有用用例的一些提示：
- 從參與者的角度編寫用例步驟。
- 用例不應該有設計和架構細節。 它應該專注於業務流程。
- 如果用例中的步驟按時間順序編寫會更好
- 根據需求和復雜性，決定是否需要將 CRUD（創建、讀取、更新和刪除）操作保存在單獨的用例中，或者可以將它們組合在一個用例中。
- 提供對備用流、異常流、包含用例和擴展用例的引用非常重要，這樣業務設計才能完成。
- 選擇一個模板（項目定義、公司定義或任何詳細的模板）並遵循所有用例的結構。
- 擁有用例圖很重要。
- 在敏捷中，我們有用戶故事來捕捉需求。 可以使用精益用例以迭代的方式詳細說明用戶故事。
- 驗證應詳細說明。
在你寫完一個用例之後，問這些問題，如果所有問題的答案都是“是”，它就是一個有效的用例——
- 用戶會知道用例中的業務流程何時執行嗎？
- 是否清楚誰將執行用例的哪個步驟？
- 業務邏輯的描述是否有足夠的信息用於分析、設計、開發和測試？
- 從主要流程到備用流程和異常流程是否有適當的參考？
- 是否有用例圖？
如果用例寫得好，用例是捕獲需求和正式記錄業務流程的有效方法。 應該指導整個團隊使用用例來完成他們的任務。 用例和用例圖是與客戶討論業務流程的好方法。 最好有一個標準的用例模板，其中包含編寫用例的指南。 以這種方式編寫的用例將受到所有項目團隊成員和利益相關者的重視。