許多採用使用案例建模方法進行需求分析的開發者，對於不需要使用者介入的系統自動作業，通常會用工作排程者來當成使用案例的主要參與者。讓系統工作排程來啟動使用案例以與系統互動，這對系統開發者而言，可以讓他們了解系統應該如何與外界互動以完成系統所提供的功能，這樣看起來是可行的需求塑模手法。
不過，工作排程者牽涉到系統設計的觀點，如果我們不想讓需求相依於系統設計，那麼我們就必須將工作排程者變成更共通而抽象化的概念。工作排程者的抽象化概念是什麼呢？我們不難理解，工作排程者也只不過是實現時間概念的具體設計。因此，照理時間才是系統自動作業的主要參與者。
然而，當我們把時間當成系統自動作業的主要參與者時，我們會遭遇到另一個問題。那就是基於黑箱的角度來看系統，使用案例應該是以使用者或外部系統來看系統，瞭解如何系統與互動而達到特定目的或產生價值。很顯然地，系統自動作業並沒有辦法為「時間」達到任何的目的或創造價值。
換句話說，我們並未找到系統自動作業的真正使用者，即使我們把工作排程者當成使用者，以使用系統的組織觀點來看，我們將會無法了解系統自動作業和組織目標的達成有何關係，而遺漏了相當重要的使用案例觀點（use case view）。
同人常觀察到許多專注技術的開發者並不重視使用案例觀點，而是在意使用案例如何直接轉換成實際的設計與程式碼。當然，在專案時程及資源的限制之下，強調軟體設計的實用性以及開發的效率而言，這樣做似乎是無可厚非的。然而，開發者卻往往會忽略使用案例觀點的遺漏是無法用設計觀點（design view）來彌補的。因為開發者的設計能力再強，也很難能夠在命題錯誤的情形下，發展出正確的解答。
因此，我們應該從組織的觀點來看待系統自動作業的主要參與者，而非技術與設計觀點。一般而言，在企業價值鏈中，系統自動作業是用來增進系統的可用性與效率，因此它的使用者其實是系統管理者。他的責任是管理系統組態，例如多久檢查一下資料的狀態來決定該執行接續的作業。如果沒有工作排程者的設計，那麼他必須隔一段時間就檢查資料；有了系統自動作業雖然可以減輕工作負擔，但他仍須維護組態設定，以確保系統運作之正常。
有些開發者會以訊息系統來當成系統自動作業的主要參與者，記得克明兄常用「送信小弟」來隱喻訊息系統這個參與者。不過，從我最近的需求分析的經驗來看，用訊息系統來當成系統自動作業的主要參與者有時候不見得合適。
如果組織並沒有賦予訊息系統明確的角色定位時，它多半會變成某些系統內部的傳訊元件，並不適合拿來當成使用案例的主要參與者；而有明確定位組織角色的訊息系統通常是通訊管理的基礎建設，這時可以把它看做是系統管理者的角色。但系統管理的機制會視對系統要求的性能不同而有所變化，不一定就是訊息系統，所以把訊息系統當成主要參與者，常會使得需求模型顯得缺乏抽象性。
這也讓我們發現到，兼顧使用案例與設計觀點才能讓我們在軟體分析的過程，確實地遵循抽象化的系統分析原則呀。
