起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識以企業流程類軟件為例，聊聊需求分析的9個步驟
本文側重企業流程類軟件需求，其它類產品可參考，總體分為8個步驟，按照順序依次為：需求識別、業務流程/統計查詢/接口分析、數據實體分析、角色及使用場景分析、系統功能分析、數據割接分析、用戶體驗分析、非功能需求分析。
需求分析是通過需求收集獲取的用戶需求，選擇一種業務導向的線索將零散的需求串聯起來，進行業務分析、消除矛盾，并在業務分析基礎上結合系統現狀進行系統分析并最終形成方案和系統需求說明書的過程。
一、需求識別
需求人員在此步驟應該分析需求類別、需求復雜度和需求價值用來確定需求實施的優先級。
1.需求類別確認：
需求類別包含流程類需求、統計分析類需求、接口類需求，一個需求可能為某一類型需求，也可能包含多類需求。
確認需求類別后應對每類需求的數量進行初步分析（比如流程類需求包含幾個流程、統計分析類需求包含幾個報表、接口類需求包含幾個接口）。
2.需求復雜度分析：
一般需求受理工作量在1-5人天的需求復雜度低，工作量在5-15人天的需求復雜度中，工作量在15人天以上需求復雜度高。（工作量表示需求受理全過程需求人員需要付出的工作量）。
3.價值分析：
需求人員收到需求后應根據收集需求內容初步分析需求痛點/目標、需求復雜度、業務重要程度確定需求價值，需求價值分析可參考如下模型：
二、業務流程/統計查詢/接口分析
針對流程類需求必須進行業務流程分析，統計查詢和接口類需求可不進行詳細的流程分析。
1.業務流程分為部門級、組織級和崗位級
- 部門級流程關注脈絡需要分析涉及哪些具體崗位、執行活動、每個活動之間的關聯關系，它是需求分析的主線條，也是流程分析的主要產物。
- 組織級流程關注宏觀一般不會直接繪制，是對部門級流程的概括和抽象。
- 崗位級流程關注每個業務活動的執行步驟屬需求細節范疇，在流程分析階段不要過度進入細節。
2.需求識別階段確認的流程均為部門級流程
需求人員在進行流程分析應遵循如下方法：
（1）業務流程確認：
一個流程為一個業務事件，一般是外部角色發起或系統內部主動發起（比如時間事件或狀態事件），發起后會觸發一系列業務活動。
（2）角色及業務活動確認：
流程圖中的每個泳道都必須對應到角色，每個角色對應多個業務活動。需求人員在確認業務活動時一定要保證活動的粒度，一個業務活動一定是由一個角色完成且每個業務活動都是有價值的活動。
比如項目輸入項目名稱是一個執行步驟，這個動作沒有價值，項目經理查詢項目信息就是一個業務活動。
在需求描述時針對線下活動或新增活動應該應標識區分。
（3）業務活動間關系及數據確認：
確定所有業務活動的前后置關系，并明確流程間的傳遞的數據實體。
（4）流程整體瓶頸分析：
一般若某個角色業務活動工作量較大，或流程涉及高級領導，一般都會造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優化建議。
3.針對統計查詢類需求及接口類需求，按照上述業務活動確定原則分析、確定角色，并明確每個角色所執行的業務活動即可。
三、數據實體分析
針對流程類需求需要分析各業務活動傳遞的數據實體，統計分析類需求需要分析統計查詢條件和查詢展現兩類數據實體、接口類需求需要分析接口傳遞數據實體，具體分析包含如下內容：
1.明確數據實體：
確認需要分析的所有數據實體，明確哪些為系統原有實體、哪些為新增實體、哪些為改造實體。
2.明確所有數據實體間關系：
實體間關系包含（1對1、1對多、多對多），另外需要分析數據實體變更是否需要保留版本，實體刪除（邏輯刪除、物理刪除）是否影響其它數據實體。
3.明確數據實體字段：
針對新增數據或改造數據實體需要明確新增字段的名稱、字段類型、是否必填、字段取值方式（人工輸入、系統自動繼承自其它數據實體、系統自動計算需要明確計算公式）。
4.數據權限分析：
需要分析不同角色在數據權限方面的差異，若涉及縱向多級用戶，要說明對于集團/省/地市用戶的數據隔離。
四、角色及使用場景分析
一般來說每個業務活動是對用戶使用場景的抽象，每個業務活動可能包含多個場景，分析使用場景時應按照業務活動為主線逐個進行分析，每個業務活動分析時應包含如下內容：
1.明確活動執行角色。
2.明確活動執行的前置條件和后置條件。
3.明確不同場景：
一個業務活動可能包含正常的使用場景、備選使用場景和異常使用場景；
4.明確每個場景的執行步驟：
描述執行步驟時應使用簡單的語法，主語明確語義易于理解，每個步驟不應該在任何一方（執行角色、系統）停留兩部以上，重點描述如何交互。
5.業務規則和約束：
明確在每個業務活動下應遵循的業務規則和約束，這里一般是與業務流程相關的行為規則（比如項目周期時長超過90天必須提交二級領導審批），或與數據實體相關的數據規則（需求交接單拒收時候必須填寫拒收原因，且拒收原因不能超過500字）。
五、系統功能分析
系統功能分析是結合系統現狀和上述分析進一步明確實現相應用戶場景的系統功能，主要還包含內容如下：
1.功能列表：
分析得出實現上述業務活動對應的功能/接口列表，并明確新增功能、改造功能；
2.功能/接口關聯影響分析：
實現某個業務活動需要新增或改造的功能對其它關聯功能/接口的影響分析。比如改造請購池受理功能，可能會影響采購項目創建功能；采購項目創建功能修改一個字段取值范圍，會影響項目統計分析和同步ES系統接口。
3.系統交互原型分析：
需求人員應遵循界面規范，并與研發溝通確定系統交互原型。用戶原型的目的，是為了幫助研發或用戶更好的理解需求場景，而非真正系統實現后高保真原型。
在交互原型中應包含如下內容：
- 原型界面的名稱、入口，原型間關聯關系和使用角色
- 頁面內容、格式及排序方法
- 操作要點：比如交互的信息提示、界面規則和約束（比如界面以不同顏色顯示不同的校驗結果）。
4.算法分析：
在系統功能交互時涉及比較復雜的算法，需要單獨對算法進行分析。
六、數據割接分析
很多功能/流程改造都會涉及數據割接，需求人員應在需求分析階段明確割接規則并與研發溝通明確割接方案，常見的割接場景如下：
1.流程環節變更（比如取消審批流程）。
2.數據實體新增字段。
七、用戶體驗分析
主要針對業務流程分析、用戶使用場景分析、系統交互原型分析時充分考慮用戶體驗，進行用戶體驗分析時可遵循如下用戶體驗要素模型：
1.戰略層：
這個層次在需求識別分析階段基本已完成。
2.范圍層：
主要針對業務流程分析階段、角色及使用場景分析階段及系統功能分析階段增加用戶體驗分析，比如流程環節是否存在瓶頸環節、整體流程效率是否高、使用場景的執行步驟是否繁雜、制定的業務規則是否會增加工作量或導致難以實施等。
3.結構層：
主要針對系統原型交互設計增加用戶體驗分析，交互設計原則如下：
- 簡化原則：刪除不必要的功能直到不能再減少為止；
- 組織原則：按照有意義的標準確定功能，信息展示按照業務含義進行分組；
- 隱藏原則：隱藏非關鍵信息，凸顯關鍵信息，避免分散用戶注意力，但隱藏信息可通過某種線索找到；
- 習慣原則：設計功能盡量貼近用戶的操作習慣，避免用戶思考；
- 幫助原則：為用戶提供適量的幫助和引導；
- 響應原則：每次用戶進行操作后，都需要給用戶一個響應反饋；
- 容錯原則：必須允許用戶犯錯，給予用戶后悔的機會；
- 轉移原則：對復雜性操作進行轉移，用戶擅長做的轉移給用戶，計算機擅長做的轉移給計算機。
4.框架層：
主要針對系統原型界面設計增加用戶體驗的分析，主要由界面規范和系統技術架構決定。
5.視覺層：
主要由界面規范決定。
八、非功能需求分析
包含需求的可行性分析、健壯性分析、可擴展性分析、執行效率分析，可行性分析從以下幾個方面進行：
1.技術可行性：針對數據割接方案、系統交互實現方式與研發確認是否可行，需求人員在與研發溝通過程中需要不斷積累哪些功能實現在技術層面很難支撐；
2.時間可行性：根據用戶的上線時間要求分析是否可滿足要求；
3.合法合規可行性：分析用戶需求是否滿足國家法規或公司法規要求；
4.數據安全性分析：用戶需求是否滿足信息系統安全要求。
本文由 @奮斗De奶爸 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
作者能否列舉案例來講解一下
靜下心來看，著實感覺很棒，
因為工作中遇到類似的事情，需要抽象出來。