When Use Cases Are Not the Best Choice

Even though use cases are a popular and widely adopted technique that comes with many benefits, there are situations when they are not the best choice for describing software requirements. In the following cases, the analyst should consider selecting another requirements analysis technique.

UI-Intensive Applications

Dashboards, calendars, email clients, or editors – all of these are not easy to describe using use cases. This is because the core requirements of such applications lie one level below the user goals – in the individual system functions which are not best described by use cases. What is more, intensive interaction with the user interface tempts analysts to misuse use cases to perform functional decomposition, so they usually end up with dozens of micro use cases that do not provide any value.

Example 1: Dashboards

It would work to define use cases such as Add Fragment to Dashboard, Move Dashboard, or Refresh Dashboard, but the analysis would end up consisting of separate functions with short, two- or three-step-long scenarios. These functions would be called use cases, but in fact, they would be just ordinary system functions dressed up as use cases. Save time, avoid use cases, create a wireframe, and describe the individual features the user interface should have. You will be a more effective analyst.

Example 2: Editors

Let's look at a system for managing cutting tools, which includes use cases such as "Edit tool", "Show tool" detail, or "Import tools". According to stakeholders, there should also be functionality to manually create a tool by selecting its main parts, specifying its parameters, changing the order of the parts, and generating its 3D model.

We saw an inexperienced analyst model each function named above as a separate use case. It worked, the system was implemented, but the use case management was a mess, as it was not clear what was a user goal and what was just a function. Such use cases have a very trivial scenario (system opens an editor, user creates a new tool and saves it), but have complicated logic inside each scenario step (editor, wizard, process, etc.). Use case analysis is based on scenarios, so it does not make sense to use this technique if the scenarios are not the core aspect on which we need to focus.

Example 3: Wizards

A common element of business applications is a wizard, which guides users through particular steps that must be completed in order to finish the entire task:

Since a wizard is, in fact, a user-system interaction, it seems to be a good idea to describe the wizard as a use case. However, a wizard description requires different information. It must be clear what the steps are, which user actions change the state of the wizard, and from which steps it is possible to go back, for example. Wizards are very user-interface-oriented, so instead of using scenarios, screen flows or event lists would be a better choice. Wizards could also have complex logic inside, which is not suitable for a textual description – in this case, an activity diagram could be a good technique, for example:

Note: Even though the wizard is not described using use cases, we need to somehow store the user requirements. This is why the "Create Item" use case is included; its goal is to streamline the management of user requirements.

Automats and Batch Jobs

Another example of inappropriate use of use cases is the specification of complex computations, automatic jobs, and batch data processing. All of these are implemented as system functions, usually run automatically with minimal user interaction. Therefore, there is basically no real user-system scenario, and all scenarios look very similar: "User starts the function, system calculates the amount and sends a notification". But at the same time, they include complex logic which is placed one level lower. Examples of such functions are automatic regular jobs (crons, watchdogs, etc.) or systems whose primary purpose is to provide services for other systems, for example, functions for sending SMS messages or emails.

Process and Workflow Systems

Use cases generally excel at describing user goals in the form of user-system interactions with a defined start and finish. A user triggers the use case, interacts with the system somehow to meet the goal, and gets the results. However, many of today's business applications are designed to support process management and workflows, which means that the use case itself is just a part of more complex functionality and is preceded and/or succeeded by another use case (workflow step). While use cases are great for describing the individual steps, they are not meant to document the transitions between individual tasks. One possibility is using an activity diagram:

Event-Driven Systems

Let's look at the following situation: an analyst was asked by a friend, an enthusiastic young entrepreneur, to design software for operating his new automatic dog door. Obviously, the analyst needs to first find out how the door is expected to work, but in this case, the good old use cases are not going to help much. The software the analyst is asked to develop is not the type of application suitable to be described by use cases. The analyst must deal with embedded software, which is not defined by user-system interaction, but rather by events the system accepts and its responses to those events. The user, actually the dog, does not work directly with the software, as is common in the case of business applications, so there is no user-system interaction. The interaction is between the user/dog and the hardware, and between the device and the software. This requires the analyst to use a completely different set of techniques.

In the first phase, the analyst mapped the states the door can be in and the transitions between them. This gave him an initial idea of how the door was going to work and, mainly, the events to which the door would have to react:

Once the events are clear, it is possible to design responses to these events: