In my case; my system (A) is publishing a web service which another system (B) invokes to make payment. There is a series of interactions between A and B where A fullfill demands/needs of B by providing required services.
My question here: Whether system B can be shown as ACTOR in Use Case ?
Matthew Brown wrote:I'd say: sure, no problem. Actors can be anything external to your system that initiates an interaction. If you're trying to model system A, that sounds like what you're describing.
I agree and I've done exactly that in the past. However, I'd also point out that you might want document some use cases of the complete system (yours plus the other system). That way you can verify that the combined system really will be satisfying some end-user requirements. This practice is more useful when you're developing the "other" system or at least have the ability to influence the design of it. The practice of developing use cases for the combined system is relatively less useful when the other system is already set in stone.
Ryan McGuire wrote:However, I'd also point out that you might want document some use cases of the complete system (yours plus the other system).
Very true - I almost mentioned that, then decided to keep things simple. Be clear about the scope of the system you're analyising (System A, System B, System A + B), and your actors should be external to that.
Joined: Sep 02, 2001
In my case; System B is completely a separate System. Actually, we own System A which provides payment services by publishing required Web Services. Whereas other systems (B1,B2,Bn) integrates with System A in order to make payments.
After above replies, I am concluding that System B can be shown as (Primary) Actor as it will be the one who will be initiating interaction (s) with System A.