如果把IT比做一個江湖，無論是什么公司什么業務的需求，練好這個武功心法“四層五步五清法”，可以從宏觀上以及部分微觀上理解用戶的需求。

需求分析的步驟

從事需求分析以來，不管是自己參與的或是完全由自己一個人需求調研的，也有過大大小小項目需求調研的經歷。這周去了深圳某券商進行了為期一周的需求調研，需求調研完成之后，其實總結下來有些套路可以使用。

如果把IT比做一個江湖，無論是什么公司什么業務的需求，練好這個武功心法“四層五步五清法”，可以從宏觀上以及部分微觀上理解用戶的需求。之所以說是部分微觀，是因為具體的需求，還得具體的分析，但練好這個武功心法，在需求分析的宏觀上可以說沒有問題。

對于需求分析人員從宏觀上做需求調研的時候，需要弄清楚這四個層次（對于一般的需求分析人員弄清楚前面兩個層次也是可以的）。

四層：

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

一個系統如果涉及到很多部門，那么梳理各部門的職能能幫助我們去理解他們提出需求的原因，甚至通過了解各部門的職能反過頭去質疑其他部門提出的需求。

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

咋一聽這個需求提的很合理，但是風控部的職能是從公司整體上控制風險并防范風險，風控部可以看所有業務部門的數據。

用戶提需求的時候只是出于自身考慮，并沒有想到其他部門，所以當需求涉及多個部門的時候，需求分析人員在需求調研階段把各部門的職能弄清楚。

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

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

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

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

這需要需求分析人員懂一些技術才能梳理清楚，對需求分析人員很高要求的一個層次。對于系統的底層數據，需要梳理數據與數據的流向，數據與數據的邏輯關系，這些都梳理清楚以后，對于現在的開發或是以后的迭代都能起到很大的作用。

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

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

以上是四層五步法的四層，如何去實現上面的四層，做到以下“五步”：

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

四層和五步做到以后，問自己幾個問題，看看是否真正的理解需求：

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

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

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

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

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

題圖來自PEXELS，基于 CC0 協議