所屬章節：

第11章. 軟件需求工程

? ? ? ? 第2節. 需求獲取

需求獲取是一個確定和理解不同的項目干系人的需求和約束的過程。需求獲取是一件看上去很簡單、做起來卻很難的事情。需求獲取是否科學、準備是否充分，對獲取出來的結果影響很大，這是因為大部分用戶無法完整地描述需求，而且也不可能看到系統的全貌。因此，需求獲取只有通過系統分析師與用戶的有效合作才能成功。系統分析師必須建立一個對問題進行徹底探討的環境，而這些問題與將要開發的系統有關。讓用戶明確了解，對于某些功能的討論并不意味著將在系統中實現它。

作為一名系統分析師，掌握各種不同的需求獲取技術，并且熟練地在實踐中運用它，是十分必要的。本節就一些最常用的需求獲取技術進行展開討論。

11.2.6?需求記錄技術

在需求獲取的過程中，將會產生大量的信息，系統分析師要將這些信息有條理地記錄下來，就需要借助一些工具。在信息系統開發實踐中，有時候進行需求獲取的人員和進行需求分析的人員不是同一個人或團隊，有時候在同一個項目中有多個系統分析師參加需求獲取，因此，需要統一需求記錄工具，以便讓所有人的獲取結果是同一口徑的。

常用的需求記錄工具有任務卡片、場景說明、用戶故事和Volere白卡等。

1. 任務卡片

在各種需求記錄工具中，任務卡片是一種比較簡單的工具，它特別適合對業務活動級的信息收集與整理。常用的任務卡片如圖11-2所示：

在圖11-2中，各個項目的內容及解釋如表11-3所示：

增強版任務卡片在基本任務卡片的基礎上，增加了問題點描述和解決方案提示。其中，方案示例是針對問題點，系統需要實現什么樣的功能，以便驗證這些解決方案是否能夠解決用戶提出的問題。

2. 場景說明

有時候，系統分析師可能很難總結出子任務和任務變體，因為這需要對任務執行過程進行抽象。此時，系統分析師可以使用場景說明來對用戶的描述進行整理，抽象出子任務。簡單地理解，場景說明就是用戶對其工作場景和過程的詳細描述，這些描述將在編寫測試用例和用戶培訓手冊中再次用到。

3. 用戶故事

用戶故事描述了對用戶有價值的功能，可包括三個方面內容，分別是：書面描述（用于計劃和備忘）、交談（細化故事）和測試用例（驗證故事實現）。用戶故事描述的傳統形式是手工書寫的用戶故事卡。系統分析師輔助用戶編寫，告訴用戶所編寫的故事是進一步討論的引子，而不是詳細的需求規范。在任何項目中，需要用戶團隊根據故事的重要性來安排開發工作，回答所有開發問題，編寫所有的故事。在編寫故事之前應該建立用戶角色模型，必須包含對項目成功至關重要的角色，盡量保證所有用戶對系統完全滿意。

用戶故事具有6個基本屬性：獨立性、可協商性、對用戶有價值、可預測性、短小精悍和可測試性。

（1）獨立性

盡可能避免故事之間存在依賴關系，因為依賴關系會產生優先級和規劃問題。

（2）可協商性

故事是可協商的，不是必須實現的書面合同或者需求。

（3）對用戶有價值

確保每個故事對用戶有價值的最好方式是讓用戶編寫故事。

（4）可預測性

系統分析師應該能夠預測（至少大致猜測）故事的規模，以及實現所需要的工作量。

（5）短小精悍

故事規模對實現有影響，何種故事規模最合適，取決于開發團隊的規模和能力，以及技術實現等方面。

（6）可測試性

所編寫的故事必須是可測試的。

4. Volere白卡

Volere白卡是一種類似于任務卡片的需求記錄工具，其格式如圖11-4所示：

用戶故事和Volere白卡定位的是最小的需求項，因此在實際應用中會導致量比較大，一般在敏捷方法中使用。

系統分析師在選擇需求記錄工具時，既可以借鑒現有的模板，也可以根據自己的需要進行擴展或重新定義。另外，選擇記錄工具時要考慮項目團隊所使用的開發方法、用戶的實際情況、系統分析師的技能等因素。

至此，“11.2.6?需求記錄技術”的全部內容就講解完了。“11.2 需求獲取”的全部內容也都講解完了。