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

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

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

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

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

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

1. 要有個(gè)所有文章列表

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

3. 能評論文章

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

5. 能編輯刪除文章

6. 要有權限機制

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

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

前臺子系統應該對任何人可見(jiàn)，該子系統至少包含以下頁(yè)面或功能：

1. 文章列表 + 概要頁(yè)面

2. 文章詳情頁(yè)面

3. 作者主頁(yè)

4. 文章評論功能

5. 文章搜索功能

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

后臺子系統只對登錄用戶(hù)開(kāi)放，對應多人博客而言，該子系統應該分用戶(hù)組，為不同類(lèi)型用戶(hù)分配不同的權限，該子系統至少包含以下頁(yè)面或功能：

• 用戶(hù)登錄或注冊功能

• 根據不同用戶(hù)的權限，登錄后看到不同的頁(yè)面或功能

• 創(chuàng )建新文章

• 修改或刪除文章

• 維護博客名稱(chēng)描述等內容的功能

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

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

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

多人博客系統業(yè)務(wù)架構

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

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

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

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

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

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

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

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

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

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

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

（2）確認和完善非功能需求

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

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

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

最后，上文中還要一些內容沒(méi)有講清說(shuō)透，做以下補充：

1. 軟件項目團隊，需求可以由專(zhuān)人負責，也可以分攤到所有開(kāi)發(fā)者身上，但無(wú)論何種情況，需求分析盡量全員參與進(jìn)去，以避免后續階段在理解需求上浪費沒(méi)必要的時(shí)間。

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

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

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

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

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

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