Hi GVerkerk,
Disagree with some of your comments enough to reply:
You Said: "For instance, if you have a use case with check out, but not a use case with check in, then that fairly odd. It means that you never identify your users. And how can you check out if your aren't checked in?"
In a standard online purchase process, you browse, make selections (add to cart) and check out when you're ready to buy. No Check in required
You said: "The use case select product is not an include of use case place order. It's the other way around. You cannot place an order without selecting a product."
Think you're wrong here. The use case place order is doing something of value to the client and is a standalone function. During the action of placing an order, the client will select one or more products. So Select Product is included in Place Order.
You said: "you cannot have a use case manage user accounts without a use case create user accounts. You cannot have a use case update products without a use case insert products."
To me Manage User Accounts and Update Products are standard CRUD use cases. Some people split these into separate Create, Read, Update, Delete use cases but I don't for a number of reasons - they usually share a set of business rules and having them in 4 places makes them hard to maintain; always the same initiating actor (if not, they should be separate); separating them out artificially distorts the number of use cases and inflates the expectation of work required; I'm lazy cause there is a lot of extra typing and repetition.
I can see other problems with the diagram (e.g. trying to show process in a use case diagram) but it looks like at least the functionality required is all there. So its not a bad start.
Kimbo