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 best 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, these all are not easy to describe using use cases. It 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, the intensive interaction with the user interface tempts analysts to misuse the use cases to do functional decomposition, so they usually end up having 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 Dasboard or Refresh Dashboard, but the analysis would end up being consisted 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 have 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 the 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 the 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 the business applications is a wizard, which guides users through particular steps, that must be completed in order to complete the whole task:

Since the wizard is, in fact, a user-system interaction, it seems to be a good idea to describe the wizard as a use case. However, the 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 a complex logic inside, which is not suitable for 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 the user requirements.

Automats and Batch Jobs

Another example of inappropriate use of use cases are specifications 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 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 in describing user goals in the form of user-system interactions with 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 the 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 acitivity diagram:

Event-Driven Systems

Let's have the following situation: 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 the user-system interaction, but rather by events the system accepts and its responses to those events. User, actually the dog, does not work directly with the software, as it is common in case of the 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 which the door can be in and the transitions between them. This gave him the initial idea of how the door would 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: