理順軟件開發各個環節-8（需求管理-軟件需求分析探討）

4.4.5軟件需求分析探討

　　本節探討一下軟件需求分析在實際操做中的幾個問題。

4.4.5.1軟件需求分析的必要性

　　個人見解，軟件需求分析是十分必要的。

　　1）由於軟件需求分析將產品需求轉換爲軟件需求，即將用戶（業務）語言表達的產品需求轉換爲開發人員語言表達的軟件需求，使得開發、測試人員更能準確、完整地理解需求。
　　2）由於軟件需求分析，清晰、完整地表述的軟件需求，基於此開展的設計方案纔有可能考慮得更加全面、更加有彈性，評審設計方案也有據可依。

　　3）只有作了軟件需求分析，才能瞭解軟件的需求集合的實際規模，估算軟件產品的開發工做量才能相對較靠譜，再結合人力資源狀況，給出開發計劃。

　　只有產品需求清單，沒有作軟件需求分析的狀況下，給出軟件開發計劃是困難的。此時不少模塊是灰盒子，朦朦朧朧，軟件需求沒有明晰，工做量測算是拍腦殼定的。若是工做量算少了，後期開發時需頻繁調整開發計劃，開發團隊加班加點還頂一個拖延進度的帽子，心情可想而知；若是工做量多算，管理者又不滿意，認爲沒多少需求，怎麼要這麼多時間！由於沒有軟件需求分析，開發項目經理拿不出明細條目來，無法力排衆議，結果開發計劃每每是按領導的意思去作。

　　而作過軟件需求分析後，狀況就大不相同。

　　首先，所有的需求集是明晰的，每一個需求項的工做量也容易測算的，所以工做量的估算不會誤差不少。

　　其次，能夠根據需求的優先級，結合開發資源狀況，規劃版本計劃，肯定在哪一個時間點開發完成哪些需求項，提供些什麼功能，達到什麼效果？

　　所以，個人觀點是軟件需求分析階段不可省。

4.4.5.2軟件需求分析缺失緣由探討

　　軟件需求分析在瀑布式開發模式時代，是不可逾越的階段。而現在，敏捷開發大行其道之時，不少研發團隊每每能省則省。

　　爲何如此？

　　個人理解是：

　　首先，一部分管理者對軟件需求分析的重要性理解不足，軟件需求分析須要時間，這段時間只是紙面做業，看不到有形的輸出，不肯意付出這些時間成本。

　　其次，軟件需求分析和設計階段，不須要整個開發團隊的成員所有參與，這段時間的工做安排，對開發管理者是個挑戰；若是針對產品需求，直接編碼實現，這樣你們都有活幹了。

　　再次，需求變動時，軟件需求分析文檔的及時更新維護成本太高，常常沒有及時更新，致使軟件需求規格書最後版本與實際有所誤差，最後流於形式。

4.4.5.3軟件需求分析的執行者

　　軟件需求分析的分析人員，須要什麼資質？

　　我認爲須要系統分析員或高級程序員，最低程度爲中級程序員偏上水平，不少狀況是系統分析員（或高級程序員）帶領1到2位中高級程序員來作。需求分析時候，還須要常常與產品經理及客戶溝通。

　　由於軟件需求分析，是一項創造性的智力勞動。如Use Case的表達方式，實際上，須要想象需求使用場景，正常過程是什麼流程？有哪些可選過程？有哪些異常過程？考慮得越全面，分析質量越高，爲後期開發帶來的益處越多。

　　以前我有過經歷，帶領一個開發小組一塊兒作軟件需求分析，結果是慘不忍睹，有些成員對需求爲何用、如何用Use Case形式來表達軟件需求理解不深，作出來的需求分析質量可想而知；還有即便掌握了Use Case形式的軟件需求表達方式，但對正常過程的每個步驟，沒有去質問這一步是否可能發生異常，有哪些可能的異常過程，這樣異常過程輕描淡寫，軟件需求分析質量也不會很高。

　　所以，作好軟件需求分析，須要能力和責任心的結合。

　　等軟件需求分析經過評審後，能夠安排時間給開發團隊的其它人來說解，一樣達到使之理解需求的目的。

4.4.5.4軟件需求分析不只僅是產品需求的細化

　　軟件需求分析一方面是對產品需求的細化，對每一個需求項，或功能需求、非功能需求等，羅列具體的需求規格。但不只限於此。

　　軟件需求分析還伴隨着初步的模塊劃分和架構設計。模塊劃分是歸併需求子集，將功能相關的需求項歸於同一個模塊中；而架構設計，則從系統實現角度，設計哪些功能、邏輯處理模塊，通常可以使用C4設計模式（C4模式中的Code視圖通常忽略）。

　　爲何軟件需求分析須要初步的模塊劃分和架構設計？

　　舉個栗子：
　　對於通訊協議而言，通常使用CSN.1或ASN.1語法來描述的，如3GPP協議。一個具體協議的解碼模塊的需求，有兩種處理方法。

　　方法1，使用硬coding方式，來解碼，即按照具體的通訊協議，按照ASN.1語法，逐個結構來解析，解析結構存入一個個消息結構中。

　　方法2，開發通用的ASN.1的解碼器，針對某個ASN.1的協議的相關腳本，解碼器輸出特定計算機語言（如C++）的解碼代碼文件。

　　方法1和方法2均可以知足需求，但二者的開發難度和工做量是不一樣的。

　　方法1容易，但若是須要解碼的協議不少，工做線性疊加，最後實際工做量仍是很大的。

　　方法2有難度，可是屬於一勞永逸型，除非ASN.1的語法有擴展，但維護工做量也是不大的。這種方法對於有多個協議須要解碼，且通訊協議版本升級的狀況，後期工做量可忽略不計，且質量穩定可靠。方法2屬於配置化的設計思想。

　　對於產品需求而言，需求項就是：須要一個針對XX協議族的解碼。而軟件需求分析的結果，若是決定使用方法2，則須要進一步描述通用解碼器的軟件需求。

4.4.5.5軟件需求變動的文檔一致性維護

　　軟件需求變動，對於軟件而言，是很正常的，特別是前期需求不明確的狀況下，需求變動更是頻繁。關於軟件需求變動，在變動管理中詳細討論。

　　這裏重點探討一下，如何使得軟件需求發生變動時，軟件需求分析文檔能以比較低的代價得以維護，從而確保軟件需求符合軟件產品的最新狀況。

　　以前，使用word文檔格式，編寫軟件需求分析，輸出SRS文檔、DD文檔、及外部接口文檔等。

　　因爲文件的共享性問題，結果致使維護成本很高；做爲文檔發佈路徑的管理，有必定的權限控制，上傳更新成問題；相互之間傳遞，時間一長，可能不是最新版本。

　　軟件產品通過屢次迭代後，因爲不一樣的人員負責不一樣的模塊，其對需求也更瞭解，由其來維護需求也更可行；結果不一樣人員的維護不一樣的需求模塊，整合是一個問題。

　　使用Markdown形式，歸入git配置管理，是一個方案；可是文檔篇幅較長，還包含圖片，須要注意圖片更新，文件須要使用不一樣的連接地址，從而確保不一樣版本的圖片共存。

　　還有一種形式，只是個人理解（尚未嘗試），利用wiki的形式，來管理各需求項，維護軟件需求與軟件產品的一致性，是一個可行的方案。