Your notation looks correct, but as Neil and Chris point out, there is very little to judge beyond that. This is a good start in helping you organize your thoughts, understanding the large-grained use cases and involved actors. Now, you need to proceed to break down the large-grained use cases into more-focused, finer-grained steps. Textual use cases are good for this. You might check out Writing Effective Use Cases by Alastair Cockburn for more information.
Once you have your steps reasonable defined, you can then flow into Activity Diagrams to more clearly show the logical flow, then on to Sequence Diagrams where you will really begin to flesh out the details of interaction. Note that this is not a strict linear process. Things you discover as your create each artifact likely will require you to revisit previous diagrams. As you proceed, however, your Use Cases, Class Diagrams, and other artifacts will evolve into a better representation of your target system.
Read Alistair Cockburn's Effective Use Cases book (see it on Amazon: 1). He does an excellent job of explaining practical use of use cases in a structured and effective way.
This is the book on use-cases:
http://www.amazon.com/Writing-Effective-Cases-Software-Development/dp/0201702258/ref=sr_1_3?ie=UTF8&s=books&qid=1244456081&sr=8-3.
The drawing part og usecases is not important, it's the textual part thta matters...
In my opinion, use cases are one possible way to get a clear understanding of your requirements. So, as ChrisBD already stated, there won't be a diagram out there that suites your needs and, most importantly, even if it were, this is not desirable.
It's important to know that the valuable part of creating use cases is not the creation of a UML diagram(altough they are helpful for getting an overview of a system). The much more valuable process is writing the textual description of a use case.
There are various templates which guide you through the process (e.g., by Alistair Cockburn [1] or others [2,3] ). If you are interested in the subject, I can recommed the book "Writing Effective Use Cases"[4] by Cockburn.
[1] http://alistair.cockburn.us/Basic+use+case+template (great resources for use case in general)
[2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.255 (easy for starters)
[3] http://hcid.soi.city.ac.uk/research/Rescue.html (uc embedded in requirements engineering)
This is a somewhat deep question, so I am hesitant to give a short answer. It is a good idea to read a few good books that describe different approaches, such as The Inmates Are Running the Asylum, which describes scenario-based function design. Another approach is to use high-level use-cases, as described in Writing Effective Use Cases.
Some guidelines:
Write what is required without constraining how this will be done.
Make each requirement a separate numbered list entry for cross-reference.
Split requirements into separate items until each one is 'atomic'.
Include a Security section, and be explicit about what security is required.
Include a Non-functional requirements section, for constraints like performance and availability.
Include a Non-requirements section to list things that are not requirements, so you can tell the difference between something you forgot, and something you do not need.
Specify external interfaces (to other systems) as well as user-interface requirements.
When you are introducing someone new to your programming environment they need to understand the business problems as opposed to the technical. For the feature set under consideration, you need to identify the expected success paths and minimize the failure space before handing off to them. By this I mean clearly documenting how a particular piece of functionality is expected to behave and also what should happen when something is done incorrectly (e.g. bad data such as a string when a number's expected, clicking submit multiple times on a web-app, etc...). It's identifying and documenting how to deal with the failures that really take the most effort.
[1] https://www.amazon.com/Writing-Effective-Cases-Alistair-Cock...
Your notation looks correct, but as Neil and Chris point out, there is very little to judge beyond that. This is a good start in helping you organize your thoughts, understanding the large-grained use cases and involved actors. Now, you need to proceed to break down the large-grained use cases into more-focused, finer-grained steps. Textual use cases are good for this. You might check out Writing Effective Use Cases by Alastair Cockburn for more information.
Once you have your steps reasonable defined, you can then flow into Activity Diagrams to more clearly show the logical flow, then on to Sequence Diagrams where you will really begin to flesh out the details of interaction. Note that this is not a strict linear process. Things you discover as your create each artifact likely will require you to revisit previous diagrams. As you proceed, however, your Use Cases, Class Diagrams, and other artifacts will evolve into a better representation of your target system.
Read Alistair Cockburn's Effective Use Cases book (see it on Amazon: 1). He does an excellent job of explaining practical use of use cases in a structured and effective way.
This is the book on use-cases: http://www.amazon.com/Writing-Effective-Cases-Software-Development/dp/0201702258/ref=sr_1_3?ie=UTF8&s=books&qid=1244456081&sr=8-3.
The drawing part og usecases is not important, it's the textual part thta matters...
In my opinion, use cases are one possible way to get a clear understanding of your requirements. So, as ChrisBD already stated, there won't be a diagram out there that suites your needs and, most importantly, even if it were, this is not desirable.
It's important to know that the valuable part of creating use cases is not the creation of a UML diagram(altough they are helpful for getting an overview of a system). The much more valuable process is writing the textual description of a use case.
There are various templates which guide you through the process (e.g., by Alistair Cockburn [1] or others [2,3] ). If you are interested in the subject, I can recommed the book "Writing Effective Use Cases"[4] by Cockburn.
[1] http://alistair.cockburn.us/Basic+use+case+template (great resources for use case in general)
[2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.255 (easy for starters)
[3] http://hcid.soi.city.ac.uk/research/Rescue.html (uc embedded in requirements engineering)
[4] http://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258/ref=sr_1_1?s=gateway&ie=UTF8&qid=1285833847&sr=8-1
This is a somewhat deep question, so I am hesitant to give a short answer. It is a good idea to read a few good books that describe different approaches, such as The Inmates Are Running the Asylum, which describes scenario-based function design. Another approach is to use high-level use-cases, as described in Writing Effective Use Cases.
Some guidelines:
When you are introducing someone new to your programming environment they need to understand the business problems as opposed to the technical. For the feature set under consideration, you need to identify the expected success paths and minimize the failure space before handing off to them. By this I mean clearly documenting how a particular piece of functionality is expected to behave and also what should happen when something is done incorrectly (e.g. bad data such as a string when a number's expected, clicking submit multiple times on a web-app, etc...). It's identifying and documenting how to deal with the failures that really take the most effort.
Then assuming a human facing piece of functionality, lead with user interface designs (e.g. wireframes) and written use cases. If this functionality is meant to exist in, or integrate with, another system UML diagrams are useful to show that interaction. At this point, are you hiring a glorified typist or someone who can think? If the former, then really get into the weeds and UML out the class hierarchy.
Templates
One option is the format recommended in Alistair Cockburn's Writing Effective Use Cases:
Step 2a occurs after step 2 and before step 3. If the UC ends at step 2a2 then simply replace 'returns to step 3' with 'Use Case ends' or similar.
hth.