Incorporating too much in a single use case by capturing several goals or business values in one use case.

Keywords: Alternative flow, business value of a use case, large use case, long use case.

It is sometimes tempting to identify use cases that are oversized, that is, use cases including too many alternative flows. In an attempt to reduce the size of the model, the developers might have merged certain use cases that ought to have been kept separate. Each use case should have only one goal. This makes it easier for a reader to understand the purpose and the value of the use case. Furthermore, when a use case encompasses too many goals, there are usually many stakeholders interested in that use case, making it complicated to make decisions regarding that use case. Many people will want to have their say, incorrect assumptions might be made, and various compromises might have to be made before the stakeholders will settle on a definition of the flow of the use case. Different readers might also misinterpret a use case whose definition is very general, and therefore they are likely to assume that it captures things that it really does not offer.

Furthermore, it is bad use of resources to have reviewers read what they neither need nor opted for, which will be the case if a certain stakeholder is interested in only a small part of a large use case.

Splitting a use case does not increase the amount of development work, although it increases the number of use cases and the documents describing them, but it clearly increases the understandability of the model. If too much is expressed with a single use case, the use-case modeling effort has not added much to the understanding of how the system is to be used.

In a sense, this modeling mistake can be seen as the counterpart of the Micro Use Cases modeling mistake.

The way forward when trapped by this modeling mistake is of course to split the “Do Everything” use case into several use cases, one for each business value or goal.

As a first step, the actors involved in the use case should be reviewed. Sometimes, perhaps as a consequence of this modeling mistake, there are also actors capturing too much. Make sure that all the different roles played by the system surroundings interacting with the use case that need to be split are represented by a separate actor and, if not, identify additional actors for individual roles.

The next step is to focus on one of the actors at a time. For each of the actors, the parts of the large use case that this actor will want to make use of all constitute candidates for new use cases. When such use-case candidates are identified from the original, large use case for all the actors, it may be apparent that some of them should be combined into CRUD use cases (see Chapter 20, “CRUD”). The other candidate use cases will be new use cases of their own.

After the relevant parts of the original use-case description have been moved into the descriptions of the new use cases, you can remove the original use case from the model.