de_DEen_USes_ESfa_IRfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

引言

在軟體開發快速演變的環境中,敏捷性與結構之間的張力長期以來一直是核心挑戰。數十年來,團隊在冗長的文件(確保完整性但抑制速度)與輕量級的使用者故事(促進速度但常犧牲背景)之間來回搖擺。隨著系統複雜度增加,且快速交付的需求日益強烈,單一極端已無法滿足需求。

現在我們來介紹用例 2.0:一種現代化的需求工程演進,彌補了這項差距。源自傳統用例的基礎原則,但透過敏捷方法論(如 Scrum 與 Kanban)的視角重新構想,用例 2.0 提供了一種輕量但可擴展的方式來捕捉使用者需求。它結合了使用者故事的簡潔性與用例的全面結構,為團隊提供從高階目標到詳細實作的清晰路徑。

Use-Case 2.0: Agile Evolution of Requirements

本案例研究探討用例 2.0 如何轉變需求收集、設計與開發流程。透過檢視其核心原則、實際應用,以及與新興人工智慧輔助開發工具的協同作用,我們展示此方法論如何讓團隊高效地打造正確的系統,確保每個增量都能交付價值。


需求工程的演進

近三十年來,用例一直是需求工程的基石,幫助團隊理解使用者如何與系統互動以達成目標。它啟發了許多現代技術,包括使用者故事。但近年來,一件非凡的事發生了——啟發的方向反過來了。

用例 2.0是新一代的用例驅動開發——輕量、敏捷且精簡,受到使用者故事以及敏捷方法論(Scrum 與 Kanban)的啟發。它代表了傳統用例實務的重大演進,結合了使用者故事的簡潔性與專注性,以及用例始終具備的全面結構與可擴展性。

「用例 2.0 擁有過去所有受歡迎的價值——不僅支援需求,還涵蓋架構、設計、測試與使用者體驗,並在商業建模與軟體重用中扮演關鍵角色。」

什麼讓用例 2.0 不同?

傳統的用例方法論涉及建立詳細的用例文件,以捕捉系統行為,包括簡要描述、前置條件、後置條件與參與者互動。雖然有效,但這種方法常導致文件過於繁重,難以適應敏捷開發的快速迭代。

用例 2.0 在此基礎上進行發展,同時引入多項創新:

  • 敏捷對齊:與敏捷方法論無縫整合,使開發團隊更容易與利害關係人合作、分解需求,並快速迭代

  • 使用者故事整合:將使用者故事納入,作為輕量級捕捉使用者需求並建立共識的方式

  • 用例切片:將複雜的用例拆分成較小、可管理的單元,可獨立實作與測試

  • 視覺模型:強調使用流程圖、活動圖與序列圖,以全面理解系統

  • 迭代開發:在每個組件建構時即進行測試,以實現早期問題偵測

其核心在於,用例 2.0 引入了一個關鍵的新概念:用例切片。切片是從用例中精心挑選出的一個可獨立處理的部分——它不僅切分需求,還貫穿設計、實作、測試案例與測試結果。

Visual representation of Use-Case 2.0 structure showing the relationship between actors, use cases, and slices.

圖1:Use-Case 2.0結構的視覺化呈現,顯示參與者、使用案例與切片之間的關係。


Use-Case 2.0 的六項原則

Ivar Jacobson、Ian Spence 與 Kurt Bittner 提出了六項基本原則,構成成功採用使用案例的基礎:

1. 透過說故事來保持簡單

說故事是最簡單且最有效的溝通系統應如何運作的方式。使用案例捕捉系統的目標,而故事則涵蓋達成這些目標的方法以及途中可能發生問題的處理方式。這使得需求能夠輕鬆地被捕捉、分享與理解。

2. 理解整體圖像

無論你的系統規模大小,理解整體圖像都是至關重要的。若缺乏此整體概觀,團隊將無法正確決策系統的範圍、成本或價值。使用案例圖提供了一種簡單的方法,來呈現系統需求的整體概觀——顯示系統所有可能的使用方式、誰啟動互動,以及任何其他相關方。

