Use cases, scenarios and user goals

This isn't quite right. A scenario represents a particular path through a use case or a specific instance of executing a use case.

Each use case encompasses multiple scenarios. Each scenario involves certain data combinations and branches taken through the use case execution. Some scenarios result in success; that is, the user achieves his intended goal. The most typical or default scenario typically is called the normal flow of the use case. Other scenarios or paths through the use case that also result in success are alternative flows. In addition, most use cases identify conditions under which they might fail to complete successfully. These are called exceptions. Exceptions represent another type of scenario, a failure scenario.

It's really a question of abstraction level. A use case is more abstract, more general, than a scenario. When working with use cases, it's always a struggle to determine the most appropriate level of abstraction. If the use cases are written at too low an abstraction level, you can end up with a use case explosion. This can lead to hundreds of use cases, some of which represent just minor variations on a common theme. This is a clue that you need to write the use cases at a higher level of abstraction and treat these variations as different flows within the use case, or simply as data variations that could take place during execution.

Use cases and misuse cases: Use cases don't need to include all system functionality details Software requirements analysis: Five use case traps to avoid Threat modeling enhanced with misuse cases

Be cautious about dividing a use case. Remember, a use case states a goal the user is trying to accomplish. Don't arbitrarily split a use case up just because it gets big or has many alternative flows. If the ultimate user goal is the same for each of the flows, it's one use case. The only time you should subdivide a use case into multiple use cases is when you realize that some of the flows might logically fit together and be qualitatively different from another subset of the flows. For instance, if you find the word "and" in the name of your use case, you might need to split it into multiple use cases because it really represents multiple goals.