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