開始一個APP開發(fā)項目，對于APP開發(fā)團隊而言，首先要知道做什么。APP開發(fā)的全過程是：做什么，怎么做，做 ，成果檢驗，交付部署；其中，“做什么”對應的是需求分析過程，“怎么做”對應于軟件架構設計過程，“做”對應于開發(fā)過程，“成果檢驗”對應于測試，部署由運維團隊執(zhí)行后，如果達到用戶的要求，則軟件上線后進入軟件的運行生命周期。

在實際的軟件項目開發(fā)中，“做什么”，“怎么做”和“做”是緊密結合在一起的，“做”，“成果檢驗”和“交付部署”通常也會是一個持續(xù)交付過程，“成果檢驗”的內容會受到“做什么”的影響，開展“做什么”階段的時候，也要考慮到如何部署和交付。所以軟件開發(fā)的全過程，都是緊密結合在一起的，如果刻意劃分為獨立的幾個階段，忽視其作為一個整理的綜合影響，每個環(huán)節(jié)的實施過程必然會遇到因上一階段考慮不周全帶來的問題，從而影響整體開發(fā)效率。

基于此，我們的需求分析，從需求深度劃分，可以分為三個層次：原始需求分析、業(yè)務架構分析和功能架構分析。這三個層次依次遞進，沒有嚴格的界限。

原始需求是從用戶或業(yè)務角度看到的，或應該有的需求，或項目團隊經(jīng)過初步挖掘后整理出來的、未經(jīng)進一步提煉的需求。
如果拿做項目與做產(chǎn)品做個類比，原始需求有點類似與產(chǎn)品經(jīng)理所說的“用戶故事”，由于原始需求可能是開發(fā)者分析出來了，也可能是行業(yè)專家或目標客戶 / 用戶提出來的，原始需求可以不止步于“用戶故事”，在該階段做一定的業(yè)務邏輯的抽取和提煉，對接下來“業(yè)務架構”階段的需求分析也是有幫助的，所以這兩個階段沒必要確立一個嚴格的界限。

業(yè)務架構階段的需求分析，是對原始需求的抽象和再提煉，在形成業(yè)務架構之前，首先要梳理清楚功能需求和非功能需求，非功能需求是為接下來的功能架構及怎么做鋪路的，本節(jié)暫不展開；功能需求又分為“顯式的功能需求”和“潛在的功能需求”，如上一節(jié)列出的需求，均為顯式功能需求，潛在的功能需求要從多個角度去考慮，如整理出用戶組、權限對應的完整業(yè)務邏輯，是屬于可以推測并進一步開展工作的潛在功能需求，而修改密碼、個人信息、用戶管理和忘記密碼等功能，是上面漏掉的、但又會影響到系統(tǒng)完整性的潛在需求，而需要提供一個系統(tǒng)初始化接口的功能需求，是站在運維實施角度提出來的潛在需求。

業(yè)務架構為軟件系統(tǒng)的開發(fā)奠定了基礎，在實際的軟件項目中，通?？梢栽诖嘶A上讓需求分析再往前邁一步，將"做什么"和“怎么做”是緊密聯(lián)系起來，承上啟下，我將這部分需求分析稱之為“功能架構分析”。
為什么需求分析中要做功能架構分析？
定性的說，這一步工作也可以納入“怎么做”的環(huán)節(jié)再開展，但我認為把它作為需求分析的最后階段，對整個項目過程而言更有效率。這部分工作依然是圍繞需求分析展開的，前文所述的需求分析工作通常開發(fā)者也會參與進去，所以業(yè)務架構分析和功能架構分析本來就是銜接在一起的連續(xù)過程，如果把這一步工作從需求分析中拋離，項目進行到怎么做或做的階段時，發(fā)現(xiàn)現(xiàn)實（代碼邏輯和系統(tǒng)實施）和理想（業(yè)務邏輯）不一致的概率會更大，開發(fā)過程中可能會有更多關于“需求分析沒做到位”的扯皮，甚至不得不重新返回需求分析階段再次梳理需求，這都會帶來本可避免的項目進度延誤。
所以，需求分析如果只考慮“原始需求”和“業(yè)務架構”兩個維度，是有盲點的，功能架構分析雖然可以作為“怎么做”的第一步，但把它作為“做什么”的最后一步，能有效減少因為沒有“向后看”帶來的需求分析不充分的問題，能夠把需求和實現(xiàn)更緊密的結合在一起，它在一定程度上對業(yè)務架構做了進一步的細化，也在一定程度上影響了業(yè)務架構的最終成果。

綜上，在APP開發(fā)項目中，如果要把需求分析做到位，止于功能架構分析才是保險的。