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

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

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

原始需求是從用戶或業(yè)務(wù)角度看到的，或應(yīng)該有的需求，或項目團(tuán)隊經(jīng)過初步挖掘后整理出來的、未經(jīng)進(jìn)一步提煉的需求。

如果拿做項目與做產(chǎn)品做個類比，原始需求有點(diǎn)類似與產(chǎn)品經(jīng)理所說的“用戶故事”，由于原始需求可能是開發(fā)者分析出來了，也可能是行業(yè)專家或目標(biāo)客戶 / 用戶提出來的，原始需求可以不止步于“用戶故事”，在該階段做一定的業(yè)務(wù)邏輯的抽取和提煉，對接下來“業(yè)務(wù)架構(gòu)”階段的需求分析也是有幫助的，所以這兩個階段沒必要確立一個嚴(yán)格的界限。

例如，對一個多人博客系統(tǒng)而言，原始需求可能是這樣的：

1. 要有個所有文章列表

2. 能點(diǎn)擊查閱文章

3. 能評論文章

4. 能創(chuàng)建新文章

5. 能編輯刪除文章

6. 要有權(quán)限機(jī)制

而對于更有經(jīng)驗的人而言，原始需求可能更加體系化：

首先，多人博客系統(tǒng)由前臺展示子系統(tǒng)和后臺管理子系統(tǒng)構(gòu)成，兩個子系統(tǒng)的功能可以分別來描述。

前臺子系統(tǒng)應(yīng)該對任何人可見，該子系統(tǒng)至少包含以下頁面或功能：

1. 文章列表 + 概要頁面

2. 文章詳情頁面

3. 作者主頁

4. 文章評論功能

5. 文章搜索功能

6. 側(cè)邊欄的目錄、tag 等博客經(jīng)典功能

后臺子系統(tǒng)只對登錄用戶開放，對應(yīng)多人博客而言，該子系統(tǒng)應(yīng)該分用戶組，為不同類型用戶分配不同的權(quán)限，該子系統(tǒng)至少包含以下頁面或功能：

• 用戶登錄或注冊功能

• 根據(jù)不同用戶的權(quán)限，登錄后看到不同的頁面或功能

• 創(chuàng)建新文章

• 修改或刪除文章

• 維護(hù)博客名稱描述等內(nèi)容的功能

原始需求階段做的，主要是需求是收集、整理和簡單分析工作，為業(yè)務(wù)架構(gòu)階段的需求分析奠定了基礎(chǔ)。

當(dāng)業(yè)務(wù)架構(gòu)梳理過程中，尤其是整理潛在功能需求時，一定會發(fā)現(xiàn)上一階段疏漏或在上一階段的視角下考慮不到的需求點(diǎn)，此時應(yīng)結(jié)合項目的進(jìn)度要求，考慮是否進(jìn)行一輪需求的迭代和補(bǔ)充。

對上文提到的多人博客系統(tǒng)而言，業(yè)務(wù)架構(gòu)可以設(shè)計如下：

多人博客系統(tǒng)業(yè)務(wù)架構(gòu)

做好業(yè)務(wù)架構(gòu)，是為整個軟件項目邁出堅實的第一步。業(yè)務(wù)架構(gòu)是需求分析中最重要的階段，經(jīng)歷了整理業(yè)務(wù)架構(gòu)分析的過程，基本上才真正把系統(tǒng)需求梳理出來了，如果簡單粗暴的在需求和開發(fā)之間切出一個交接面，把交接面放在業(yè)務(wù)架構(gòu)上是比較合適的，系統(tǒng)開發(fā)的底線是要與業(yè)務(wù)架構(gòu)保持一致，后續(xù)的需求迭代或變更，也要基于業(yè)務(wù)架構(gòu)擴(kuò)展或重構(gòu)。

