BPM & Use Cases, Who's Counting? Revisited

Whenever I have questions about use cases myself, I grab my use case bible which is Writing Effective Use Cases from Alistair Cockburn. One of the sections in that book is named Your Use Case Is Not My Use Case, which discusses that different people writing use cases for different purposes or audiences, may write use cases differently. This posting I also could have named My Use Case Is Not My Use Case, at least not at Different Points in Time, as you will soon find out.

In one of my earlier postings called BPM & Use Cases, Who's Counting? I discuss an example and suggest that some automatic notification activity is part of the preceding interactive activity. Then in a total different context I noticed myself arguing to a colleague that a notification in her use case model was a use case of its own. It then realized that in general this is a better approach.

The following example will show why:


Assuming that the Customer is not a direct user of your system, for the Notify Customer activity you could argue that it would be part of the goal of the Account Manager to notify the customer. But for the Notify Warehouse I find it way more intuitive to claim that it is a goal of the Shipping Clerk to be notified that there is work to do. But that would imply that the first notification would be part of the Review Order use case, while the second notification would be a use case of it's own. Does that sound inconsistent or what?

So I therefore want to change my opinion and suggest that in principle you should consider a notification activity to be a use case of its own, having the one being notified as primary actor (i.e. having the goal). Make sense, not?