面向問題域的分析方法

㈠ 面向對象分析方法的步驟和特點

使用MVC進行項目開發已經有一段時間了，在這段時間里感觸最深的就是自己對宏觀性面向對象分析方法的缺乏。面向對象分析是當今流行的系統分析方法之一，下面就談談在做項目的過程中我的一些小經驗。

在面對簡單系統時程序員可以很順利的提出問題的解決方案，並且一般情況下都是可行的。這是由於問題域關系簡單，所涉及到的內部構造、聯系比較容易解釋。而對於當前越來越復雜的系統，其問題域也就顯示的越來越復雜，而且內部的關系也不是很容易解釋，有些大的系統常常超出了人的解決問題的能力。在這種情況下，以往的面對過程的解決方法已經不能滿足日益增長的復雜系統分析的需要，在這種情況下，面向對象的分析方法就顯得尤為總要了。

在面向對象設計領域中，在橫向上把問題域分為數個不同的、低耦合、高內聚的問題域，而在縱向上又繼續分解各個不同的小的問題域，最後分解為葉節點問題域，從而解決問題。在面對對象分析方法中，用數個對象間的消息傳遞來完成整個問題。

下面看一看復雜系統的5個屬性：

1． 雜性經常是以層次的形式表現出來，復雜系統是由相互關聯的子系統組成，而這些子系統又是由他們各自的子系統構成，並由此類推到最底層的基本構件。

2． 對系統中最基本的構件的選擇是任意的，而且在很大程度上取決於系統觀察者的判斷力。

3． 一般而言，各構件內的連接總是要強於構件間的連接。在從構件的低頻動態中分離出高頻動態時，這一屬性是相當有用的。這是因為高頻動態涉及到各部件的內部結構，而低頻動態涉及到構件間的交互。

4． 層次系統通常都是由僅僅少數不同的子系統通過不同的排列組合方式組成。

5． 我們發現正運行的復雜系統總是由以前運行的簡單系統演化而來……任何胡亂湊合設計出來的復雜系統都不可能正常運轉，也不可能被修補好。我們必須由運行中的簡單系統開始。

對於第一點，正像我上面所說的那樣，系統是層次結構的。能夠給一個復雜的系統進行正確的層次分析，才能夠保證對系統的正確估計，包括可行性、可維護性、可擴展性……等等。而且對於日後對該系統進行維護(maintenance)、演化(evolution)、維持(preservation)都能夠很好的支持。

對於其中的第二點，強調了觀察者的判斷力，其實我認為其中也包括觀察者的身份角度。對於一個系統而言，觀察者並不是只進行分析設計的工程師，編碼階段的程序員，還應該包括用戶等所有這些同該系統有關的人員。作為不同的人員，對於系統就有不同的觀察點、觀察角度、身份等特殊因素。因此在不同身份的人（指參與者）甚至同一身份的人眼中說觀察到的系統特性都是不盡相同的。在大學里大家都接觸過透明性的概念，這就是不同觀察者所觀察角度不同的直觀反應。對於用戶來說，基本上底層的操作、演算法、通訊對於他們來說都是透明的，他們根本不用理會（其實也不知道）內部用了什麼。而對於一個負責某模塊的程序員來說就不會考慮其他模塊的實現，對於他們來說其他模塊是透明的，他們只需要負責管理好提供的模塊介面就OK了。

對於第三點，講的就是面對對象分析設計的方向，在面對對象分析設計系統時，被分解的各個模塊一定要做到高內聚、低耦合。有良好高內聚、低耦合系統常常會很容易維護，一個地方改動通常不需要牽扯到大的改動，維護行強。而且對於像VC程序這種更要求效率的程序來說，高內聚、低耦合也可以提高程序的運行期效率，應為對象內部的調用一般情況下會相比模塊間的調用佔用更少的執行時間，這樣將高頻動態封裝在一個對象內部就會一定程度上提高程序運行期執行效率。

第四點則說明了面向對象程序設計對程序設計可復用性的優點。在這點中所「層次系統由僅僅少數不同的子系統構成」那麼多數子系統在不同的復雜系統中都是能夠重復使用的。比如說建築一棟大廈和建築橋梁，雖然兩者都是復雜的系統，但是對於其結構中就會有很多相似甚至相同之處，沒有必要建築好大廈回頭建築橋梁的時候又要重新設計每一快磚瓦。

