使用用例和用戶故事捕獲功能需求 - IT 觀察者隨筆

Table of Contents hide

定義新產品、服務、流程或系統的第一步是定義需求，即特定的功能性或非功能性需求。

功能需求描述了產品或服務如何滿足客戶需求。這包括記錄用戶如何與產品或服務交互的用例中的特性和功能。
非功能性需求是有時對用戶來說並不明顯的操作和產品屬性，包括性能、可用性、耐用性、安全性和財務（價格和成本）。

編輯此插圖——功能需求與非功能需求

功能性需求可以被認為是產品需要為客戶做的事情，而非功能性需求可以被認為是產品或服務設計時需要滿足的約束。

功能需求捕獲系統的預期行為。這種行為可以表示為系統需要執行的服務、任務或功能。在軟件開發行業，用例方法已迅速成為捕獲功能需求的廣泛實踐。在它們起源的面向對象和 UML 社區中尤其如此，但它們的適用性並不限於面向對象的系統。

捕獲功能需求的技術是什麼？

功能需求通常以用例或用戶場景的形式捕獲。這些術語有時可以互換使用，但實際上它們的含義略有不同。

用例更多地關注系統以及它必須做什麼才能滿足用戶的需求。
另一方面，用戶故事從用戶的角度展示產品功能，指定用戶角色和他們想要實現的特定目標。

使用用戶故事捕獲功能需求

用戶故事是一種快速捕獲產品需求的“誰”、“什麼”和“為什麼”的輕量級方法。簡而言之，用戶故事是表達用戶想要的需求的想法。用戶故事很短，每個元素通常包含少於 10 或 15 個單詞。用戶故事是“待辦事項”列表，可幫助您確定項目路徑中的步驟。它們有助於確保您的流程和最終產品滿足您的要求。

用戶故事模板

用戶故事僅捕獲需求的基本要素：

它是給誰的？
它對系統的期望是什麼？
為什麼它很重要（可選？）？

以下是 70% 的從業者使用的簡單用戶故事格式：

角色 ——用戶應該是與系統交互的實際人。

要盡可能具體
開發團隊不是用戶

動作 ——系統的行為應該寫成一個動作。

通常每個用戶故事都是獨一無二的
“系統”是隱含的，沒有寫在故事中
主動語態，而不是被動語態（“我可以收到通知”）

收益 ——收益應該是一個真實世界的結果，它是非功能性的或系統外部的。

許多故事可能共享相同的利益聲明。
好處可能是其他用戶或客戶，而不僅僅是故事中的用戶。

如何用用例識別功能需求？

為了全面了解系統的功能需求，你必須知道系統是為誰服務的，即誰將使用系統？

這個問題的答案是：用例分析中的參與者

用例或用戶故事捕獲功能需求，其行為可以表示為系統需要執行的服務、任務或功能。用例定義了用戶和系統服務之間的交互，這可以幫助定義正在開發的系統的功能需求。或者換句話說，產品或服務需要做什麼才能滿足客戶的需求。

用例以“參與者”或“誰”開始，即產品或服務的特定用戶。

參與者是在與系統交互中發揮作用的人或外部系統。參與者的實例可以是個人或外部系統；但是，每個參與者都提供了系統的獨特且重要的視角，該視角對於參與者的每個實例（實際的人/用戶）都是通用的。

真實用戶與用例參與者

為了充分理解系統的用途，你必須知道系統是為誰服務的，即誰將使用它。不同的用戶類型表示為演員（角色）。

角色和單個用戶之間的區別在於，角色代表特定類別的用戶，而不是實際用戶。不同的用戶可以扮演相同的角色，在這種情況下，每個用戶構成一個參與者的實例。

參與者和參與者實例之間的這種區別如下所示：

下圖顯示了 Mary 和 John 是自動售貨機客戶的情況。當他們使用自動售貨機時，每個人都由一個名為 customer 的參與者的實例表示，該參與者期望能夠訪問系統的某些功能（在本例中是購買食物的打印）。

編輯此自動售貨機插圖

相反，同一個用戶可以扮演多個角色（即同一個人可以扮演不同的角色）。

例如，蓋茨博士，他是計算機協會的委員會成員。他負責管理會員管理系統，例如添加和刪除用戶帳戶。當他這樣做時，他扮演一個稱為管理員（Actor）的角色。然而，同樣的蓋茨博士也可能是計算機協會的成員。在這種情況下，他還將扮演一個名為“成員”（演員）的角色

如何通過識別系統的用例得到功能需求

可以通過向利益相關者詢問以下類型的問題（他們必須從參與者的角度回答這些問題）來識別用例：

這個角色的用戶想要完成什麼？
為了履行這個角色，用戶需要能夠做什麼？
擔任此角色的用戶的主要任務是什麼？
該角色的用戶需要檢查、創建或更改哪些信息？
這個角色的用戶需要係統通知什麼？
該角色的用戶需要通知系統什麼？

注意：

用例通常用作發現和表示功能和系統需求的一種方式，因為用例定義了為實現特定業務目標所需執行的交互和任務。但是，它們通常不是定義非功能性需求（例如係統性能和質量）的好方法。