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:-
- Supplier creates a price list,
- Buyer chooses some items to buy and sends a Purchase Order,
- Supplier receives the purchase order and sends the goods.
- Supplier sends an invoice
- 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?
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.