Hi Graham,
This is long-winded, but please bear with me.
The short answer to your question(s) is: Perhaps, but not really.
Note that the following is not meant to the 'gospel' of use cases, just to get you unstuck.
+++++
NOTE ALSO: I am not going to suggest a help text on use cases. There are several threads in the forum that provide many excellent suggestions, with discussion of strengths and weaknesses of each.
IMHO Searching for these threads is well worth your time.
Helpful posters with yet another (probably repeated) suggestions would do well to search for one of these threads and add their suggestion if it is not already there, or their comments if it is. Posting a suggestion here (or in another thread that is not specifically for use case documentation suggestions) only serves to 'blur' the suggestions across the entire forum. This will quickly make finding a good set of suggestions essentially impossible.
+++++
Use cases are not meant to be procedural breakdowns of system usage. They should tell us what the 'users' (which for use cases includes other systems, components, and perhaps even events and triggers, as well as people) experience when interacting with a system, and what the system will do for those users. That said, you don't necessarily need to break a multi-tier menu down into multiple use cases.
As an example (somewhat contrived, to illustrate the point)...
Say a user needs to open a file via some kind of menu sequence like 'File | Open | Text File' where the final option is selected from a lower-level menu. [Perhaps there are other types of files, some of which may have even more detail at lower levels.]
In the above case just list the sequence of menu pads that the user must click, don't create cascading use cases. The use case you will end up with will illustrate a single interaction with the system - opening a text file - from start to finish; thus (exactly) one use case is needed, and appropriate. There is a success condition, which is that the user has successfully (perhaps chosen, depending on your system) and opened a text file. There are obvious situations that would constitute failure, and various alternate paths should be apparent. All of these are scenarios (or parts thereof) within the single use case.
As an informal test, imagine that we change the system to use an Open dialog. The user now sees a different (shorter) menu sequence and then a dialog. This is a small change to the use case, and should be well contained, perhaps in a preamble to the main scenario. The overall use case would remain the same. This makes sense, since the interaction described (between the use and the system, for the purpose of opening a text file) has not changed at all.
Note that you might have other use cases for different file types, or expand this single use case to handle all file types. This kind of decision depends on your organization, the end client of the system, the system itself, your methodology, and level of presentation and documentation you require.
Now, how to go about describing the system itself...
You could use more detailed use cases to drill down to how the menus work. These would not be connected to the above use case in the ways you describe. They would more likely be 'inner' use cases (at a lower model level) or connected by something like a «trace» or «realize» link. It might be (more) effective to use a different diagram type to drill down to the details, with or instead of low level use cases. Common choices include state models, activity diagrams, and sequence diagrams, though others are certainly possible.
EA makes the above situations easy to set up and visualize. Use composite elements or right-click a use case element and choose Add from the context menu - there's another level of menus there, but not another level of instruction (use case) since you're only doing one thing; you'll see.
HTH, David
