結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業務框架確定系統的功能範圍，以及每個功能的處理邏輯和業務規則，功能需求規格書等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以採用圖表、示例圖、文字等等方式來描述系統。在系統開發以前，一般還可以採用更為直觀的原型系統方式和終端使用者進行交流和確認，因此對業務需求的要求會低一些，業務需求階段的週期相對容易控制；透過業務全景圖，終端使用者也能瞭解系統的功能；透過功能活動圖和業務規則的描述，也可以相對精確地描述業務系統；因為沒有嚴格的標記語言，可以採用適當的篇幅描述適當的系統。當然，這種方法的缺點也是明顯的，分析人員和業務人員之間可能缺乏共同語言，機器不能識別業務需求書，在設計階段還需要繼續和使用者確認一部分功能。 　　面向物件的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個系統，採用程式語言的方式和終端使用者交流（終端使用者必須要熟悉這種語言），能夠在專案一開始就發現很多問題，避免在開發的過程中出現需求的反覆，而且在系統設計和開發階段不需要終端使用者參與。在實施上，一般可以採用場景、業務功能等方式來描述，比較適合於業務流程環節多的系統，或者軟體產品的開發。但是，我們也要看到，在現實中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，使用者要非常清楚地知道最終的業務系統應該是什麼樣，或者採用一種抽象的方式能夠確定最終的應用系統；其次，因為終端使用者不需要參與設計和開發階段的工作，所以雙方確定業務需求的過程也會比較長；同時，因為是精確描述，因此描述系統的語言是非常邏輯化的，一般透過某種方式可以使機器識別業務需求，採用這種方式寫的業務需求是非常格式化的，一方面描述一個系統需要的資訊非常多，可能使需求說明的篇幅非常長，不便於理解和閱讀；另外由於透過抽象的方式來推演最終系統的執行方式，對業務人員的要求非常高。