第五點提醒我們在系統設計時，盡量使用以往能夠正常運行的子系統來重新構件新的系統。這一點不僅說明第四點中的復用性，而且也說明了一個我們常常要犯的錯誤。就是將並沒有通過嚴格測試的子系統，匆忙的加入到大系統中，這樣做不利於對系統的基層，常常引入了其他錯誤，使得系統頻頻崩潰，最嚴重會導致系統的重新分析。

這是我對面向對象的一點心得體會，雖然我們大家在平時工作中所面對的問題、問題域不同，使用的開發工具不同，但是面向對象是一種思維方式，有利於分析、解決問題的一種方法，並不和任何語言掛鉤（當然語言對於面向對象特性的支持程度有所不同）。所以希望各位同事能夠盡量使用科學的方法分析解決問題，形成一種設計模式，以供大家互相交流。

軟體設計是一種藝術，也是一門工程學。

㈡ 需求分析有哪些方法

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

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

㈢ 請問常用的需求分析方法有哪些

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

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

㈣ 軟體需求分析有哪些方法

軟體需求分析免費下載

鏈接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。

㈤ 做需求分析的典型方法及優缺點

摘要 你好，關於你的問題我認為三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問題域的分析方法。

㈥ 論文高手進：軟體開發需求分析的認識和理解

