What should be modeled as a sub use case in a use case diagram?

Question

I know how to draw a use case diagram, but it suddenly comes to me that what functionality should be modeled as a sub use case that is included in another use case? As sometimes the functionality is just part of the use case and it's hard to decide whether to extract out and make it a sub use case or not.

Answer 1

There is no right/wrong answer to these type of question (and use cases in general). You'll have to decide for yourself what seems to be useful for you or not.

But there are a few considerations and guidelines that can help you decide whether or not you should use included use cases.

Behavior is shared between different use cases

When describing the use case scenario you find yourself repeating the same chunks over and over in different use cases

Its a large enough chunk of behavior to be a use case

You should not use included use cases for one or two steps in your scenario that are shared between use cases. I'd say that in order to be considered you should at least have 4 steps in the main scenario, and maybe a few alternate or exception scenarios.

The behavior can also be used on its own

If the shared behavior is also something that can be used on it's own, without the including use case, then you definitely have a case for an included use case.