如何作好軟件項目需求分析？

對於軟件開發團隊而言，軟件開發的全過程是：作什麼 -> 怎麼作 -> 作 -> 成果檢驗 -> 交付部署；其中，「作什麼」對應的是需求分析過程，「怎麼作」對應於軟件架構設計過程，「作」對應於開發過程，「成果檢驗」對應於測試，部署由運維團隊執行後，若是達到用戶的要求，則軟件上線後進入軟件的運行生命週期。

在實際的軟件項目開發中，「作什麼」，「怎麼作」和「作」是緊密結合在一塊兒的，「作」，「成果檢驗」和「交付部署」一般也會是一個持續交付過程，「成果檢驗」的內容會受到「作什麼」的影響，開展「作什麼」階段的時候，也要考慮到如何部署和交付。因此軟件開發的全過程，都是緊密結合在一塊兒的，若是刻意劃分爲獨立的幾個階段，忽視其做爲一個整理的綜合影響，每一個環節的實施過程必然會遇到因上一階段考慮不周全帶來的問題，從而影響總體開發效率。

基於此，咱們的需求分析，從需求深度劃分，能夠分爲三個層次：原始需求分析、業務架構分析和功能架構分析。這三個層次依次遞進，沒有嚴格的界限。

原始需求分析

原始需求是從用戶或業務角度看到的，或應該有的需求，或項目團隊通過初步挖掘後整理出來的、未經進一步提煉的需求。

若是拿作項目與作產品作個類比，原始需求有點相似與產品經理所說的「用戶故事」，因爲原始需求多是開發者分析出來了，也多是行業專家或目標客戶 / 用戶提出來的，原始需求能夠不止步於「用戶故事」，在該階段作必定的業務邏輯的抽取和提煉，對接下來「業務架構」階段的需求分析也是有幫助的，因此這兩個階段不必確立一個嚴格的界限。

例如，對一個多人博客系統而言，原始需求多是這樣的：

而對於更有經驗的人而言，原始需求可能更加體系化：

首先，多人博客系統由前臺展現子系統和後臺管理子系統構成，兩個子系統的功能能夠分別來描述。

前臺子系統

前臺子系統應該對任何人可見，該子系統至少包含如下頁面或功能：

文章列表 + 概要頁面
文章詳情頁面
做者主頁
文章評論功能
文章搜索功能
側邊欄的目錄、tag 等博客經典功能
後臺子系統

後臺子系統只對登陸用戶開放，對應多人博客而言，該子系統應該分用戶組，爲不一樣類型用戶分配不一樣的權限，該子系統至少包含如下頁面或功能：

用戶登陸或註冊功能
根據不一樣用戶的權限，登陸後看到不一樣的頁面或功能
建立新文章
修改或刪除文章
維護博客名稱描述等內容的功能
原始需求階段作的，主要是需求是收集、整理和簡單分析工做，爲業務架構階段的需求分析奠基了基礎。

業務架構分析

業務架構階段的需求分析，是對原始需求的抽象和再提煉，在造成業務架構以前，首先要梳理清楚功能需求和非功能需求，非功能需求是爲接下來的功能架構及怎麼作鋪路的，本節暫不展開；功能需求又分爲「顯式的功能需求」和「潛在的功能需求」，如上一節列出的需求，均爲顯式功能需求，潛在的功能需求要從多個角度去考慮，如整理出用戶組、權限對應的完整業務邏輯，是屬於能夠推測並進一步開展工做的潛在功能需求，而修改密碼、我的信息、用戶管理和忘記密碼等功能，是上面漏掉的、但又會影響到系統完整性的潛在需求，而須要提供一個系統初始化接口的功能需求，是站在運維實施角度提出來的潛在需求。

當業務架構梳理過程當中，尤爲是整理潛在功能需求時，必定會發現上一階段疏漏或在上一階段的視角下考慮不到的需求點，此時應結合項目的進度要求，考慮是否進行一輪需求的迭代和補充。

對上文提到的多人博客系統而言，業務架構能夠設計以下：

多人博客系統業務架構

作好業務架構，是爲整個軟件項目邁出堅實的第一步。業務架構是需求分析中最重要的階段，經歷了整理業務架構分析的過程，基本上才真正把系統需求梳理出來了，若是簡單粗暴的在需求和開發之間切出一個交接面，把交接面放在業務架構上是比較合適的，系統開發的底線是要與業務架構保持一致，後續的需求迭代或變動，也要基於業務架構擴展或重構。

業務架構對軟件系統開發也有重要影響。開發軟件系統，一般要求具有充分的可擴展性，而可擴展性，在需求分析階段就奠基了基礎，需求分析作的充分，就能在很大程度上給系統可擴展性定性了，當增長新功能時，系統可否擴展功能，仍是系統的某些功能要打破重來，業務架構階段就能看出端倪。好比，若是想在多人博客系統中增長用戶的社交功能，能夠把該功能插入到用戶模塊和我的模塊中去，也能夠單獨開一個社交模塊來封閉相關功能，前者會更多的打破原有業務邏輯，從而改變已有功能的代碼實現，然後者更多的是在新的模塊中梳理業務邏輯，開發新功能，前者重構多於擴展，然後者擴展多於重構。因此若是業務架構設計的具備足夠的擴展性，至關於軟件系統先天具有較強的可擴展性。

功能架構分析

業務架構爲軟件系統的開發奠基了基礎，在實際的軟件項目中，一般能夠在此基礎上讓需求分析再往前邁一步，將"作什麼"和「怎麼作」是緊密聯繫起來，承上啓下，我將這部分需求分析稱之爲「功能架構分析」。

