開(kāi)始一個(gè)APP開(kāi)發(fā)項(xiàng)目，對(duì)于APP開(kāi)發(fā)團(tuán)隊(duì)而言，首先要知道做什么。APP開(kāi)發(fā)的全過(guò)程是：做什么，怎么做，做 ，成果檢驗(yàn)，交付部署；其中，“做什么”對(duì)應(yīng)的是需求分析過(guò)程，“怎么做”對(duì)應(yīng)于軟件架構(gòu)設(shè)計(jì)過(guò)程，“做”對(duì)應(yīng)于開(kāi)發(fā)過(guò)程，“成果檢驗(yàn)”對(duì)應(yīng)于測(cè)試，部署由運(yùn)維團(tuán)隊(duì)執(zhí)行后，如果達(dá)到用戶的要求，則軟件上線后進(jìn)入軟件的運(yùn)行生命周期。

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

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

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

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

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

綜上，在APP開(kāi)發(fā)項(xiàng)目中，如果要把需求分析做到位，止于功能架構(gòu)分析才是保險(xiǎn)的。