業(yè)務(wù)架構(gòu)對軟件系統(tǒng)開發(fā)也有重要影響。開發(fā)軟件系統(tǒng)，通常要求具備充分的可擴(kuò)展性，而可擴(kuò)展性，在需求分析階段就奠定了基礎(chǔ)，需求分析做的充分，就能在很大程度上給系統(tǒng)可擴(kuò)展性定性了，當(dāng)增加新功能時，系統(tǒng)能否擴(kuò)展功能，還是系統(tǒng)的某些功能要打破重來，業(yè)務(wù)架構(gòu)階段就能看出端倪。比如，如果想在多人博客系統(tǒng)中增加用戶的社交功能，可以把該功能插入到用戶模塊和個人模塊中去，也可以單獨(dú)開一個社交模塊來封閉相關(guān)功能，前者會更多的打破原有業(yè)務(wù)邏輯，從而改變已有功能的代碼實現(xiàn)，而后者更多的是在新的模塊中梳理業(yè)務(wù)邏輯，開發(fā)新功能，前者重構(gòu)多于擴(kuò)展，而后者擴(kuò)展多于重構(gòu)。所以如果業(yè)務(wù)架構(gòu)設(shè)計的具有足夠的擴(kuò)展性，相當(dāng)于軟件系統(tǒng)先天具備較強(qiáng)的可擴(kuò)展性。

業(yè)務(wù)架構(gòu)為軟件系統(tǒng)的開發(fā)奠定了基礎(chǔ)，在實際的軟件項目中，通?？梢栽诖嘶A(chǔ)上讓需求分析再往前邁一步，將"做什么"和“怎么做”是緊密聯(lián)系起來，承上啟下，我將這部分需求分析稱之為“功能架構(gòu)分析”。

所以，需求分析如果只考慮“原始需求”和“業(yè)務(wù)架構(gòu)”兩個維度，是有盲點(diǎn)的，功能架構(gòu)分析雖然可以作為“怎么做”的第一步，但把它作為“做什么”的最后一步，能有效減少因為沒有“向后看”帶來的需求分析不充分的問題，能夠把需求和實現(xiàn)更緊密的結(jié)合在一起，它在一定程度上對業(yè)務(wù)架構(gòu)做了進(jìn)一步的細(xì)化，也在一定程度上影響了業(yè)務(wù)架構(gòu)的最終成果。

功能架構(gòu)分析的主要內(nèi)容有 2 點(diǎn)：（1）再次提煉和抽象業(yè)務(wù)功能；（2）確認(rèn)和完善非功能需求。

（1）再次提煉和抽象業(yè)務(wù)功能

博客系統(tǒng)比較簡單，其業(yè)務(wù)架構(gòu)和功能架構(gòu)可能基本上是一致的。對于復(fù)雜的業(yè)務(wù)系統(tǒng)而言，業(yè)務(wù)架構(gòu)分析階段提煉的業(yè)務(wù)功能，是有可能被再次提煉的，如：

OA 系統(tǒng)中，我們從業(yè)務(wù)架構(gòu)的視角看，可以整理出如“計劃管理”、“任務(wù)管理”和“表單管理”等模塊，這些模塊的業(yè)務(wù)流程都會包含“審批流程”、“短信通知”、“郵件通知”等基礎(chǔ)功能，這些功能在每個業(yè)務(wù)模塊中，功效類似，但在業(yè)務(wù)架構(gòu)的視角和顆粒度上，不一定能清晰的表達(dá)出來，但梳理功能架構(gòu)的時候，可以將此作為從相關(guān)業(yè)務(wù)模塊的核心業(yè)務(wù)邏輯中剝離的非核心業(yè)務(wù)邏輯，作為基礎(chǔ)功能模塊放到功能架構(gòu)的恰當(dāng)位置。

OA 系統(tǒng)中，可能還存在一些功能模塊，涉及到上傳附件、預(yù)覽或下載附件等功能，甚至在此之外還會有獨(dú)立的“文檔管理”模塊，順著上一段的思路，我們可能都意識到了“文件存儲管理”也可以獨(dú)立出來作為基礎(chǔ)功能模塊來實現(xiàn)；而有相關(guān)開發(fā)經(jīng)驗的人還知道，文件有大有小，大文件存儲、管理和消費(fèi)的業(yè)務(wù)邏輯和零散小文件類似業(yè)務(wù)邏輯的實現(xiàn)及性能上可能會有很大差別，導(dǎo)致不同的應(yīng)用場景對應(yīng)不同的實現(xiàn)方案，如某些業(yè)務(wù)場景下，該模塊是可以與系統(tǒng)其它模塊集成在一起的，而另外一些場景下，該模塊需求獨(dú)立出來，單獨(dú)服務(wù)器部署，另外文件的存儲、備份和恢復(fù)機(jī)制等，也都要考慮進(jìn)去。這些都是使得看似簡單的文件存儲功能，在具體實現(xiàn)和實施上非常麻煩，而這些可能是“業(yè)務(wù)架構(gòu)分析”中難以避免的盲點(diǎn)。

