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

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

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

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

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

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

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