Hi Shure2,

As a use case diagram it is fine. 

The issue you will run in to is when you try to document each use case on the diagram. It is likely that the specification of requirements in whatever format you choose to document them against the use case will define a different set of requirements for "Add Details" in "Manage Customers" compared to "Add Details" in "Manage Products". 

In the case of adding details to Customers compared to adding details to Products, there will be different rules to apply in a different sequence. The specification for each of the 3 reused use cases (Add, Edit and Delete Details) will be different compared to which use case (manage Customers or Products or Leads or Companies) invokes them. 

Contrast that statement with the re-use of the Log In use case. Assuming that the Log In use case logs the user in the solution, this will be the same regardless of the use case that invokes it.

Given the above, the conclusion is that that "Add Details", "Edit Details" and "Delete Details" are not good candidates as re-useable components to be invoked by Manage Customers and Manage Companies and Manage Leads and Manage Products.

It might also be the case that the complexities of who can do what, when and with what data might require the definition of process sequence rules which are (arguably) more easily modelled on a process model (e.g. using BPMN). 

Hope that is useful.

guy

  I would say "What value does this diagram produce?"