通過閱讀有效用力分析書籍，學習到了許多寶貴的經驗，現總結如下：

　　需求分析是介于系統分析和軟件設計階段之間的橋梁。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，并從軟件角度對它們進行檢查與調整；另一方面，需求規格說明又是軟件設計、實現、測試直至維護的主要基礎。良好的分析活動有助于避免或盡早剔除早期錯誤，從而提高軟件生產率，降低開發成本，改進軟件質量。
　　需求工程是隨著計算機的發展而發展的，在計算機發展的初期，軟件規模不大，軟件開發所關注的是代碼編寫，需求分析很少受到重視。后來軟件開發引入了生命周期的概念，需求分析成為其第一階段。隨著軟件系統規模的擴大，需求分析與定義在整個軟件開發與維護過程中越來越重要，直接關系到軟件的成功與否。人們逐漸認識到需求分析活動不再僅限于軟件開發的最初階段，它貫穿于系統開發的整個生命周期。80年代中期，形成了軟件工程的子領域——需求工程(requirementengineering,RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《RequirementsEngineering》。一些關于需求工程的工作小組也相繼成立，如歐洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，并開始開展工作。
　　需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統的所有外部特征的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特征和相關約束，形成需求文檔，并對用戶不斷變化的需求演進給予支持。RE可分為系統需求工程（如果是針對由軟硬件共同組成的整個系統）和軟件需求工程（如果僅是專門針對純軟件部分）。軟件需求工程是一門分析并記錄軟件需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟件，并通過一系列重復的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟件的需求描述和一些性能參數。
　　需求工程是一個不斷反復的需求定義、文檔記錄、需求演進的過程，并最終在驗證的基礎上凍結需求。80年代，HerbKrasner定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理。近來，MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證。
　　綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：
　　（1）需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；
　　（2）需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，并盡可能多的捕獲現實世界的語義；
　　（3）形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；
　　（4）需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；
　　（5）需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。

三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。
　　結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能范圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以采用更為直觀的原型系統方式和最終用戶進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的周期相對容易控制；通過業務全景圖，最終用戶也能了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以采用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和用戶確認一部分功能。

　　面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，采用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發現很多問題，避免在開發的過程中出現需求的反復，而且在系統設計和開發階段不需要最終用戶參與。在實施上，一般可以采用場景、業務功能等方式來描述，比較適合于業務流程環節多的系統，或者軟件產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業務系統應該是什么樣，或者采用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般通過某種方式可以使機器識別業務需求，采用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的信息非常多，可能使需求說明的篇幅非常長，不便于理解和閱讀；另外由于通過抽象的方式來推演最終系統的運行方式，對業務人員的要求非常高。

轉載于:https://www.cnblogs.com/LJT666/p/4912549.html

總結

以上是生活随笔為你收集整理的有效用例分析阅读笔记一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。