Advice on splitting up a process involving multiple actors into Use Cases

Question

Let's say I am modelling a process that involves a conversation or exchnage between two actors. For this example, I'll use something easily understandable:-

1. Supplier creates a price list,
2. Buyer chooses some items to buy and sends a Purchase Order,
3. Supplier receives the purchase order and sends the goods.
4. Supplier sends an invoice
5. Buyer receives the invoice and makes a payment

Of course each of those steps in itself could be quick complicated. How would you split this up into use cases in your requirements document?

If this process was treated as a single use-case it could fill a book.

Alternatively, making a use case out of each of the above steps would hide some of the essential interaction and flow that should be captured. Would it make sense to have a use case that starts at "Received a purchase order" and finishes at "Send an Invoice" and then another that starts at "Receive an Invoice" and ends at "Makes a Payment"?

Any advice?

Answer 1

Yes, there are many possibilities here. In your example above it could be even more complicated by the Buyer making multiple partial payments to pay the bill.

You probably need to create complete workflow use cases. Splitting each of the above steps into their own use cases may not prove useful as some of the steps will have pre & post conditions.

I work on the QuickBooks source code and the number of ways that a transaction can flow through the system is daunting. It is almost impossible for our QA guys to test every combination.

Answer 2

The way I usually approach such tasks is by just starting to create UML Use Case and high-level Activity diagrams for the process. Don't bother about specifics, just give it your best shot.

When you will have a draft you would almost immediately see from it how it could be improved. You could then go on refactoring it - getting the use case smaller, structuring large Activities and so on. Alternatively you could lump a couple of Use Cases together if they are too small.

Without knowing the details of your project I would just go ahead and make each step a separate Use Case - they all seem to be self-contained and could be described without any cross-references. If while doing so you will find any dependencies you could always rethink the approach.

Also consider use 'extend' and 'include' blocks for common elements like logging, security etc.