Identifying Actors for Use Cases

Question

I am working on a little hobby project and am experimenting with doing things a little differently.

The system I am building is an ERP system, and includes a till, product catalogue, sales database, sales log (similar to the database, but used for accounting purposes), a printer, a payment partner and a basket (cart).

Although the printer is hardware, I need to program the higher level code to print receipts.

The only part which I do not need to program is the payment partner.

I have two questions.

1) Would the use case to sell a bunch of products to a customer be one use case named "sell items at till", or would be be broken into several, such as "add product to cart" and "complete sale" (which would write the sales log and print the receipt).

2) Although I am programming the catalogue, sales database, sales log, basket, etc, can I model them as actors in my use cases? Or are the only actors the sales person, and the payment partner?

Answer 1

Use case analysis is deceptively simple, but this question betrays some of the inherent complexity.

Each use case must be meaningful to the actors involved, in the sense that it must represent a well-defined interaction with the system. Each actor and use case must also make sense when you talk about the system, even using everyday language. If you find yourself in difficulty defining either actors or use cases, then probably the system context is unclear and so a domain model might help.

A use case must represent a well-defined interaction, but not necessarily a complete one. The <<include>> relationship can be used in situations where it makes sense to see both full- and partial-interaction use cases at the same level. You might consider having a use case buy stuff include browse products, add product to cart and check out <<xor>> cancel, for instance, each of which makes sense to the customer.

(I am a little bit confused about whether your system is intended for physical or on-line transactions; having a till and printed receipts seems to imply the former, a shopping cart as part of the concepts used in the analysis the latter. The above assumes an on-line system.)

In your case, however, you are talking about actors which may be considered part of the system itself. This usually means that you are trying to define the system and its subsystems at the same time, which is common in situations where you have a good idea of the (eventual) system design before you start the analysis.

What you want to do then is to split the analysis into two levels. At the upper (system) level, be very strict about treating the system as a whole. In your case, you'd probably need the actors customer, payment partner, clerk (for a physical-transaction system), accountant (and maybe administrator), and use cases as listed above plus update product catalogue, audit sales log, etc.

Then you break the system down into subsystems and do a separate analysis for each of them. Here the subsystems can be actors in each others' use cases. Print receipt, for instance, is not a meaningful use case on the system level because it is not in itself an interaction between the system as a whole and a system-level actor, but it is meaningful as a use case for the printer subsystem, with the till as the actor.

You do not need to complete the system-level analysis before you start the subsystem breakdown, in fact I think it's better to have them both active at the same time - although this places higher requirements on you the analyst / designer to be able to switch contexts quickly and be disciplined about which context you're working in at any given time.

So, after all that (phew!) I think the answer to your questions are:

1. Both, provided each use case makes sense to its actors as a well-defined (but not necessarily complete) interaction with the system.
2. Yes, but not at the same level; with one model for the system and separate models for each subsystem you can use the subsystems as actors in each others' use cases.