A sample use-case diagram illustrating actors and their interactions with the system.

圖2:一個示範使用案例圖,用以說明參與者及其與系統的互動。

3. 聚焦於價值

只有當系統真正被使用時,價值才會產生。與著重於冗長的功能或特性清單不同,使用案例專注於系統如何被使用,以達成特定使用者的具體目標。基本流程描述達成目標的最簡方式,而替代流程則增加選項與錯誤處理機制。團隊可先交付基本流程,再後續加入替代方案——這正是設計上的累加方式。

4. 按切片方式建構系統

大多數系統在可使用之前都需要大量工作。試圖一次性完成整個系統的建構是一項錯誤。相反地,系統應以切片方式建構,每個切片都為使用者帶來明確的價值。

方法很簡單:

  1. 識別系統必須執行的最有用功能

  2. 將其切分成更薄、更易管理的切片

  3. 定義代表這些切片被接受的測試案例

  4. 選擇貫穿整個概念的最核心切片

  5. 由團隊共同評估並開始建構

5. 以增量方式交付系統

軟體系統會經歷多個世代與版本的演進。每個增量都應提供可展示或可用的系統版本。Use-Case 2.0 透過將使用案例切分成工作項目,使其能組合成增量,最終形成發布版本,從而支援此做法。

6. 根據團隊需求進行調整

軟體開發中並無萬能解決方案。不同團隊與情境需要不同的風格與細節層級。Use-Case 2.0 可依需求輕量化——小型協作團隊可使用簡單索引卡上的輕量級使用案例敘述,而大型分散團隊則可使用更詳細的文件。


Use-Case 2.0 的結構:切片、情境與任務

三個關鍵概念定義了 Use-Case 2.0 在實務中的運作方式:

使用案例切片是使用案例中較小且更易管理的組成部分。與在單一文件中定義整個使用案例不同,Use-Case 2.0 將其拆分成更易設計、開發與測試的切片。每個切片代表系統為支援特定使用者任務或目標所必須執行的特定功能。

情境代表使用者在切片內完成任務時可能採取的各種路徑:

  • 正常路徑:預期或標準的操作順序(「順利路徑」)

  • 替代路徑: 可達成相同目標的變體或不同方式

  • 例外路徑: 可能發生的錯誤或異常狀況

任務是使用者在情境中必須執行的具體動作,以達成目標。它們代表構成情境的單獨步驟。

例如,在電子商務平台的「瀏覽產品」用例片段中:

  • 正常路徑: 使用者搜尋、檢視結果、選擇產品、加入購物車,然後進入結帳流程

  • 替代路徑: 使用者選擇不同的付款方式(例如 PayPal 而非信用卡)

  • 例外路徑: 由於資金不足或帳單地址錯誤,付款被拒絕

 

Detailed breakdown of a use-case slice showing normal, alternative, and exception paths.

圖 3:用例片段的詳細分解圖,顯示正常路徑、替代路徑與例外路徑。


用例與使用者故事:為何兩者都重要

這正是 Use-Case 2.0 為常見的敏捷挑戰提供有力解決方案之處。

使用者故事是一個獨立項目——它與其他故事之間沒有內建關係。若產品待辦事項中有 200 個使用者故事,若無如大型故事或主題等額外的分組機制,將難以導航。故事容易失去上下文,團隊也經常過晚撰寫驗收測試。

用例則不同。它將所有相關的故事歸納於同一目標之下,包含:

  • 明確的目標(用例本身)

  • 逐步流程(基本流程)

  • 明確的變異(替代流程)

  • 驗收標準(測試案例)

當您檢視一個用例時,看到的是使用者達成特定目標的完整圖像,而不僅僅是單一片段。

User Stories vs Use Cases
圖 4:對比圖表,突顯使用者故事與用例之間的差異及其互補性。


Use-Case 2.0 在敏捷實務中的應用:實際案例

Use-Case 2.0 為面臨常見挑戰的敏捷團隊提供結構:

