The use case model is arguably the most used requirements model in the IT industry. It’s a simple-to-use visual model. Use cases are further referred to as the most valuable requirements tool that captures the functional requirements in the context of user actions. Use case allows everyone to be on the same page about the understanding of the software requirements.
But do we practice it correctly? What are these top use case mistakes we must avoid? In this guide, let us learn about the Top Use Case Mistakes to Avoid while framing it. But before we do that, let’s talk about the use case diagram.
What Is a Use Case Diagram?
A use case diagram represents the observed interaction among actors and the system being developed as a behaviour diagram. The system, associated use cases, and actors are represented in the diagram. Hence, a use case is made up of a number of possible interactions between users and systems that specify the functionality to be implemented as well as how any potential problems should be fixed.
A use case (or series of use cases) contains the following features:
- It sets up the functional requirements
- It models interactions between a system, an actor, and a user.
- It explains one primary course of events and perhaps additional exceptional courses of events, often known as routes or user scenarios.
Read More – Non-functional Requirements
Mistakes to Avoid in Use Case Diagrams
1. Confusing Use Cases with Process Model
Use cases serve as a good representation of high-level requirements and aid in understanding all of the system requirements. Use cases need not be considered to be steps in a business process, however.
When we start thinking of use cases as part of a business process, we lose focus altogether and that leads to mistakes. In fact, each use case itself is a business objective or goal that drives further investigation to identify the procedures necessary to achieve those goals.
Learn More – What is Business Process Reengineering (BPR)?
2. Confusion between System Functionality and Operational Functionality
There is a difference between what a software system does vs what a company does. This is a classic mistake of not identifying the use cases and actors correctly.
An example will help in explaining this issue.
The following diagram represents the use case model of an airline check-in system for travelers where they can check in themselves.
Even though a traveler can get a check-in done through a counter staff (at the airports) or by dialing in, the travelers are not interacting with the system directly. So, these are not valid actors in this case for this particular software (the scope is to develop software to be used by travelers).
3. Including User Interface Details in Use Cases
User interfaces or user screens are NOT use cases; rather, they are high-level requirements or feature representations. A common blunder is to confuse a menu item or user interface for a use case.
For instance, “Clicking on the login button” or “Entering demographic details” are user actions in a system, not use cases.
This occurs because, at this point, we begin to focus more on “HOW” than “WHAT.”
Read Now – What Is Requirements Analysis and Modelling?
4. Confusing System Modules with Use Cases
The system modules or functional modules are not used as case candidates. Use cases indicate a system feature, a business objective, or a goal.
The error where system modules are mistakenly labeled as use cases is indicated in the following diagram.
5. Confusing Include with a Next Step
Include represents a mandatory relationship between use cases. For example, “Login into the system” has an <<include>> relationship with “View Order” or “Raise a ticket”.
However, <<include>> does not represent the next step in a process. For example,
“Search for Mobile phones” does not include “Add to shopping cart”
6. Showing Too Many Details into Use Case Model
Use case models in general, are developed to help stakeholders in understanding system functionality and features. It’s not a playground or a showcase of your skills.
A complicated use case diagram may demonstrate your skills, but it will be useless if it does not benefit the stakeholders.
If the number of use cases is too many, you can always divide them into module-wise use cases or choose a way to partition them.
Read Now – How to Handle Difficult Stakeholders?
7. Describing Everything a System does in a Use Case
It is crucial to ensure that use cases are understood by everyone and for doing this it is important to identify and describe them properly. Moreover, describing a use case becomes more important when there is a complex user-system interaction involved. Therefore, describing the system behaviour is important for developing and testing the system.
Benefits of Use Case Diagram
Here are some benefits of the use case diagram that you can go through.
- By dividing the issue into key user features (i.e., use cases) and defining applications from the users’ point of view, use cases can assist in managing the complexity of large projects.
- Use cases are an effective method for gathering and capturing black-box functional requirements.
- Since use cases are presented in normal language, they are simple to understand and offer a great means for engaging with customers and users.
- Use cases offer a good link between the validation of the interaction between actors and a sequence of collaborative objects.
- The use case-driven approach offers transparent links for project tracking, with the main development activities, such as the use cases implemented, tested, and deployed.
Trending – Why would I need a business analyst? Can’t a developer gather the requirements?
Conclusion
We hope this guide on top mistakes to avoid was helpful and that you were able to grasp the basics of use case and use case diagrams. Use cases are a great way for managing complex and large projects. Use cases are designed to capture the high-level view of the system and must be used for that purpose by avoiding the mistakes pointed out above.
Are you eager to learn more about Business Analysis and how to frame use cases? If so, you can explore our certification and short business analysis courses. Moreover, you can also leverage our Business Analysis Self-learning course to develop your business analysis skills.
Furthermore, we offer comprehensive ECBA and CBAP Training sessions to business analyst professionals. In these courses, you can leverage our top-rated question bank, mock exams, mindmaps, doubt-clearing sessions, and one-on-one training from IIBA Certified industry trainers and professionals.
