Are Use Cases Good for System-to-System Interactions?
Let’s first consider the structure of the relationship between the system that is the primary actor, and the system providing services to that actor. This latter system we will call the SUD, the System Under Discussion.
First, it is imperative to view the relationship as a requestor/provider relationship, not a data source/data sink metaphor. The primary actor requests a service from the SUD; the SUD provides the service and a response of some kind. The following UML Sequence Diagram (SQD) illustrates this relationship:
Second, if there is only a single request, and a single response, involved in the interaction between the primary actor and the SUD, then you have a situation wholly analogous to a subroutine call. The SQD above shows the structure of this situation, and you can readily appreciate that there is no interaction of any complexity going on ― only a “touch and go”. No matter how much work the SUD is doing internally to satisfy the actor’s request, it is still a single request and single response. Representing this situation as a use case is not terribly enlightening. Your entire use case for the “happy path” would be something like:
1. Actor requests service from SUD
2. SUD provides response to actor.
Many use cases that I see for Logon, Logoff, and Print Report have this structure, and provide little to no business value to the project. The use case presentation template is usually an order of magnitude larger than this use case.
However, it is sometimes the case that use cases with this limited structure may have interesting exception-handling behavior, and capturing this behavior might justify using a use case format for these services. But in the absence of such exception behavior, I do not write use cases for these services: I write a simple user story instead.
If the interaction between the actor and the SUD does have complexity, i.e., multiple sets of requests and responses, then you have the structure of a use case. Few of us have difficulty envisioning a human user interacting many times with a software system to achieve a goal that provides value to that user. Here is the structure of such a complex interaction:
With just a little thought we can recognize this as a sequence of interactions, or transactions. This is the conceptual key to representing system-to-system interaction as a use case. In the SQD below I have marked the sequential interactions as transaction groups:
Each grouping is a request and response, and all of the groupings together constitute a process composed of sequential, or nested, transactions. Any response from the SUD to the actor system may invoke decision-code in the actor system, resulting in one of several subsequent requests in the next group. Similarly, any request from the actor system may result in one of many possible responses from the SUD ― just as if it were a human actor using a software application.
So, if you have two or more software systems interacting in a way that consists of sequential transactions, you can readily use the use case form to describe that interaction.