Hello,
The thing to be careful with when you're writing use cases is not to get into the design of a solution. A (good) use case describes the interaction between a user and the system under analysis, and is expressed from the user's perspective.
If you're concerned with overlap between use cases, don't be. Use cases are part of requirements analysis, and requirement overlap is perfectly fine. It's the design, not the requirements analysis, that takes care of those overlaps. (In fact, the number of times a requirement recurs can be used as an indicator of which requirements should be prioritized in the design.)
The key factor when determining whether to split a use case into two is whether or not the two use cases describe interactions which are distinct in terms of what they achieve for the user.
In this case, the user wants to exit a program. Would the user think that closing a program
with save confirmations is fundamentally different from closing a program
without save confirmations?
In most cases, the user would not. But in some cases, they would. So that's when you get into user analysis: who is the user? For whom are you designing the system?
Without that information, no one else can tell you whether it should be one or two use cases.
I think that's essentially what qwerty was saying, just with fewer words.
Now, in order to describe the imagined flow through a use case (which is nothing to do with the designed flow through a GUI), you can use activity or sequence diagrams. I've seen state diagrams used for this purpose as well, which is sometimes a good fit. Each allows branching, loops and conditions.
EA also allows you to create scenarios in the properties dialogs of the use case elements. You can set up different whole scenarios, as well as branches and joins between paths. I prefer not to use these, diagrams are clearer and give you a far wider range of expression.
HTH,
/Uffe
