Ask the Expert

Use cases, scenarios and user goals

If we divide a use case and split them, can any of them be a use case or a scenario? As per my knowledge, a scenario is a use case but every scenario might not be a use case.

Requires Free Membership to View

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.

This was first published in May 2007

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: