需求分析方法論：如何理解透需求？

需求分析的步驟

從事需求分析以來，不論是本身參與的或是徹底由本身一我的需求調研的，也有過大大小小項目需求調研的經歷。這周去了深圳某券商進行了爲期一週的需求調研，需求調研完成以後，其實總結下來有些套路可使用。

若是把IT比作一個江湖，不管是什麼公司什麼業務的需求，練好這個武功心法「四層五步五清法」，能夠從宏觀上以及部分微觀上理解用戶的需求。之因此說是部分微觀，是由於具體的需求，還得具體的分析，但練好這個武功心法，在需求分析的宏觀上能夠說沒有問題。

對於需求分析人員從宏觀上作需求調研的時候，須要弄清楚這四個層次（對於通常的需求分析人員弄清楚前面兩個層次也是能夠的）。

四層：

第一層職能層：梳理各部門的職能。

一個系統若是涉及到不少部門，那麼梳理各部門的職能能幫助咱們去理解他們提出需求的緣由，甚至經過了解各部門的職能反過頭去質疑其餘部門提出的需求。

舉一個很簡單的例子，某券商的風控部牽頭要建設信用風險管理系統，爲實現監管的「同一客戶，同一業務，統一管理」，風控部將其餘業務部門也歸入到系統中來，在需求調研階段，某業務部門提出在實現一個報表查詢到時候，須要部門與部門的權限隔離，即固收部的看固收部的持倉數據，其餘部門在看同一張報表的時候看不了固收部的持倉數據。

咋一聽這個需求提的很合理，可是風控部的職能是從公司總體上控制風險並防範風險，風控部能夠看全部業務部門的數據。

用戶提需求的時候只是出於自身考慮，並無想到其餘部門，因此當需求涉及多個部門的時候，需求分析人員在需求調研階段把各部門的職能弄清楚。

2. 第二層業務層：梳理業務。

沒有人會平白無故去購買一個系統，對於企業而言購買系統就是想將公司的業務放在系統上去作。不一樣類型的企業或不一樣部門，業務是不同的，業務的複雜程度決定了系統的複雜程度，若一個複雜的業務可以被梳理的邏輯清晰條理清晰，系統也不會很複雜，但前提是你很懂很懂業務。

當一個業務小白如何快速的理解業務，能夠蒐集業務相關的名詞解釋，弄懂這些名詞算四分之一理解業務。每種業務都會有其特定的術語，好比在物流行業，你須要知道什麼是貨代、郵路、頭程、預報等等，在金融行業，你須要知道什麼是股票質押、債券投資、融資融券、資管計劃，除此還不夠，你須要理解透每個業務以及業務與業務的差異，好比股票質押與融資融券的差異在哪？

3. 第三層數據層：梳理信息。

這須要需求分析人員懂一些技術才能梳理清楚，對需求分析人員很高要求的一個層次。對於系統的底層數據，須要梳理數據與數據的流向，數據與數據的邏輯關係，這些都梳理清楚之後，對於如今的開發或是之後的迭代都能起到很大的做用。

4. 第四層：梳理支撐環境。

業務需求以及數據都弄清楚之後，還須要考慮非功能性的需求，好比系統的硬件環境和軟件環境是什麼，用谷歌瀏覽器仍是IE瀏覽器等。

以上是四層五步法的四層，如何去實現上面的四層，作到如下「五步」：

• 根據組織結構梳理職能域，好比機構／部門的職能，各崗位的工做職責
• 根據職能域梳理業務元素，包括業務術語、名詞解釋等
• 根據業務元素梳理業務活動，如業務流程、業務環節、狀態、信息等
• 根據業務活動梳理業務等內外聯繫，如業務協做、信息流向
• 描繪業務架構、信息架構，如用戶分類、業務分類、信息分類

四層和五步作到之後，問本身幾個問題，看看是否真正的理解需求：

1. 業務對象清楚了沒有？系統的用戶以及各功能模塊的用戶是誰是否清楚。
2. 業務流程清楚了沒有？各環節的處理人以及處理動做是否清楚。
3. 業務場景清楚了沒有？每一個需求的業務場景是否弄清楚，全部需求的業務場景是否能鏈接在一塊兒，在腦海中完整的造成一個故事。
4. 業務事項數量清楚了沒有？一共有多少個需求，一共有多少種角色，一共有多少張報表，一共有多少個前置條件……
5. 跨部門的業務關係清楚了沒有？這個部門與那個部門的關係以及產生的哪些業務往來是否清楚。

四層五步五清法都作到之後，你能夠把一個需求故事的大綱弄明白，再加上具體細節的需求分析（請查看以前的文章有寫如何去分析不一樣類型的需求），把細節填充在需求故事的大綱裏面，一個完整的故事就出來了。

需求分析人員能把一個需求故事從頭到晚每一處都講清楚，在需求的把控上大致上不會出錯，要知道需求要是錯了，後果是很嚴重的。

 

做者：Vi-Vi-Fu，微博@風將信至，杭州某金融軟件公司需求分析師，負責過證券公司信用風險管理項目的需求分析。

本文由 @Vi-Vi-Fu 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基於 CC0 協議