Scenario: (sort of Call center) (1) Customer Requests technician. (2) Request goes into queue for technicians to see. (2b) Customer gets confirmation email about submitting data (3) Technicians Process request (3b) everyone gets email (4) Request is completed (5) Technician submits data for completed request (6) Closed Request.
So two actors on the left. Not everything has to connect right? So for customer getting emails and submitting data is drawn. For Technician actor they have processing interaction and submitting data and getting email.
I am reading about UML here: http://www.soberit.hut.fi/T-76.115/01-02/palautukset/groups/Fireball/t2/docs/UseCaseMethod.html
Was wondering if there should be an actor on the right side of the diagram representing the database? Am I missing anything? How do you know you are completed with a use-case diagram?
Actors are not included in the system, they are extern to the system. Usually, the DB is in the system and it is not an actor.
For example, in your case, a secondary actor could be google map if the technician has to know how to go the customer and, for that he has to see a map whith the travel. In this case, during a use case, google map is reached to get the map.
The only way I know to be sure that UCs are completed is to review them and/or to get a list of customers needs and to trace customers needs with UCs.
Hope this help.
More : The remark of @Kilian about function is a real good one. Usually when we start we thought use case as "workflow to achieve a feature" or as the set of all user interface menus and this is not that.
So @Waren, I could suggest:
First try to define the system with a title and a paragph deifning the main mission of the system. System is not only the code you are going to write but all what will deployed for it (machine, virtual machine, db, bays, swicht, procedures, DDL, configuration files and so on)
Then define the needs, high level needs that the system must fulfilled (iso term is shall see enter link description here )
Then define the actors/stackeholder and the inheritance hierarchy to figure the needed roles and rights. Do not forget all operational needs (monitoring, backup/restore, DRS procedure, reports, deployment and so on)
Then define your use cases thinking features or single added values and check the whole coherency. A good point about UC is to describe "error/exception" scenarios.
Then an interesting point could be to define the mode of system : installation, tests before production live, production, update/patch, maintenance, system stop and removing. Like that you will be sure to cover the whole system lifecycle.