電子商務平台: 線上購物系統的用例包括瀏覽產品、搜尋產品、加入購物車、進入結帳流程與完成付款。早期的用例圖可揭示遺漏的流程(例如「訪客結帳」),這些可在 Sprint 承諾前加入,避免生產環境中出現購物車放棄的問題。

行動銀行應用程式: 記錄如「憑證無效 → 多重驗證備援」等替代流程,可及早發現安全漏洞,避免高昂的上線後修補成本,並建立使用者信任。

共乘服務: 使用案例切片推動MVP開發——從請求、接受和付款開始;後續迭代再加入評分和投訴功能。這能實現快速價值交付,並具備明確的優先順序。

醫療預約平台: 利益相關者對使用案例流程的審查揭示了「未到達處理」的需求。可加入自動重新排程功能,可能減少錯過的預約。

Example of an Agile team using use-case slices to plan sprints.

圖5:敏捷團隊使用使用案例切片規劃迭代的範例。


AI的連結:使用案例2.0與AI輔助開發的結合

使用案例2.0最初於2011年開發,遠在AI程式輔助工具出現之前。然而,其原則被證明與AI輔助開發完美契合。

AI程式輔助工具在清晰、結構化的規格下表現最佳。使用案例提供:

  • 讓AI明確理解的目標

  • 讓AI執行的逐步流程

  • 讓AI處理的明確變異

  • 讓AI達成的接受標準

AI輔助開發的四個階段自然對應到使用案例2.0的原則:

  • 啟動 → 「理解整體圖景」——建立商業需求與初步的使用案例圖

  • 詳述 → 「聚焦價值」——撰寫包含基本流程與替代流程的規格

  • 建構 → 「以切片方式建構系統」——使用AI時,工作單元可為完整的使用案例規格,而不僅僅是切片

  • 過渡 → 「以增量方式交付系統」——使用者接受測試確認使用案例滿足利益相關者需求

Illustration of how AI assistants integrate with Use-Case 2.0 workflows.

圖6:AI助理如何與使用案例2.0工作流程整合的示意圖。


開始使用使用案例2.0

你不需要一次就全面採用使用案例2.0的實務。從三件事開始:

  1. 繪製使用案例圖 — 識別系統中的參與者與使用案例。這只需30分鐘,即可獲得整體視野。

  2. 撰寫一個使用案例敘述 — 選擇最重要的使用案例。以項目符號列出基本流程。初期僅以名稱列出替代流程。

  3. 執行你的第一個使用案例 — 不論你使用手動開發或AI協助,都讓使用案例引導你的實作。

您可以使用簡單的電子試算表或便利貼來追蹤使用案例。開始使用使用案例 2.0 時,不需要特別的工具。


結論

使用案例 2.0 不是使用者故事的替代品——而是補充。使用案例為您提供整體視野與結構。測試案例為您提供明確的完成定義。在手動開發中,切片可為您提供恰當規模的工作項目。

關鍵洞察在於,使用案例包含了使用者故事所提供的技術,同時為較大的系統、較大的團隊以及更複雜的開發提供了顯著更多的價值。它們與使用者故事一樣輕量,卻能以平順且結構化的方式擴展,以納入所需的任何細節。最重要的是,它們驅動並連結軟體開發的許多其他面向。

The Integration of AI and Use Case 2.0

在人工智慧正在改變我們建構軟體方式的時代,使用案例 2.0 提供了結構化且以使用者為導向的基礎,確保我們建構的不僅是能運作的系統,而是正確的系統。正確的系統——而不僅僅是能運作的系統。透過採納這種進化的方法論,團隊能在其敏捷旅程中實現更高的清晰度、效率與價值交付。


參考文獻

  1. 使用案例 2.0:需求工程的敏捷演進:使用案例 2.0 原則與實務的全面概述。

  2. 將使用案例與敏捷方法整合:結合使用案例與 Scrum 和 Kanban 的指南。

  3. 使用案例切片的力量:使用案例 2.0 中切片技術的詳細說明。

  4. 人工智慧輔助開發與結構化需求:探討人工智慧工具如何從結構化使用案例中受益。

  5. 敏捷專案中的視覺化模型:在敏捷環境中使用圖表的最佳實務。