Use case diagram (secondary actors)

Question

I have a problem statement that describes an online E-commerce system:

An E-commerce software system is going to be developed. This system allows customers to browse the store catalog, pick the items, and put them in an e-cart. Customer can place an order and enter his shipping details, credit card information. It provides a secure form of credit card payment service. It shall provide to customers a set of shipment methods, which are ground via local shipment agencies, next business day via DHL. The system has an administration backend that allows administrators to add new products, manage inventory and process customer’s refunds if they existed as well. The system should conform to all applicable local and international laws. It should also conform to the company standard STD0945. The requirements at the client side are no more than a web-browser and a reasonable amount of memory on a computing device. This system should have a fast response time and should tolerate common types of faults.

The question is to get the functional and non functional requirements: in the functional of the Customer I have "request a refund" and the functional for the Admin is 'process refunds', I considered the Admin as the secondary actor since he/she responds to initiated use case from the Customer (primary).

I have two question:

1- Can I consider the Admin as a primary actor since he/she has some use cases that he/she can initiate ?

2- Which of the following use case diagrams that describes the system are correct ? (I made 3 of them but I'm uncertain)

A)

B)

C)

I'm conviced that C is the correct one, but I want to hear your thoughts on A and B.

Answer 1

Primary vs. secondary actors are not defined at system level but at use-case level. This means that the same actor Admin can be:

• a secondary actor for a use case "Request a refund", since this request is not the Admin's objective, but he/she is nevertheless involved in this customer objective;
• a primary actor for a use case "Add new products", since this activity is part of Admin's own goals in his/her professional capacity.

The usage of placing secondary actors to the right of the system is only an informal practice. From a formal point of view B and C are equivalent. Up to you to chose the most readable layout when an actor is both primary and secondary in the same diagram. Intuitively I'd opt for B, but it's a matter of taste.

A is anyway wrong, because there's no association allowed between two use cases (i.e. Request vs. process the refund).

Not related but to improve:

• A use-case diagram is not meant to make a functional decomposition of the requirements, and not either to model the user interface. Overall, this diagram seems very detailed, so my advice would be to critically question what is really a use case with value for the user (independently of the others).
• Shipment method is a noun and does not describe a use case. It's either Select shipment method (but then you can have no specialization via DHL or local; at best you could consider extension), or Process shipping instructions (assuming that the choice is already made before, but then it should be Process shipping instructions via DHL and Process shipping instruction via local to clarify that it's really a specialization and not a graphical mistake).
• Pay with credit card could be considered as a sub-goal (even if it's difficult to imagine independently of the enclosing use case). But Place an order to extend it seems confusing. This seems plain functional decomposition. I'd really remove this last one from the diagram.