;-)  Sounds like a good enough guideline...  I realize that you are trying to ensure the readability/usability of the use case and try to keep it less complex - however, at the same time, you don't want to have too many use cases with similar names but with very small variations.

From my personal experience leading teams of business systems analyst I realized that it is important to realize that any standards that we put in place are simply "guidelines".  There is no one standard and choice that will work for all situations.  On my team, I tend to be stricter with the guidelines when it comes to the junior analysts and tend to be more flexible when it comes to the senior analysts who can make better decisions when not to follow the guidelines.

The interesting thing about the business analyst (and systems analyst) profession is that there is a large amount of "art" in addition to the "science".  As much as we would want to use a very structured and rigorous methodology, the reality is that the consumers of our artifacts also include the business stakeholders.  For these guys - readability and ease of use (of the artifacts) is more important than a very well structured and rigid document that reads like a space shuttle detailed design. 

This is the challenge of the IT business analyst: the artifacts created for the business stakeholders need to be readable at the expense of perfection while the artifacts for the implementation team need to be unambiguous and precise at the expense of simplicity (readability).

- Adrian