參考博客https://www.cnblogs.com/alabo1999/p/12933811.html
軟件需求分析
軟件需求分析，對於開發團隊而言，是軟件開發工作的起點。
軟件需求分析，是非常重要的節點，但是實際情況是，在敏捷開發時代，很多研發團隊錯把產品需求作為軟件需求。產品需求是以用戶的語言表述的，而軟件需求是開發人員語言表達的，兩者的受眾是不同的。因此，軟件需求分析不可省略。
不做軟件需求分析，我認為有以下問題：
1開發人員在開發軟件時，根據產品需求，自己腦子里仍然有做軟件需求分析，或者在草稿紙塗塗寫寫，梳理以下，這種“線下”的做法沒有經過評審環節，質量難以保障，返工的情況很多
2不同開發人員自己做的”線下“需求分析，相互之間溝通成本很高，軟件需求碎片化，導致軟件需求的完整性很成問題，開發的軟件容易埋下更多的坑
3沒有文檔化的軟件需求分析，軟件產品的維護成本很高
對產品需求理解完整，然后用開發人員理解的語言將之表達出來，即軟件需求分析，基於此的系統分析設計才有可能符合產品需求，而不至於因為對某些需求的忽視，在后期加入時發現系統結構失效的情況發生。
軟件需求分析節點關鍵信息
責任人：開發項目經理
執行人：系統分析員、高級程序員或架構師
關鍵行為：分析和溝通
分析：對產品需求進行分析，或者說對每個用戶故事進行分析
溝通：
與產品經理溝通；
必要時，與最終用戶溝通；
與產品的上下游接口方溝通；
開發團隊內部的討論溝通
輸入：
產品需求規格書
UI&UE交互設計原型
用戶故事
相關標准化文件（國際標准 國家標准 行業標准 企業標准）
相關外部接口文檔
輸出：
軟件需求規格書（SRS）
數據字典（DD）
相關接口文檔
職責要求：
1完整地分析產品需求
2分析每個產品需求項或用戶故事
需求表達是否清晰？
有無需要澄清的問題？如有，通過反復溝通來澄清
技術可行性：是否存在較大的未知技術風險，必要時，預研一下
用戶故事要素是否完備
特別是驗收標准，如無，與產品經理一起商定，驗收標准要合理。
較高的標准：意味着較高的代價
較低的標准：用戶體驗差
暫不開發的需求項：需簡單地評估技術可行性，避免依據局部需求而做出的設計方案不能滿足未來需求；可以不詳細展開分析。
提請軟件需求評審：
需求分析員：主講人，負責講解和答復各種質疑和疑問
產品經理：評估產品需求是否被清晰、完整、無差錯表述，有無技術障礙；
用戶代表（市場、銷售、客服）：最好對業務比較熟悉，對代表的角色的需求較明晰，評估需求完整性、准確性
項目經理：了解需求相關方，便於協調開發、測試、部署資源
開發技術人員：了解軟件需求，便於開發時對業務的理解
測試技術人員：了解軟件需求，便於測試時對業務的理解，重點是需求的可驗證性
運維人員：了解軟件需求，對產品部署的需求
軟件需求分析的必要性
1 因為軟件需求分析將產品轉化為軟件需求，即將用戶（業務）語言表達的產品需求轉化為開發人員語言表達的軟件需求，使得開發、測試人員更能准確、完整的理解需求
2因為軟件需求分析，清晰完整地表述軟件需求，基於此開展的設計方案才能考慮得更加全面、更加有彈性，評審設計方案也有據可依。
3只有做了軟件需求分析，才能了解軟件的需求集合的實際規模，估算軟件產品的開發工作量才能相對靠譜，再結合人力資源情況，給出開發計划。
只有產品需求清單，沒有做軟件需求分析的情況下，給出軟件開發計划是困難的。此時很多模塊是灰盒子，朦朦朧朧，軟件需求沒有明晰，工作量測算是拍腦袋定的。如果工作量算少了，后期開發時需頻繁調整開發計划，開發團隊加班加點還頂一個拖延進度的帽子，心情可想而知；如果工作量多算，管理者又不滿意，認為沒多少需求，怎么要這么多時間！因為沒有軟件需求分析，開發項目經理拿不出明細條目來，沒法據理力爭，結果開發計划往往是按領導的意思去做。
而做過軟件需求分析后，情況就大不相同
首先，全部的需求集是明晰的，每個需求項的工作量也容易測算的，因此工作量的估算不會偏差很多。其次，可以根據需求的優先級，結合開發資源情況，規划版本計划，確定在哪個時間點開發完成哪些需求項，提供些什么功能，達到什么效果？
軟件需求分析確實原因探討
軟件需求分析在瀑布式開發模式的時代，是不可逾越的階段。而如今，敏捷開發大行其道之時，很多研發團隊往往能省則省。為什么如此：
1 一部分管理者對軟件需求分析的重要性理解不足，軟件需求分析需要時間，這段時間只是紙面作業，看不到有形的輸出，不願意付出這些時間成本。
2 軟件需求分析和設計階段，不需要整個開發團隊的成員全部參與，這段時間的工作安排，對開發管理者是個挑戰，如果針對產品需求，直接編碼實現，這樣大家都有活干了。
3 需求變更時，軟件需求分析文檔的及時更新維護成本過高，經常沒有及時更新，導致需求說明書最后版本與實際有所偏差，最后流於形式。