How to convert a use case to a use case diagram?

Question

Suppose I have a use case, like this example.

Normal Flow:
The user will indicate that she wants to order the items that have already 
been selected.
The system will present the billing and shipping information that the user 
previously stored.
The user will confirm that the existing billing and shipping information 
should be used for this order.
The system will present the amount that the order will cost, including 
applicable taxes and shipping charges.
The user will confirm that the order information is accurate.
The system will provide the user with a tracking ID for the order.
The system will submit the order to the fulfillment system for evaluation.
The fulfillment system will provide the system with an estimated delivery 
date.
The system will present the estimated delivery date to the user.
The user will indicate that the order should be placed.
The system will request that the billing system should charge the user for 
the order.
The billing system will confirm that the charge has been placed for the 
order.
The system will submit the order to the fulfillment system for processing.
The fulfillment system will confirm that the order is being processed.
The system will indicate to the user that the user has been charged for the 
order.
The system will indicate to the user that the order has been placed.
The user will exit the system.    

I would be grateful if you could let me know of a procedure or guideline that helps in converting this to use case diagram, more specifically the use case bubbles.

Going back to the example, I think I would have one use case bubble named place order, and I probably have another bubble named payment, and there is am "include" relation from payment to place order. But I hope there is something more formal than intuition to help me come up with a more accurate diagram. Thanks!!

Answer 1

You only have one use case there, so only one blob. Add actors for everything that's mentioned there that isn't "the system" ("the user", "the billing system" and so on). Then join them up with lines. Job done.

She only reasons why you'd need multiple blobs i:

• If you break out parts of a use case into sub-use cases, where there is common functionality, or
• If you want to put multiple use cases on the same diagram.

Answer 2

In principle, a use-case diagram, should show use-cases that correspond in to some goals of value to the actors:

A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.
- Ivar Jacobson

Each use-case in the diagram would further be documented, among other with a narrative or a table that describes the normal flow of event:

• Essential (also called abstract) use-cases try to avoid a step by step narrative and focus on goals to aim at a bigger freedom for designing the solution.
• Classical use case narrative express either in one or two columns the sequence of interactions between the user and the system.
• Modern use-cases, i.e. use-case 2.0 no longer give a full picture of the use-case, but slice the use-case in smaller parts, each parts being describe by user stories.

Your narrative starts with "Normal flow" and then describes the sequence of interactions beteween the user and the system. So it's the narrative of a single classical use-case.

You could further decompose this use-case, if you would find some sub-goals that could make sense to the user independently of the other parts. But here there are only closely related actions that make only sense in the sequence. So there are no other use-case in there. I just see some secondary actors that are independent systems: Fulfillment system , and Billing system, but not use-cases.

Some people (and unfortunately some teachers) try to promote functional decomposition (e.g. taking order, scheduling shipment, etc...). You shall not do this: use-cases are not functions. Functional decomposition is a no-go for use-cases.