用例分析法，是來自面向對象的分析方法。用例描述系統的用戶和系統本身之間的交互過程，從而對如何使用系統提供了壹種詳細的陳述，獲得對系統需求的了解。用例分析，是獲取系統功能需求的壹個重要技術。
用例中，用戶術語叫actor。用戶不必是真的人，如果要開發的系統系統對另外壹個計算機系統提供服務，那麽，另壹個系統就是這個系統的用戶。
壹個用例有多個場景組成，壹個用例中，所有的場景有著相同的用戶目標。壹般包括壹個主成功場景和幾個附加的擴展場景，例如在壹個網上超市系統，“購物過程”是壹個用例，這個用例中，***同的用戶目標就是完成購物。但這個目標可能成功完成，也可能因為什麽原因而失敗。這樣，就有成功實現購物的主場景，還有多個購物失敗的場景：如信用卡失敗，貨物售空等等。
用例中的壹個復雜的步驟可能是另壹個用例。這就是用例之間的包含關系。
UML用例圖重點說明兩種關系：
用戶和用例的關系。就是那個用戶啟動了哪個用例。
多個用例之間的關系。比如，壹個用例包含了其他的用例
用例的幾乎全部的價值在於內容。用例圖本身的價值不大。妳在使用用例進行分析的時候，不必過多的致力與用例圖，應該關註與用例的正文內容。這才是這種技術的真正價值所在。
除了簡單的包含關系，UML中還定義了其他的許多關系。但我認為，除了包含關系，以外的其他關系都可以忽略。其他關系除了導致混亂和復雜，幾乎沒有什麽價值。
千萬不要把用例做的太復雜，通常做的過少比做的過多危害要小。如果做的太少，壹個短小易讀的文檔，構成發問的起點。如果做的更多，任何人對它將難以閱讀，難以理解。
用例可以按照等級劃分，分為系統用例和業務用例。系統用例重點說明軟件系統的交互，業務用例討論的是壹種業務如何響應來自客戶的事件。
還有壹種更詳細的分級方法：海級用例，魚級用例和風箏級用例。海級用例描述主參與者和系統之間的壹次完整交互，不是任何其他交互過程中的壹個步驟。包含在海級內的用例是魚級用例。更高級別的風箏級用例，風箏級用例就是上面的業務用例。如果適應更廣泛的業務交互。
數據流分析法
這個方法來自傳統的結構化分析方法。使用數據流圖描述系統的數據處理模型。
註意：數據流圖描繪的是系統的邏輯模型，圖中沒有具體的物理元素，只是描述信息在系統中流動和處理的情況。
數據流圖在分析和設計的前期使用，數據流圖中的處理，是邏輯上存在的壹個過程，開始時不要考慮對應任何具體的軟件實體（不要把處理當成了模塊）。在輸入數據和輸出數據確定的情況下，需要什麽樣的處理，才能由輸入產生輸出？--通過這種思路獲得對系統功能需求的理解。最終究竟由哪個軟件實體來承擔壹個處理，是設計階段的事情。最終，有可能壹個處理最終由多個軟件實體承擔，也由可能，多個處理由壹個軟件實體承擔。甚至可能，某些處理是人工的過程，最終不對應任何的軟件實體---哪部分處理通過用戶手工完成，也是設計的內容。
數據流圖中的數據存儲也不是實際存在的物理實體。
數據流圖的基本要點是描述“做什麽”而不是“如何做”。數據流圖的意義在於分析，而不在於設計。避免數據流圖中的設計的味道。
許多人畫不好數據流圖，是因為在畫數據流圖的過程中。因為他們把數據處理想象成模塊或者對象，把數據存儲看成了具體的數據文件或者數據庫。
另外不要在數據流圖中，表現分支和循環，這樣會造成混亂，畫不出正確的數據流圖。數據流圖中，描繪所有可能的數據流向，而不應該描繪出現某個數據流的條件。--有時候妳可把判斷條件當成是輸入的數據。
面向對象與數據流分析
是否可以在面向對象設計中使用數據流分析法，是壹個有爭議的話題。大部分講面向對象設計方法的書，都反對在面向對象的方法中使用傳統的結構化的方法。我個人認為，可以使用，但要小心使用。有下面的理由：
數據流圖，涉及了系統內部的分析。而用例分析方法不涉及系統的內部。只通過用例分析系統，總是覺得分析的不夠徹底。
有些系統，本身就是壹數據處理為主要任務的，應用的邏輯集中在數據的處理上而不是交互的過程上，不適合使用用例分析法。
數據流圖流傳很久，容易被人看懂，容易在交流中使用。而用例圖使用的人少，許多人對它不熟悉。
在面向對象的設計方法中，使用數據流圖分析後，就要在數據流圖的基礎上抽象對象，數據流圖上的每種元素：數據流，數據存儲;外部實體和數據處理，都可能用來抽象對象。
壹般的意義下，在面向對象的程序中，對象或類構成了系統的邏輯結構。而模塊反應了系統的物理結構。模塊的概念往往和具體的編程語言相關，比如在C++中，模塊對應獨立的編譯單元。壹個編譯單元中，包含壹個或多個緊密相關的類實現。
模塊是壹個很不精確的概念。在實際的交流中，甚至在壹些正式的文檔上，模塊可能代表任何的軟件實體。特別是在結構化設計方法裏面，模塊可以是單獨命名的，可以通過名字來訪問的任何程序對象的集合，過程，函數，子程序，宏都可以作為模塊。對這種不準確的概念，應該怎樣辦，應該從狹隘的概念中解放出來，應該“求其意而忘其形”。
但要註意：在面向對象的設計過程中，使用數據流圖確實是危險的。註意下面的兩點：
在面向對象的設計過程中使用數據流圖，註意不要回到結構化設計的路子上。
數據流圖，最主要的功能是分析，是幫助程序員理解需求，千萬不要在讓數據流圖有了設計的味道。
JACKSON分析方法
JACKSON方法是壹套完成的分析和設計方法。Jackson認為有三種形式的數據結構。、順序、選擇和重復。三種數據結構可以進行任意嵌套，組合。形成復雜的結構體系。JACKSON方法的從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的描述程序結構的JACKSON圖。
我在實際中，我沒有完整的使用過JACKSON方法（實際上，我也沒有系統的學習過這種方法）。我只在分析階段，經常使用JACKSON圖描述復雜的要處理的數據的邏輯結構。我把這種只把JACKSON方法用來做分析的方法，稱為JACKSON方法。
JACKSON方法的主要思路，就是：通過對要處理的復雜數據，繪制JACKSON圖進行分析，了解需求。
另外，除了使用JACKSON圖來完成分析，我還使用過JACKSON圖，來描述過復雜配置文件的文件結構。因為JACKSON圖關註與數據的邏輯結構，而不比關心數據的具體存在形式。用來設計配置文件的格式，挺合適的。
在中國移動數據網管系統中。我就使用了這種圖來設計數據轉換配置文件的數據結構。最終，配置文件使用了XML文件。
根據實際情況選擇分析方法
交互型的系統：系統和外部有復雜的交互過程，適合使用用例分析法。有圖形界面的軟件或者服務端常是這種情況。
對數據處理性的系統，可能存在復雜的數據處理流程，系統要求有復雜的數據處理過程，對這樣的，適合使用數據流的分析。
如果被處理數據，有復雜的結構，就適合使用面向數據結構的分析方法。在同壹個項目中，可能使用到多種分析方法。