繼上一篇業務流程識別與分析篇后，本文主要分享業務場景識別與分析相關知識點。

一、識別業務場景

首先是要理解用例和用戶故事的本質，它要求我們不是去關注系統提供什么功能，而是用戶在什么場景下需要系統提供支持！

1.用例的關鍵知識認知

1-1.用例名稱要基于用戶場景去設定，使用業務語言去描述，而不是機械式的使用“增刪改查”

1-2.在業務場景中的用例粒度是由組織分工決定的，特征是獨立、可匯報、可暫停的單元（一般不會是太細化的動作）

1-3.2人/周的工作量分拆成更小的故事，另外大故事要保留的原因是方便組織小故事，不忘初心。

2.基于流程圖識別參與系統的角色。

2-1.對這個流程提供支撐需要有哪些角色？

2-2.非必需的角色納入系統支持中有什么價值？不納入的話有什么影響？（在優先級排序時有指導作用）

2-3.一般執行層的角色會用崗位名稱命名

2-4.在權限系統中要如何抽象各個角色

3.基于流程圖識別業務場景。我們要思考在流程過程中，哪些業務活動要系統支持，哪些是部分支持，審批點是否屬于系統內，判斷點是否為獨立環節。（下圖是一套體檢系統的流程圖，假如工程排期優先內部作業電子化，故體檢者一欄暫時不納入電子系統。紅圈則是現要開發的系統所支持的任務活動）

4.補充業務場景。常見如由時間、狀態而觸發的業務場景，如信用卡到期還款以及長期逾期狀態導致信用卡凍結的場景。

5.繪制用例圖。

注意常見三個關系。包含、擴展、泛化。包含關系——公共子事件流（不需給用戶看），如檢查座位信息。擴展關系——不一定執行的擴展事件流（需給用戶看），如處理等候隊列。泛化關系——公共事件流，如辦理結賬。

二、六步分析業務場景

1.概述業務場景（包括業務目的、前后置條件等）

2.把場景細化成事件流，整理去用戶預期的步驟，并思考擴展和異常事件流。注意兩點。

2-1用例描述重在人機交互和意圖，不需要過多些人機界面和動作

2-2結構化語言描述，少用“如果..就”的表達方式了；擴展或備選事件流單獨列出來分支，降低理解成本。

3.針對每一個步驟，思考并羅列用戶可能遇到的問題

4.針對問題思考解決方案

5.考慮環境與業務特點帶來的影響或要求，主要是性能、易用性、部署環境等三方面

6.開始初步的交互設計