理順軟件開發各個環節-4

 

4.4 軟件需求分析

  軟件需求分析,對開發團隊而言,是軟件開發工做的起點。 運維

  軟件需求分析,是很是重要的節點,但實際狀況是,在敏捷開發時代,不少研發團隊錯把產品需求做爲軟件需求。產品需求是以用戶的語言表述的,而軟件需求是開發人員的語言表達的,二者的受衆是不一樣的。所以,軟件需求分析不可省略。測試

  不作軟件需求分析,我認爲有如下問題:spa

  •  開發人員在開發軟件時,根據產品需求,本身腦子裏仍然有作軟件需求分析,或者在草稿紙塗塗寫寫,梳理一下,這種「線下」的作法沒有通過評審環節,質量難以保障,返工的狀況不少;
  •  不一樣開發人員本身作的「線下」需求分析,相互之間溝通成本很高,軟件需求碎片化,致使軟件需求的完整性很成問題,開發的軟件容易埋下更多的坑;
  •  沒有文檔化的軟件需求分析,軟件產品的維護成本很高。

  我認爲,對產品需求的理解要完整,而後用開發人員理解的語言將之表達出來,即軟件需求分析,基於此的系統分析設計纔有可能符合產品需求,而不至於由於對某些需求的忽視,在後期加入時發現系統結構失效的狀況發生。設計

4.4.1 軟件需求分析節點關鍵信息

責任人:開發項目經理。接口

執行人:系統分析員、高級程序員或架構師。資源

關鍵行爲:分析和溝通。開發

  • 分析:對產品需求進行分析,或者說對每一個用戶故事進行分析;文檔

  • 溝通:

    • 與產品經理溝通;

    • 必要時,與最終用戶溝通;

    • 與產品的上下游接口方溝通;

    • 開發團隊內部的討論溝通。

輸入

  • 產品需求規格書;

  • UI&UE交互設計原型(若是有);

  • 用戶故事;

  • 相關標準化文件:

    • 國際標準、規範;

    • 國家標準;

    • 行業標準;

    • 企業標準。

  • 相關外部接口文檔。

輸出

  • 軟件需求規格書(SRS);

  • 數據字典(DD);

  • 相關接口文檔。

職責要求

  • 完整地分析產品需求;

  • 分析每一個產品需求項或用戶故事:

    • 需求表達是否清晰?

    • 有無須要澄清的問題?若有,經過反覆溝通來澄清;

    • 技術可行性:是否存在較大的未知技術風險,必要時預研一下;

    • 用戶故事要素是否完備?

    • 特別是驗收標準,如無,與產品經理一塊兒商定,驗收標準要合理。

      • 較高的標準:意味着較高的代價;

      • 較低的標準:用戶體驗差。

    • 暫不開發的需求項:需簡單地評估技術可行性,避免依據局部需求而作出的設計方案不能知足將來需求;能夠不詳細展開分析。

  • 提請軟件需求評審:

    • 需求分析人員:主講人,負責講解和答覆各類質詢和疑問;

    • 產品經理:評估產品需求是否被清晰、完整、無差錯地表述,有無技術障礙;

    • 用戶表明(市場、銷售、客服):最好對業務比較熟悉,對錶明的角色的需求較明晰,評估需求的完整性、準確性;

    • 項目經理:瞭解需求的相關方,便於協調開發、測試、部署資源;

    • 開發技術人員:瞭解軟件需求,便於開發時對業務的理解;

    • 測試技術人員:瞭解軟件需求,便於測試時對業務的理解,重點是需求的可驗證性;

    • 運維人員:瞭解軟件需求,對產品部署的需求。

相關文章
相關標籤/搜索