通過閱讀有效用力分析書籍，學習到了許多寶貴的經(jīng)驗，現(xiàn)總結如下：

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

三種需求分析的方法：結構化分析方法、面向?qū)ο蟮姆治龇椒ā⒚嫦騿栴}域的分析方法。
　　結構化的分析方法是傳統(tǒng)的分析法，它的好處是在需求階段可以不需要精確地定義系統(tǒng)，只需要根據(jù)業(yè)務框架確定系統(tǒng)的功能范圍，以及每個功能的處理邏輯和業(yè)務規(guī)則，功能需求規(guī)格書等。因為不需要精確描述，因此描述系統(tǒng)的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來描述系統(tǒng)。在系統(tǒng)開發(fā)以前，一般還可以采用更為直觀的原型系統(tǒng)方式和最終用戶進行交流和確認，因此對業(yè)務需求的要求會低一些，業(yè)務需求階段的周期相對容易控制；通過業(yè)務全景圖，最終用戶也能了解系統(tǒng)的功能；通過功能活動圖和業(yè)務規(guī)則的描述，也可以相對精確地描述業(yè)務系統(tǒng)；因為沒有嚴格的標記語言，可以采用適當?shù)钠枋鲞m當?shù)南到y(tǒng)。當然，這種方法的缺點也是明顯的，分析人員和業(yè)務人員之間可能缺乏共同語言，機器不能識別業(yè)務需求書，在設計階段還需要繼續(xù)和用戶確認一部分功能。

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

轉(zhuǎn)載于:https://www.cnblogs.com/LJT666/p/4912549.html

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。