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