協議宣告：“本文為InfoQ中文站特供稿件
首發地址為：InfoQ 公眾號：軟體專案中，需求怎麼做？。
如需轉載，請與InfoQ中文站聯絡。
對於軟體開發團隊而言，軟體開發的全過程是：做什麼 -> 怎麼做 -> 做 -> 成果檢驗 -> 交付部署；其中，“做什麼”對應的是需求分析過程，“怎麼做”對應於軟體架構設計過程，“做”對應於開發過程，“成果檢驗”對應於測試，部署由運維團隊執行後，如果達到使用者的要求，則軟體上線後進入軟體的執行生命週期。
在實際的軟體專案開發中，“做什麼”，“怎麼做”和“做”是緊密結合在一起的，“做”，“成果檢驗”和“交付部署”通常也會是一個持續交付過程，“成果檢驗”的內容會受到“做什麼”的影響，開展“做什麼”階段的時候，也要考慮到如何部署和交付。所以軟體開發的全過程，都是緊密結合在一起的，如果刻意劃分為獨立的幾個階段，忽視其作為一個整理的綜合影響，每個環節的實施過程必然會遇到因上一階段考慮不周全帶來的問題，從而影響整體開發效率。
基於此，我們的需求分析，從需求深度劃分，可以分為三個層次：原始需求分析、業務架構分析和功能架構分析。這三個層次依次遞進，沒有嚴格的界限。
1. 原始需求分析
原始需求是從使用者或業務角度看到的，或應該有的需求，或專案團隊經過初步挖掘後整理出來的、未經進一步提煉的需求。
如果拿做專案與做產品做個類比，原始需求有點類似與產品經理所說的“使用者故事”，由於原始需求可能是開發者分析出來了，也可能是行業專家或目標客戶/使用者提出來的，原始需求可以不止步於“使用者故事”，在該階段做一定的業務邏輯的抽取和提煉，對接下來“業務架構”階段的需求分析也是有幫助的，所以這兩個階段沒必要確立一個嚴格的界限。
例如，對一個多人部落格系統而言，原始需求可能是這樣的：
- 要有個所有文章列表
- 能點選查閱文章
- 能評論文章
- 能建立新文章
- 能編輯刪除文章
- 要有許可權機制
而對於更有經驗的人而言，原始需求可能更加體系化：
首先，多人部落格系統由前臺展示子系統和後臺管理子系統構成，兩個子系統的功能可以分別來描述。
（1）前臺子系統
前臺子系統應該對任何人可見，該子系統至少包含以下頁面或功能：
- 文章列表+概要頁面
- 文章詳情頁面
- 作者主頁
- 文章評論功能
- 文章搜尋功能
- 側邊欄的目錄、tag等部落格經典功能
（2）後臺子系統
後臺子系統只對登入使用者開放，對應多人部落格而言，該子系統應該分使用者組，為不同型別使用者分配不同的許可權，該子系統至少包含以下頁面或功能：
- 使用者登入或註冊功能
- 根據不同使用者的許可權，登入後看到不同的頁面或功能
- 建立新文章
- 修改或刪除文章
- 維護部落格名稱描述等內容的功能
原始需求階段做的，主要是需求是收集、整理和簡單分析工作，為業務架構階段的需求分析奠定了基礎。
2. 業務架構分析
業務架構階段的需求分析，是對原始需求的抽象和再提煉，在形成業務架構之前，首先要梳理清楚功能需求和非功能需求，非功能需求是為接下來的功能架構及怎麼做鋪路的，本節暫不展開；功能需求又分為“顯式的功能需求”和“潛在的功能需求”，如上一節列出的需求，均為顯式功能需求，潛在的功能需求要從多個角度去考慮，如整理出使用者組、許可權對應的完整業務邏輯，是屬於可以推測並進一步開展工作的潛在功能需求，而修改密碼、個人資訊、使用者管理和忘記密碼等功能，是上面漏掉的、但又會影響到系統完整性的潛在需求，而需要提供一個系統初始化介面的功能需求，是站在運維實施角度提出來的潛在需求。
當業務架構梳理過程中，尤其是整理潛在功能需求時，一定會發現上一階段疏漏或在上一階段的視角下考慮不到的需求點，此時應結合專案的進度要求，考慮是否進行一輪需求的迭代和補充。
對上文提到的多人部落格系統而言，業務架構可以設計如下：
做好業務架構，是為整個軟體專案邁出堅實的第一步。業務架構是需求分析中最重要的階段，經歷了整理業務架構分析的過程，基本上才真正把系統需求梳理出來了，如果簡單粗暴的在需求和開發之間切出一個交接面，把交接面放在業務架構上是比較合適的，系統開發的底線是要與業務架構保持一致，後續的需求迭代或變更，也要基於業務架構擴充套件或重構。
業務架構對軟體系統開發也有重要影響。開發軟體系統，通常要求具備充分的可擴充套件性，而可擴充套件性，在需求分析階段就奠定了基礎，需求分析做的充分，就能在很大程度上給系統可擴充套件性定性了，當增加新功能時，系統能否擴充套件功能，還是系統的某些功能要打破重來，業務架構階段就能看出端倪。比如，如果想在多人部落格系統中增加使用者的社交功能，可以把該功能插入到使用者模組和個人模組中去，也可以單獨開一個社交模組來封閉相關功能，前者會更多的打破原有業務邏輯，從而改變已有功能的程式碼實現，而後者更多的是在新的模組中梳理業務邏輯，開發新功能，前者重構多於擴充套件，而後者擴充套件多於重構。所以如果業務架構設計的具有足夠的擴充套件性，相當於軟體系統先天具備較強的可擴充套件性。
3. 功能架構分析
業務架構為軟體系統的開發奠定了基礎，在實際的軟體專案中，通常可以在此基礎上讓需求分析再往前邁一步，將"做什麼"和“怎麼做”是緊密聯絡起來，承上啟下，我將這部分需求分析稱之為“功能架構分析”。
3.1 為什麼需求分析中要做功能架構分析？
定性的說，這一步工作也可以納入“怎麼做”的環節再開展，但我認為把它作為需求分析的最後階段，對整個專案過程而言更有效率。這部分工作依然是圍繞需求分析展開的，前文所述的需求分析工作通常開發者也會參與進去，所以業務架構分析和功能架構分析本來就是銜接在一起的連續過程，如果把這一步工作從需求分析中拋離，專案進行到怎麼做或做的階段時，發現現實（程式碼邏輯和系統實施）和理想（業務邏輯）不一致的概率會更大，開發過程中可能會有更多關於“需求分析沒做到位”的扯皮，甚至不得不重新返回需求分析階段再次梳理需求，這都會帶來本可避免的專案進度延誤。
所以，需求分析如果只考慮“原始需求”和“業務架構”兩個維度，是有盲點的，功能架構分析雖然可以作為“怎麼做”的第一步，但把它作為“做什麼”的最後一步，能有效減少因為沒有“向後看”帶來的需求分析不充分的問題，能夠把需求和實現更緊密的結合在一起，它在一定程度上對業務架構做了進一步的細化，也在一定程度上影響了業務架構的最終成果。
3.2 功能架構分析怎麼做？
功能架構不必刻意設計的與業務架構不同，但功能架構分析的關注點已經是為怎麼做和做這兩個階段鋪路了，是怎麼做的基礎，“怎麼做”是架構師負責的，功能架構分析最好也由需要架構師來牽頭和落實。
功能架構分析的主要內容有2點：（1）再次提煉和抽象業務功能；（2）確認和完善非功能需求。
（1）再次提煉和抽象業務功能
部落格系統比較簡單，其業務架構和功能架構可能基本上是一致的。對於複雜的業務系統而言，業務架構分析階段提煉的業務功能，是有可能被再次提煉的，如：
OA系統中，我們從業務架構的視角看，可以整理出如“計劃管理”、“任務管理”和“表單管理”等模組，這些模組的業務流程都會包含“審批流程”、“簡訊通知”、“郵件通知”等基礎功能，這些功能在每個業務模組中，功效類似，但在業務架構的視角和顆粒度上，不一定能清晰的表達出來，但梳理功能架構的時候，可以將此作為從相關業務模組的核心業務邏輯中剝離的非核心業務邏輯，作為基礎功能模組放到功能架構的恰當位置。
OA系統中，可能還存在一些功能模組，涉及到上傳附件、預覽或下載附件等功能，甚至在此之外還會有獨立的“文件管理”模組，順著上一段的思路，我們可能都意識到了“檔案儲存管理”也可以獨立出來作為基礎功能模組來實現；而有相關開發經驗的人還知道，檔案有大有小，大檔案儲存、管理和消費的業務邏輯和零散小檔案類似業務邏輯的實現及效能上可能會有很大差別，導致不同的應用場景對應不同的實現方案，如某些業務場景下，該模組是可以與系統其它模組整合在一起的，而另外一些場景下，該模組需求獨立出來，單獨伺服器部署，另外檔案的儲存、備份和恢復機制等，也都要考慮進去。這些都是使得看似簡單的檔案儲存功能，在具體實現和實施上非常麻煩，而這些可能是“業務架構分析”中難以避免的盲點。
所以業務架構分析階段，雖然能夠做到把業務需求和邏輯完整的整理出來，但不一定能把構成每個業務邏輯的單位功能一一提煉和組織起來，也可能會因為缺乏功能開發和系統效能上的背景知識，忽視某些需要單獨處理的功能或模組的特殊性，為系統的穩定性和可擴充套件性埋下隱患，所以，在業務架構分析之後，在開發之前，一定要做“功能架構分析”。
業務架構是面向使用者的，功能架構是面向開發者的，功能架構和業務架構是一致的，且功能架構可以看做是業務架構的超集。
（2）確認和完善非功能需求
非功能需求方面的考慮，其實已經屬於架構師在怎麼做階段的起步了，怎麼做的主要成果是軟體架構，而設計軟體架構要考慮的兩個維度是“業務架構”和“業務量級”。設計軟體架構，一方面要保證軟體系統的功能符合使用者預期，另一方面，也是更重要的是，軟體系統要能被正常部署、使用、維護和監控，前者對應的是原始需要和業務架構的初級階段，後面面向的是潛在的功能需求和非功能需求。
非功能需求，通常要考慮系統的儲存能力、吞吐能力和容錯能力等，最常見的就是我們常說的“日活”或“併發”，這些效能指標會影響到我們的軟體架構，例如，上面提到的多人部落格系統，可能大部分情況下可能只有幾千到一兩萬的日活，這種情況下單體架構肯定能撐得住，但如果這個多人部落格系統是Tumblr或Medium話，就必須是分散式架構。確立非功能需求，一方面是為了保證我們的軟體架構能夠支撐起我們的業務量，另一方面也是為了防止我們對軟體架構做過度設計，為系統開發帶來不必要的複雜度。另外，這也為系統的效能測試提供了依據。
綜上，在軟體專案中，如果要把需求分析做到位，止於功能架構分析才是保險的。
4. What's more？
最後，上文中還要一些內容沒有講清說透，做以下補充：
- 軟體專案團隊，需求可以由專人負責，也可以分攤到所有開發者身上，但無論何種情況，需求分析儘量全員參與進去，以避免後續階段在理解需求上浪費沒必要的時間。
- 軟體專案的主要參與者是計算機相關背景的開發者，而軟體專案面向的卻是各行各業，對於有行業專業背景限制的專案，如建築、金融、醫療領域的業內應用，團隊裡需要有行業專家，以保證做原始需要分析和業務架構分析是，能夠接地氣，成果符合甚至超出預期。
- 需求分析階段通常也要提供原型，原型設計的主要工作，要在業務架構分析階段定稿。
- 功能架構分析和軟體架構設計是緊密結合在一起的，沒有嚴格的界限，“做什麼”和“怎麼做”之間的度，各專案團隊需要結合實際情況自行把握。
- 需求做不到位，專案做不好，先想清楚再做開發。
- 做專案和做產品是不盡相同的，本文面向的是做軟體專案，如果你的團隊是做產品的，可能要在實踐過程中要再做變通。
注：轉載本文，請與Gevin聯絡
歡迎關注我的微信公眾賬號