爲何需求分析中要作功能架構分析？

定性的說，這一步工做也能夠歸入「怎麼作」的環節再開展，但我認爲把它做爲需求分析的最後階段，對整個項目過程而言更有效率。這部分工做依然是圍繞需求分析展開的，前文所述的需求分析工做一般開發者也會參與進去，因此業務架構分析和功能架構分析原本就是銜接在一塊兒的連續過程，若是把這一步工做從需求分析中拋離，項目進行到怎麼作或作的階段時，發現現實（代碼邏輯和系統實施）和理想（業務邏輯）不一致的機率會更大，開發過程當中可能會有更多關於「需求分析沒作到位」的扯皮，甚至不得不從新返回需求分析階段再次梳理需求，這都會帶來本可避免的項目進度延誤。

因此，需求分析若是隻考慮「原始需求」和「業務架構」兩個維度，是有盲點的，功能架構分析雖然能夠做爲「怎麼作」的第一步，但把它做爲「作什麼」的最後一步，能有效減小由於沒有「向後看」帶來的需求分析不充分的問題，可以把需求和實現更緊密的結合在一塊兒，它在必定程度上對業務架構作了進一步的細化，也在必定程度上影響了業務架構的最終成果。

功能架構分析怎麼作？

功能架構沒必要刻意設計的與業務架構不一樣，但功能架構分析的關注點已是爲怎麼作和作這兩個階段鋪路了，是怎麼作的基礎，「怎麼作」是架構師負責的，功能架構分析最好也由須要架構師來牽頭和落實。

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

（1）再次提煉和抽象業務功能

博客系統比較簡單，其業務架構和功能架構可能基本上是一致的。對於複雜的業務系統而言，業務架構分析階段提煉的業務功能，是有可能被再次提煉的，如：

OA 系統中，咱們從業務架構的視角看，能夠整理出如「計劃管理」、「任務管理」和「表單管理」等模塊，這些模塊的業務流程都會包含「審批流程」、「短信通知」、「郵件通知」等基礎功能，這些功能在每一個業務模塊中，功效相似，但在業務架構的視角和顆粒度上，不必定能清晰的表達出來，但梳理功能架構的時候，能夠將此做爲從相關業務模塊的核心業務邏輯中剝離的非核心業務邏輯，做爲基礎功能模塊放到功能架構的恰當位置。

OA 系統中，可能還存在一些功能模塊，涉及到上傳附件、預覽或下載附件等功能，甚至在此以外還會有獨立的「文檔管理」模塊，順着上一段的思路，咱們可能都意識到了「文件存儲管理」也能夠獨立出來做爲基礎功能模塊來實現；而有相關開發經驗的人還知道，文件有大有小，大文件存儲、管理和消費的業務邏輯和零散小文件相似業務邏輯的實現及性能上可能會有很大差異，致使不一樣的應用場景對應不一樣的實現方案，如某些業務場景下，該模塊是能夠與系統其它模塊集成在一塊兒的，而另一些場景下，該模塊需求獨立出來，單獨服務器部署，另外文件的存儲、備份和恢復機制等，也都要考慮進去。這些都是使得看似簡單的文件存儲功能，在具體實現和實施上很是麻煩，而這些多是「業務架構分析」中難以免的盲點。

因此業務架構分析階段，雖然可以作到把業務需求和邏輯完整的整理出來，但不必定能把構成每一個業務邏輯的單位功能一一提煉和組織起來，也可能會由於缺少功能開發和系統性能上的背景知識，忽視某些須要單獨處理的功能或模塊的特殊性，爲系統的穩定性和可擴展性埋下隱患，因此，在業務架構分析以後，在開發以前，必定要作「功能架構分析」。

業務架構是面向用戶的，功能架構是面向開發者的，功能架構和業務架構是一致的，且功能架構能夠看作是業務架構的超集。

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

非功能需求方面的考慮，其實已經屬於架構師在怎麼作階段的起步了，怎麼作的主要成果是軟件架構，而設計軟件架構要考慮的兩個維度是「業務架構」和「業務量級」。設計軟件架構，一方面要保證軟件系統的功能符合用戶預期，另外一方面，也是更重要的是，軟件系統要能被正常部署、使用、維護和監控，前者對應的是原始須要和業務架構的初級階段，後面面向的是潛在的功能需求和非功能需求。

非功能需求，一般要考慮系統的存儲能力、吞吐能力和容錯能力等，最多見的就是咱們常說的「日活」或「併發」，這些性能指標會影響到咱們的軟件架構，例如，上面提到的多人博客系統，可能大部分狀況下可能只有幾千到一兩萬的日活，這種狀況下單體架構確定能撐得住，但若是這個多人博客系統是 Tumblr 或 Medium 話，就必須是分佈式架構。確立非功能需求，一方面是爲了保證咱們的軟件架構可以支撐起咱們的業務量，另外一方面也是爲了防止咱們對軟件架構作過分設計，爲系統開發帶來沒必要要的複雜度。另外，這也爲系統的性能測試提供了依據。

綜上，在軟件項目中，若是要把需求分析作到位，止於功能架構分析纔是保險的。

合理而且有效地運用項目管理軟件，不只可讓咱們工做井井有理地進行，還能最大程度保證項目目標的達成。我推薦使用CORNERSTONE，它提供了包括任務/需求/測試管理、迭代規劃、缺陷追蹤、報表統計、團隊協做、WIKI、共享文件和日曆等功能模塊,如今申請20人如下團隊便可無償使用。