所以業(yè)務(wù)架構(gòu)分析階段，雖然能夠做到把業(yè)務(wù)需求和邏輯完整的整理出來，但不一定能把構(gòu)成每個業(yè)務(wù)邏輯的單位功能一一提煉和組織起來，也可能會因為缺乏功能開發(fā)和系統(tǒng)性能上的背景知識，忽視某些需要單獨(dú)處理的功能或模塊的特殊性，為系統(tǒng)的穩(wěn)定性和可擴(kuò)展性埋下隱患，所以，在業(yè)務(wù)架構(gòu)分析之后，在開發(fā)之前，一定要做“功能架構(gòu)分析”。

業(yè)務(wù)架構(gòu)是面向用戶的，功能架構(gòu)是面向開發(fā)者的，功能架構(gòu)和業(yè)務(wù)架構(gòu)是一致的，且功能架構(gòu)可以看做是業(yè)務(wù)架構(gòu)的超集。

（2）確認(rèn)和完善非功能需求

非功能需求方面的考慮，其實已經(jīng)屬于架構(gòu)師在怎么做階段的起步了，怎么做的主要成果是軟件架構(gòu)，而設(shè)計軟件架構(gòu)要考慮的兩個維度是“業(yè)務(wù)架構(gòu)”和“業(yè)務(wù)量級”。設(shè)計軟件架構(gòu)，一方面要保證軟件系統(tǒng)的功能符合用戶預(yù)期，另一方面，也是更重要的是，軟件系統(tǒng)要能被正常部署、使用、維護(hù)和監(jiān)控，前者對應(yīng)的是原始需要和業(yè)務(wù)架構(gòu)的初級階段，后面面向的是潛在的功能需求和非功能需求。

非功能需求，通常要考慮系統(tǒng)的存儲能力、吞吐能力和容錯能力等，最常見的就是我們常說的“日活”或“并發(fā)”，這些性能指標(biāo)會影響到我們的軟件架構(gòu)，例如，上面提到的多人博客系統(tǒng)，可能大部分情況下可能只有幾千到一兩萬的日活，這種情況下單體架構(gòu)肯定能撐得住，但如果這個多人博客系統(tǒng)是 Tumblr 或 Medium 話，就必須是分布式架構(gòu)。確立非功能需求，一方面是為了保證我們的軟件架構(gòu)能夠支撐起我們的業(yè)務(wù)量，另一方面也是為了防止我們對軟件架構(gòu)做過度設(shè)計，為系統(tǒng)開發(fā)帶來不必要的復(fù)雜度。另外，這也為系統(tǒng)的性能測試提供了依據(jù)。

綜上，在軟件項目中，如果要把需求分析做到位，止于功能架構(gòu)分析才是保險的。

最后，上文中還要一些內(nèi)容沒有講清說透，做以下補(bǔ)充：

1. 軟件項目團(tuán)隊，需求可以由專人負(fù)責(zé)，也可以分?jǐn)偟剿虚_發(fā)者身上，但無論何種情況，需求分析盡量全員參與進(jìn)去，以避免后續(xù)階段在理解需求上浪費(fèi)沒必要的時間。

2. 軟件項目的主要參與者是計算機(jī)相關(guān)背景的開發(fā)者，而軟件項目面向的卻是各行各業(yè)，對于有行業(yè)專業(yè)背景限制的項目，如建筑、金融、醫(yī)療領(lǐng)域的業(yè)內(nèi)應(yīng)用，團(tuán)隊里需要有行業(yè)專家，以保證做原始需要分析和業(yè)務(wù)架構(gòu)分析是，能夠接地氣，成果符合甚至超出預(yù)期。

3. 需求分析階段通常也要提供原型，原型設(shè)計的主要工作，要在業(yè)務(wù)架構(gòu)分析階段定稿。

4. 功能架構(gòu)分析和軟件架構(gòu)設(shè)計是緊密結(jié)合在一起的，沒有嚴(yán)格的界限，“做什么”和“怎么做”之間的度，各項目團(tuán)隊需要結(jié)合實際情況自行把握。

5. 需求做不到位，項目做不好，先想清楚再做開發(fā)。

6. 做項目和做產(chǎn)品是不盡相同的，本文面向的是做軟件項目，如果你的團(tuán)隊是做產(chǎn)品的，可能要在實踐過程中要再做變通。

朵朵科技-商城搭建-軟件開發(fā)-小程序制作-系統(tǒng)網(wǎng)站開發(fā)