Q

Use cases, scenarios and user goals

A use case includes many scenarios. When dividing use cases, it's important to understand scenarios and use case flows with respect to user goals, explains expert Karl E. Wiegers.

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.

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

Dig deeper on Gathering Software Requirements Use Cases

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

0 comments

Oldest 

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:

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close