《需求工程——軟體建模與分析》讀書筆記二

標籤：

前一陣子，繼續讀了《需求工程——軟體建模與分析》。之前瞭解了需求工程的概論和需求的捕獲，分別講了需求捕獲中的困難。擷取資訊的方法和來源；學會分析項目的前景；確定系統邊界；涉眾分析與硬資料擷取；在需求捕獲時的方法：面談，問卷調查，頭腦風暴，原型，觀察與文檔審查；

這次讀的主要是介紹需求分析和需求文檔化和驗證。其中介紹了需求分析技術，需求分析方法等；建模（過程建模，資料建模，物件導向建模）；需求規格說明；需求驗證。

經過這次讀書，我發現需求萃取的根本任務是：1、建立分析模型，達成開發人員和使用者對需求資訊的共同理解。2、依據共同的理解，發揮創造性，建立軟體系統解決方案。在長期的研究與發展中，產生了很多的需求分析技術，常見的有上下文圖，資料流圖，實體聯絡圖，功能實體矩陣，過程依賴圖，使用案例圖，類圖，互動圖，活動圖表，對象約束語言，微規格說明，資料字典，狀態圖等等。需求分析階段的任務是確定軟體系統功能。軟體需求分析是研究使用者需求得到的東西，完全理解使用者對軟體需求的完整功能，確認使用者軟體功能需求，建立可確認的、可驗證的一個基本依據。軟體需求分析是一個項目的開端，也是項目實施最重要的關鍵點。據有關的機構分析結果表明，我們設計的軟體產品存在不完整性、不正確性等問題80％以上是需求分析錯誤所導致的，而且由於需求分析錯誤造成根本性的功能問題尤為突出。因此，一個項目的成功軟體需求分析是關鍵的一步。為了保證項目的正常實施，並且能夠順利的完成，我們必須加強專案管理和重視項目分析工作。我們只有從實際出發，切切實實地把握使用者需求，把握使用者需求目標，把握使用者將來功能界定，保證我們開發工作正確性方向。三種需求分析的方法：結構化分析方法、物件導向的分析方法、面向問題域的分析方法。需求分析活動的一個重要任務是進行需求細化，明確使用者需求的隱含資訊，展開為明確的對軟體系統的行為期望，即系統需求。這些細化後的系統需求從軟體和技術的角度，以可度量的方式定義了軟體系統的驗收標準。對問題域以及需求資訊的建模工作能夠能夠協助揭示問題世界中的隱含因素，系統模型就是將各種隱含因素加以明確後的抽象知識模型。因此，需求細化是在系統模型的基礎之上進行的。一方面，它要明確使用者需求的隱含因素，為軟體系統的建立和實現提供充分的資訊支援；另一方面，它要將從問題域和業務的角度表述的使用者需求等價的轉化為從軟體和技術的角度表述的系統需求，以協助軟體開發人員對需求形成恰當和準確的理解。

在需求的文檔化和驗證方面，我瞭解了編寫需求規格說明文檔的原因：一方面，清晰、明確、結構化的文檔可以將軟體系統的需求資訊和解決方案更好的傳遞給所有的開發人員。另一方面，文檔可以拓展人們知識記憶能力。需求規格說明文檔存在不同的類型，表現在：文檔的名稱、內容、組織方式、表達方式、用途和作用不同。其中優秀的需求規格說明文檔具備的特徵：正確性、無歧義、完備性、一致性、根據重要性和穩定性分級、可驗證性、可修性、可跟蹤。需求文檔的規範書寫可以讓軟體在以後的開法中少走彎路，能根據文檔開發出客戶所提的需求，能讓軟體的開發更加順利。在需求分析中文檔的編寫是其中的重要一步，其重要性在於文檔的好壞能直接影響到該項目的開發速度及開發出軟體的品質。所以在文檔編寫時我們一定要規範書寫，規範的需求文檔能體現一個開發人員的素質，好的開發習慣。而需求驗證的活動是為了確定以下幾方面的內容： 軟體需求規格說明正確描述了預期的系統行為和特徵，系統需求或其它來源中得到軟體需求，需求是完整的和高品質的，有對需求的看法是一致的，需求為繼續進行產品設計、構造和測試提供了足夠的基礎。正式技術評審的最好類型叫作審查，對需求文檔的審查是可利用的最進階軟體品質技術。要深入的瞭解驗證和確診的實質意義，就有必要在整個軟體工程的架構下來理解系統驗證意義。在需求分析的過程中，需要我們不斷地整理、分析，注重每一個細節，確定好系統的邊界。

《需求工程——軟體建模與分析》讀書筆記二