Use case model is arguably the most used requirements models in the IT industry. It’s simple to use visual model. But do we practice it correctly? What are the top use case mistakes we should avoid?
Here are my top use case mistakes
1. Confusing use cases with process model
Use cases are representative of high level requirements and help in understanding system requirements in totality. However, use cases need not be thought of as steps of a business process. When we start thinking of use cases as part of a business process, we loose the focus altogether and that leads to mistakes. In fact, use cases themselves represent a business objective/goal leading to further analysis to discover the steps in achieving those goals.
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. What’s wrong with this diagram?
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 a software to be used by travelers).
3. Including user interface details in use cases
Use cases are high level requirements/feature representation and NOT user interface or user screens. Confusing a user interface or a menu item with a use case is a common mistake.
For example – “Clicking on login button” or “entering demographic details” are not use cases, they are specific user actions in a system. This happens, because we start thinking about “HOW” rather than “WHAT” at this stage.
4. Confusing system modules with use cases
The system modules or functional modules are not used case candidates. Use cases represent a business objective or a goal or a feature of the system.
The following diagram shows the mistake where system modules are identified as use cases.
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 or for that matter, any use case model is created to help stakeholders better understand the system function/features. It’s not a playground or display of all your prowess.
A complex use case diagram may show your skills but will serve no purpose as it does not help the stakeholders.
If the number of use cases are too many, you can always divide them into modules wise use cases or choose a way to partition.
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 above.
We feel glad to know your views.
Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.
We have a Business analyst training course with domain training in-built into it. This training program offers you the opportunity to get certified with ECBA certification as well as have banking domain understanding.