應用軟體開發中的需求分析及方法 軟體工程一般具有以下基本活動：軟體描述：軟體的功能以及軟體操作上的約束定義；軟體設計和實現：軟體要按照描述來設計；軟體有效性驗證：軟體要被確定是有效的，能完成預期的應用；軟體進化：軟體按應用需要的變更來進化。其中，軟體描述的目標是，確定軟體系統需要哪些服務以及開發和運行期間受到哪些約束，對服務和約束的發現、分析、建立文檔、驗證活動，現在常稱為需求工程。為此，筆者談談如何進行需求分析及方法。 一、 需求的過程 需求工程對於軟體過程是一個特別關鍵的階段，這個階段的錯誤將不可避免地帶到後續的系統設計和實現階段中。需求工程階段的獨特之處在於很少有現成模式或特製的文檔可供參考。後續階段可以建立在前期所做工作基礎上（各種相關模型至少在一定程度上可以衍生導出），而需求工程階段的成果卻是靠創建而來的。 需求工程本身就是一個過程，這個過程將產生用以描述系統的需求文檔。通常需求在這個文檔中被分成兩個層次描述：最終用戶需要高層次的需求描述；而系統開發人員需要比較詳細的系統描述。 （一）需求過程的四個主要階段 1、可行性研究：指明現有的軟體、硬體技術能否實現用戶對新系統的要求。從業務角度來決定系統開發是否劃算以及在預算范圍內能否開發出來。可行性研究是初步的，結果就是要得出結論，該系統是否值得進行更細致的分析。 2、需求的導出和分析：這是一個通過對現有系統分析、與潛在用戶討論、進行任務分析等導出系統需求的過程。也可能需要開發一個或多個不同的系統模型和原型。這些都會幫助分析員了解所要描述的系統。 3、需求描述：需求描述就是把在分析活動中收集的信息以文檔的形式確定下來。在這個文檔中有兩類需求。用戶需求是從最終用戶對系統需求的抽象描述；系統需求是對系統要提供的功能的詳盡描述。 4、需求有效性驗證：這個活動檢查需求實現、一致和完備。在這個過程中，可發現需求文檔中的錯誤，並加以修正。 當然，需求過程中的各項活動並不是嚴格按順序進行的。在定義和描述期間，需求分析繼續進行，這樣在整個需求工程過程中不斷有新的需求出現。因此，分析、定義和描述是交替進行的。 （二）需求的進一步認識 1、軟體系統需求 常常分為功能需求、非功能需求和領域需求。 功能需求：包括對系統應該提供的服務、如何對輸入做出反應以及系統在特定條件下的行為的描述。在某些情況下，功能需求可能還需要明確申明系統不應該做什麼。理論上，系統的功能需求描述應該既全面又具有一致性。全面意味著用戶所需的所有服務都應該給出描述。一致性意味著需求描述不能前後矛盾。在實際過程中，對大型而又復雜的系統而言，要做到需求描述既全面又一致幾乎是不可能的。一方面是因為系統固有的復雜性，另一方面是因為觀點不同，需求也會發生矛盾。 非功能需求：對系統提供的服務或功能給出的約束。包括時間約束、開發過程約束、標准等。非功能需求源於用戶的限制，包括預算上的約束、機構政策、與其他軟硬體系統間的相互操作，還包括如安全規章、隱私權利保護等外部因素。 領域需求：這是來自系統的應用程序領域的需求，反映了該領域的特點。他們也可能是功能需求或非功能需求。 2、軟體需求文檔 也稱軟體需求描述（SRS），是對系統開發者要求的正式陳述。IEEE標准為需求文檔提出了以下結構：引言（目的、范圍、縮略詞等），一般描述（產品透視、功能、用戶特徵、約束等），專門需求（功能、非功能、介面），附錄，索引。 二、方法 （一）問題域（應用領域） 是指問題所存在的現實世界中的那個部分。問題域是需求分析員所要研究的首要對象。例如，對一個電梯控制系統來說，它將包含任何現存的硬體（電梯、指示器、感測器、按鈕等）、建築物特徵（樓層和電梯井的數目）、預期的使用模式、用戶特徵、使用約束（如限制短途搭乘）等等。在這個問題域內，問題可以確定為「讓電梯在建築物中更有效使用的控制系統」。為了解決問題，『解系統』顯然有必要在問題域內產生某些效果，構成軟體需求的正是這些想要獲得的效果，也就是為何做軟體需求的原因和目的。 到現在為止，我們得到初步論點。在構建一個新軟體系統之前，最好先決定它應當能夠做些什麼又不要做些什麼；從問題域的研究入手，獲得問題的描述，以及新的解系統在其中將產生效果的陳述（即需求）；確定新系統所需的行為，以便讓它在問題域內產生所需要的效果。 （二）需求分析 通過對問題域的研究，獲得對該領域特性及存在於其中（需要解決）的問題特性的透徹理解並用文檔說明。需求分析旨在揭示一個現有的系統（問題域）的結構，而內部設計則是要創建出一個尚未存在的軟體系統（解系統）的結構。對於這一重要任務其特性如下： 分析關注問題域及對其建立的模型，而不是解系統； 主要目標是要獲得對問題域及存在於其中的問題本質的理解； 分析在本質上先於解系統行為的規格說明（盡管有重疊和反復的過程）。 （三）方法論 方法不只是一種技術，它是解決任務的一種途徑，並且通常由一組技術組成。任何分析方法，要使它得到很好的利用，都應當要求並且做到便於描述以下幾個方面： 問題域的結構，根據其子域及其相互間的關系； 問題域數據，語法和語義方面 問題子域的內在屬性和行為； 問題域中的重要事件及現象； 需求，解系統在問題域中應產生的效果。 具體有以下三個方法： 1、結構化分析（SA） 結構化分析（SA）是一種具有相當長歷史的分析方法，其演化的方式既微妙又顯得很重要。如同結構化編程一樣，它致力於系統范圍內的事物處理，數據流以及存儲數據結構的建模。建模主要包括數據流模型（DFD），數據字典（DD），實體關系圖（ERD）。 結構化分析所用的原型，無論是對開發者還是客戶都顯得直觀易懂，若將初始重點放在對原有系統的建模是對實現理解問題域這一基本的分析目標的有力支持。 結構化分析方法和人們的思維方式很相似，注重的是事物的過程和方面。利用結構化分析很容易去理解一個剛剛接觸的問題域，適合對比較生疏領域做軟體需求。 2、 面向對象分析（OOA） 面向對象方法最初只是一種系統的結構進行建模的方式，後來擴展到了內部設計，如今也已經開始廣泛應用於分析階段。面向對象分析基本思想是：如果把對象類的建模限定在需求問題域，那麼面向對象的基本原理、模型以及表示法均可以用於分析。 OOA（面向對象分析）算不上一種真正的需求方法，OOA的起點是一份原有的需求文檔，或者甚至是一份行為規格說明，並且OOA隱含的假設問題域分析已經完成，即分析員已經了解了所要研究的事物。OOA的真正本質意義是作為解系統的高層體系結構的設計，並且有利於系統的下一步開發設計（如果是OOD開發的話）。 OOA的大致方法是：標識出問題域中的對象類；定義這些類的屬性和方法；定義這些類的行為；對這些類間的關系建模。 3、 面向問題域分析（PDOA） 面向問題域的分析（PDOA）是一種新技術。PDOA更多的強調描述，而較少的強調建模。描述大致劃分為兩個部分：一部分關注於問題域，而另一部分關注於解系統的待求行為。一般建議同時有兩個單獨文檔：第一文檔含有對問題域相關部分的描述以及一個需求在該域中求解的問題列表（即需求）；第二文檔（規格說明書）包含的是對解系統的待求行為的描述以解決需求。其中第一文檔才是通過做分析產生的；第二文檔推遲到後續的規格說明任務中。 PDOA整個方法過程的基本步驟： 搜集基本的信息並開發問題框架（一種模型），以建立問題域的類型 在問題框架類型的指導下，進一步搜集詳細信息並給出一個問題域相關的特性描述 基於以上兩點，收集並用文檔說明新系統的需求問題框架。問題框架是將問題域建模成一系列互相關聯的子域。一個子域可以是那些可能算是精選出來的問題域的任一部分。問題框架的目標就是大量地捕獲更多有關問題域的信息。基於不同問題子域的本質及存在於問題子域間的關系，可以把問題框架分類為： 工件系統——系統必須完成針對只存在於系統中的這些對象的直接操作。 控制系統——系統控制部分問題域的行為，包括待求行為框架和受控行為框架。 信息系統——系統將提供有關的問題域的信息，包括信息是自動提供的和信息只在響應具體的請求時提供。 轉換系統——系統必須將某種特定格式的輸入數據轉換成相應的、另一種特定格式的輸出。 連接系統——系統必須維持那些相互沒有直接連接的子域間的通信。 問題框架法在應用時，建議採用直截了當的策略： 抽象問題域：標識子域；標識子域間的交互；刻畫每個子域的特徵；生成一個上下文圖識別出相關的標准框架；調整框架，盡可能使之適用於問題；使用關於相關框架的內容技術表來指導進一步的分析與文檔編制任務。 問題域的描述與必須滿足的需求二者之間有著明顯的區別，對新的解系統的行為創建與定義應單獨處理並且推遲到下一步的規格說明階段。 4、方法的對比 結構化分析（SA）及其相應的派生方法，曾一度風行了許多年。它最初的版本主要是圍繞對數據流以及問題域的數據結構進行建模，而現代的SA則直接將重點放在開發解系統的模型。描述問題域的SA可以算是想當不錯的，所產生的功效可見一斑。然而，它對其他方面的支持卻不夠完善，在處理一些其他類型問題時顯得有些笨拙。 面向對象分析（OOA）是當今主流的方法。OOA要求所有的系統均可以按照對象的特點來建模。它也繼承了很多結構化分析的思想體系。OOA不能對問題域有個清楚的了解，因而它的起點若是有一份原需求文檔，便可大大簡化問題域的分析。OOA並不區分問題域描述與解系統描述之間的差異，而是直接交付出新的解系統的高層設計。 SA和OOA還有幾點相同特性：主要模型是結構模型；通常焦點集中在對解系統的建模上；兩中方法都較少地應用於需求獲取領域；分析與內部設計之間沒有明顯差異。 面向問題域分析（PDOA）被認為是一種較為理想的方法。PDOA特點是重新將重點定位在問題域及需求上，通過對問題域的分類，向分析人員提供具體問題的相關指南。並且它將規格說明作為另行的任務處理，它的成果只是一份問題域的全面描述和一份需求列表而已。PDOA豐富和完善了現今的「分析」方法，然而人們對它的了解和掌握還有一定距離。 因地制宜的應用三種方法，不僅能夠如實的認識問題域，創建出健全的解系統，還能夠向用戶和設計人員都提供滿意的需求文檔。 三、 總結 在做軟體需求的時候，我們完全沒必要去限定要用或將要使用何種方法。我們的目的在於分析軟體的需求，通常情況是都用到了所介紹的三種方法。首先我們用面向問題域的方法把問題分成幾個部分。接下來用面向結構或面向對象的方法對各個部分進行逐步分析細化。在逐步分析過程運用各種建模技術對問題各部分建立合適的模型來細化需求。隨著需求的進一步進行，我們越來越清晰的認識了軟體系統的需求。 雖然應用方法使我們能夠清楚地去了解軟體需求，但是，大部分的需求文檔和規格說明書都是以文本的形式記錄的，因此，如何去表達我們所了解的需求也是很值得注意的。

㈦ 需求分析有哪兩種主要分析方法

從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。