前提
本文中所講的系統分析經驗是以瀑布模型為前提，並以需求分析->系統架構->系統設計->編碼實現->測試->驗收部署->維護->終止維護的軟件開發流程為基礎的。
系統功能結構圖
抽象與分解是結構化分析與設計中的核心，通過抽象，我們可以將擁有復雜功能的軟件項目抽象成兩個字：系統。然后再將系統逐層分解成子系統、子系統的功能模塊、功能模塊中的業務數據和業務方法，最終使得系統達到可以實現的程度。
雖然這種方法直觀易懂且實用，但是我要說明的是，如果你采用面向對象的思想來進行系統的開發，那么使用系統功能結構圖進行需求分析，我是不推薦的。發揮這種分析技術最優性能的思想是面向過程的思想，因為如果使用的是面向過程的思想，則系統功能結構一旦定下來，就意味着開發人員可以工作了。
還有一個問題是，使用這種方式，只能夠得出系統擁有哪些功能以及系統的層次結構，但是卻不能夠得出誰需要哪些功能，這樣就會導致分析人員分析出的一些功能，其實上用戶並不需要，或者分析得並不准確。
例如，假設存在一個僅僅面向學生使用的教務系統，學生可能會使用它來查詢自己的成績、查看課程表、選課、選專業方向、瀏覽消息公告等。對於這樣一個系統，你很難想象，系統分析師會分析出注冊這么個功能來。如果讀到這里，你還覺得沒問題的話，可能是因為這種分析思想實在是太自然了吧，因為站在系統的角度，系統存在着用戶，那么系統存在用戶注冊的功能是很正常的啊!但是，請嘗試這樣來考慮：
如果學生能夠自己注冊的話，那么一個學生可能會注冊多個用戶，又或者會有學生沒有注冊的情況，當然系統可以進行控制，不過作為學校來講，學校有哪些學生都是固定了的，既然這樣，完全可以讓學校來進行統一的創建和發放用戶賬號，並確保數據的正確和完整。
用例圖
緊接着上面討論的教務系統，如果使用用例圖來進行需求分析，就會變成這樣：
從圖2中可以明確得出系統有哪些參與者，以及每個參與者所能夠使用的功能。或許看到這里，你可能會覺得只是功能的名字改變了而已，功能的數量還是不變嘛。
其實，按照圖1的分析，系統最終會得出：用戶注冊和用戶登陸這兩個功能，然后一般系統管理員都會有對用戶的CRUD操作，那么系統的功能就有6個。但是如果按照圖2來進行分析，系統管理員的CRUD加上用戶登陸，功能就只有5個，這時就會發現，系統除去了一個多余和重復的功能。（對於本系統而言）
應用時機
我覺得，兩種方式都可以用在系統分析階段，唯一不同的是，使用用例圖來進行需求分析，當需求分析完畢后，使用系統功能結構圖進行整理，這樣可以方便系統架構師或系統設計師大致了解到系統有哪些功能以及系統功能的層次結構。
總結
一句話：最重要的是應用思想的時機。