?????一拿到toB的產品需求總是抓耳撓腮，不知道從哪里開始，甚至開始了也混亂不堪。但經歷幾個產品后發現再復雜的系統也有章可循：自下而上的找點、連線、畫面。那如何找點，怎樣連線，用什么畫面？
一、用“實體關系圖（ERD）”尋找【點】
????實體關系圖的概念來源于關系型數據庫，也就是ER模型，主要用在信息系統的設計。但我發現簡化了其中的理論后用來做需求梳理也很好。具體做法就是：
a、拿到系統需求先抽象其中涉及的實體；
b、找出實體和實體間的對應關系，并繪圖。
那么接下來您可能要問：
什么是實體？
? ??實體的官方解釋：實體是客觀存在并可相互區別的事物。就數據庫而言，實體往往指某類事物的集合。
????我認為需求中反復出現的名詞、可用屬性描述的事物都可以抽離出來作為真正實體的備選，然后反復對比、去重（名字不同實際相同）得到所有實體。
舉個例子：
? ??需求：客戶希望做一個應用，這個應用能使巡檢員看到企業的所有幫助文檔、可以查看企業的最新資訊；可以通過巡檢員在app的報修行為產生工單，工單可以通過管理員分派給維修人員進行維修，維修完成后管理員檢查是否合格，如果合格關閉工單，如果不合格重新分派。
????根據此需求可以抽象出如下實體：幫助文檔、資訊、工單、用戶、管理員、維修人員，并兩兩關聯看是否有強關聯（兩個實體有關系），如果有則在兩個實體之間畫一條線。
得到如下ERD:
什么是對應關系？
對應關系有幾種：一對一、多對多、一對多。
一對一（1:1）：1個實體A對應1個實體B，1個實體B對應1個實體A
一對多（1:N）：1個實體A對應多個實體B，1個實體B對應1個實體A
多對多（M:N）：1個實體A對應多個實體B，1個實體B對應多個實體A
舉例：依舊按照問題1中的例子：顯然一個維修員可以看多篇幫助文檔，而1篇幫助文檔可以被多個維修員看，那么維修員和幫助文檔就是多對多的關系，兩兩對應后得出如下結論：
怎么繪圖，有什么工具可以繪圖？
????以前都是用Visio繪制，但現在有很多線上工具也很好用，比如我現在用的ProcessOn。線上工具的好處是：網站不定期提供很多素材和模板，使用體驗也比傳統的Visio好很多，重點是還可以和其他同事協作。
????經過以上3個步驟后實體以及實體間的關系已經基本清晰了，也就是系統要做哪些模塊大致確定，如果功力夠深，系統的表結構都有了模糊的呈現。
舉例：依舊按照問題1中的例子，系統的模塊大致是用戶管理、幫助文檔管理、資訊管理、工單管理。
? ??如果想更深入的學習ERD，比如有在圖上標識某些實體是否可以為空，了解ERD繪制的標準、在ERD中添加屬性等等要求，有很多材料可供學習，在此就不贅述了。
參考：
如何使用Entity Relationship Diagram (ERD) 建模 - 關系數據庫設計https://blog.csdn.net/chktsang/article/details/78751075
二、通過“功能權限、數據權限的梳理”連【線】
????功能權限、數據權限的問題在大型系統中是邏輯最為復雜的模塊，牽連甚廣。
????在進行權限的梳理前要明確：使用系統的角色有哪些？角色是自由配置還是內置寫死？
????一般大型系統組織結構復雜，用戶靈活多變，角色是需要自由配置的，而小型的系統可能根據真實場景內置幾個定義好的角色就可以。
舉例：
? ??仍舊是這個例子：客戶希望做一個應用，這個應用能使巡檢員看到企業的所有幫助文檔、可以查看企業的最新資訊；可以通過巡檢員在app的報修行為產生工單，工單可以通過管理員分派給維修人員進行維修，維修完成后管理員檢查是否合格，如果合格關閉工單，如果不合格重新分派。
? ??這個需求的業務足夠簡單，角色只有：管理員、巡檢員、維修員，可以采用內置于系統的方式。
功能權限的梳理：
????角色是功能權限的集合，那么功能權限的梳理也就變成了：哪些角色對哪些功能可寫（增刪改），對哪些功能可讀（查看），對哪些功能不可讀不可寫？而描述清楚這些問題的最好方式是表格。
舉例，根據需求，管理員對用戶管理、幫助文檔、資訊、工單可讀可寫，而維修員對幫助文檔、資訊可讀不可寫，對工單可讀可寫，梳理如下：
????有了這張表，各個角色的功能權限就較為清晰了。但是為什么能看到同一模塊的兩個用戶看到的數據卻是完全不一樣？這是因為他們的數據權限不一樣。
數據權限梳理
????兩個用戶在同一個模塊看到的數據不一樣是因為他們的數據權限不一樣。梳理數據權限的意義在于明確不同用戶可讀或者可寫的數據范圍。
????如何梳理？
????用戶對哪些數據可讀可寫與角色、組織架構有關。有的組織是扁平組織，有的則是一層一層的樹形組織。我很多時候仍舊是在功能權限說明表的基礎上重新描述數據權限。
? ??繼續之前的例子，將功能權限表的內的“√”替換為數據權限說明：
? ??根據功能權限說明表和數據權限說明表，維修員的權限就可以概述為：可讀寫工單，但只能讀寫自己的工單。
????例子中的需求較為簡單，但真實情況往往是這樣的：
????所以，以上只是從工具層面介紹如何梳理權限，但真實的系統往往更復雜，比如功能權限的粒度是更小的按鈕或者接口，比如引入標簽系統。如果想深入學習可以繼續研究RBAC權限模型并結合實際項目不斷練習。
參考：
什么是基于角色的權限訪問控制？https://digitalguardian.com/blog/what-role-based-access-control-rbac-examples-benefits-and-more
三、用“流程圖”繪制系統的【面】
????系統要對哪些實體進行管理、系統如何進行權限訪問控制兩個問題理清后需要一條橫向的線將業務串起來形成【面】，流程圖便可以幫我們找到那條橫向的【線】。
什么是流程圖？
? ? 流程圖是用來描述各個實體間的關系、系統作業順序和信息流向的圖表。任何的系統都有流程，只是簡單和復雜的區別。
? ? 流程圖可以幫我們理清很多業務流程和數據流向，也是原型之前對系統的邏輯思考，簡單系統的業務流程通常用一個泳道圖就畫完了，而復雜系統可能需要分模塊、分層級進行狀態圖、時序圖、流程圖等不同類型的圖表的繪制才能大致解釋清楚業務邏輯。
如何畫流程圖？
????如果流程圖只是作為需求階段的中間輸出物，天馬行空地畫也未嘗不可，有時還能在某個點迸出創新的火花，但如果作為正式的輸出物，可能就要拘泥于UML的標準了。
1、根據需求從開始到終點繪制該角色的操作流程，如果某些活動涉及多種角色則使用泳道圖；
舉例
2、某些實體有復雜的狀態變化使用狀態圖；
3、實體間傳遞信息有明顯的時間順序使用時序圖。
????系統邏輯經過流程圖的繪制后就變得清晰了，系統的神秘面紗被慢慢揭開。原型圖有了這些圖表作為邏輯支撐，效率和可用性都會大大提升。
參考
你可能學了假流程圖，三步教會你繪制大廠流程圖(第一篇)http://www.woshipm.com/pmd/1926387.html
制作人人喜歡的流程圖，三步教會你繪制大廠流程圖(第二篇)http://www.woshipm.com/pd/1923749.html
任務和業務流程圖分清用好，三步教會你繪制大廠流程圖(第三篇)http://www.woshipm.com/pd/1821622.html
? ? 三個步驟只是從“術”的層面簡單地概括如何做toB產品的需求分析，但是不同的系統需求也不盡相同，需要靈活使用和長期的微觀體感，如果文章中的內容存在什么問題歡迎指正，也希望大家在需求分析的道路上每天有所進步。
