Junilu and Panagiotis,
I think I got this wrong.If you read that section further, Martin suggests the following :
[..] Think about all the events from the outside world to which you want to react.A given event may cause a system reaction that does not involve users[..]
Also, in the same Chapter he defines System use cases as an interaction with the software.
I believe,Martin is emphasizing on identifying those hidden use cases, which does not surface out by looking at actors interacting with the system.He wants us to investigate further and find out
value-added actors in the context of a larger system.
For example, in a Credit Card system, an actor (Customer) may interact with the system to make Payments.So "Making Payments" could be one use case.But to break this huge credit card system further, you may have to find out a "hidden need" - say, decision to allot a Credit card to the Customer.So we may have a System Actor (Credit Decision Management) which will interact with a use case, say "Make a Decision".Identification of such a use case would reveal a need to model one more sub-system within the context of a larger system - An example of breaking a large component into smaller components.
Would like to know your views on this.
Thanks in advance,
Sandeep
[This message has been edited by Desai Sandeep (edited May 23, 2001).]