《需求工程——軟件建模與分析》——閱讀筆記一

《需求工程——軟件建模與分析》——閱讀筆記一

第一部分是緒論，包括需求工程導論、需求基礎、需求工程過程等基礎內容。

軟件經歷了以「機器」爲中心、以「應用」爲中心、以「企業」爲中心3各階段，在以「機器」爲中心階段，軟件存在生產費時、費力和功能有限等諸多問題，因此沒有普遍得以應用，而到了以「應用」爲中心的階段，原有個體化「軟件做坊式」的軟件開發方法帶來諸多問題，因而計算機科學家們在1968年北大西洋公約組織是提出了「軟件危機」問題，當年秋季就提出了走「軟件工程」之路的發展方向。

進入90年代，軟件再次快速發展，軟件與企業的緊密融合，進入了以「企業」爲中心的階段。在20世紀90年代出現的大量軟件生產情況調查中發現，平均全部項目的使用的費用和時間超標嚴重，卻只平均完成了預計功能的61%。而從致使項目成敗的因素數據分析中能夠看到需求因素的影響比例佔到了極大的比重。

致使需求問題的一個重要緣由就是：未能很好的理解和掌握應用型軟件的模擬特性以及由此產生的一系列影響和需求。軟件能夠分爲三種類別：面向專業用戶的純工具型軟件、面向普通用戶的純工具型軟件和應用型軟件。前二者一個是功能越全越好，後一個是功可以用就好，而最後一個應用型軟件，其正確工做的方式是具備模擬性。在實際工做中，若是開發人員收到的工具型軟件相關評判標準、關注點及生產過程的影響過大，就會對應用型軟件的模擬特性理解不透徹或應用不堅定，進而致使對需求處理階段重視不足或者在需求階段輕視領域知識研究，應用型軟件的生產就會發生需求問題。UC瀏覽器的廣告語這是貼合了這個意思：給的再多，不如懂我。

需求問題的具體緣由分析以下：

1.非技術性和社會性因素重視不足；

2.傳統需求分析方法的缺陷；

3.軟件規模日益壯大；

4.需求問題的高代價性。

簡單的說，需求工程是全部需求處理活動的總和，它收集信息、分析問題、整合觀點、記錄需求並驗證其正確性，最終梵音軟件被應用後與環境互動造成的指望效應。

從軟件需求工程師所須要的知識和技能咱們能看出，需求工程師須要對「人」、對「用戶」有很深的瞭解，善於溝通、觀察和寫做。

首先咱們要了解需求的定義：

①用戶爲了解決問題或達到某些目標所須要的條件或能力。

②系統或系統部件爲了知足合同、標準、規範或其餘正式文檔所規定的要求而須要具有的條件或能力。

③對①和②中的一個條件或一種能力的一種文檔化表達。

定義中包含了用戶的觀點和開發者的觀點，不一樣羣體的人們也很難對定義進行一致和準確的解讀，由於需求概念的內涵和外延都很是豐富。

需求概念的內涵包括問題域與解系統、共享現象和需求規格說明，從他們之間的關係咱們能夠看出需求工程的困難之處，也剛好說明了需求工程的工做：

進行需求開發，肯定用戶的指望效果R。

‚研究問題背景，描述問題域特性E。

ƒ構建解系統，描述解系統行爲S,使得E,S |→ R。

需求概念的外延首先要將其分類，常見的標準將其分爲5類：功能需求、性能需求、質量屬性、對外接口和約束。

需求工程的執行路線：問題分析→需求獲取→需求分析→文檔化和驗證。其各個部分具體內容以下：

需求獲取：

1.收集背景資料；

2.定義項目前景和範圍；

3.選擇信息的來源；

4.選擇獲取方法、執行獲取；

5.記錄獲取結果。

需求分析：

1.背景分析；

2.肯定系統邊界；

3.需求建模；

4.需求細化；

5.肯定優先級；

6.需求協商；

需求規格說明：

1.定製文檔模板；

2.編寫文檔

需求驗證：

1.執行驗證；

2.問題驗證。

優秀需求的特性：完整性、正確性、精確性、可行性、必要性、無歧義和可驗證。

需求的影響力貫穿於整個軟件的產品生命週期，而不是單純的需求開發階段。在需求開發創建需求基線以後，還須要再設計、實現等後繼活動中處理來自客戶、管理層、銷售部門以及其餘涉衆羣體的變動請求。需求管理會進行變動控制，歸入和實現合理的變動請求，拒毫不合理的變動請求，控制變動的成本和影響範圍。在企業界的實踐中，需求變動被認爲是致使項目失敗的兩個只要緣由之一。