Continuing our journey to understand software development, we will stop to think about the important aspect of the product we are building, and by that I mean who is interacting with our system. Now, imagine that we combine the words that are in the title, what do we get? The answer is our next important topic: Use Cases.
Where are going to continue by defined the use cases based on the Unified Process paradigm we defined in the previous post Unifying Software Development Methodologies, where there are going to be many users that interact with it, and those interactions might be different depending the type of user they are (actors), and also might have different relationships with the objects that are part of the system or other users. For example, an online classroom (the most used example, but easiest to understand), where there are teachers, helpers and students. They have different views, permissions, and a different way to interact with the whole system, i.e., the system has different use cases depending on the user.
I know, i know, I might be over reusing the word “use cases”, I didn’t understood at first why they are important because they kinda seem obvious, so let me explain. Most of humans are really good at creating or building something if you have a set of instructions, sometimes these steps are really easy to follow and even sometimes are not necessary, for example, when you are preparing a bowl of cereal, you don’t really need instructions for that, but if you want to make a Lakeside Paella, you probably not even memorize the ingredients.
Use cases are really important to define the actors in the system, and at the same time, creating a blueprint of what to expect. This blog post by Tech Republic states that use cases are a great guidebook when you are developing and they give ten reasons why they are really important, in my options these three are key (the rest are important too, I recommend reading the post, it’s really useful):
- Reveal process alternatives, process exceptions, undefined terms, and outstanding issues: You will never cover all the things needed in a complex system, but you need to try to minimize these errors, and when you create use cases, you and your team can start brainstorming or realizing about things you haven’t consider before.
- Recognize patterns and contexts in functional requirements: Some uses between uses are related, and by defining them before hand, we can define similar functionality that both can share, to make a more simpler and cleaner design.
- Ensure the delivered software works properly: A key factor before delivery is testing, and if you have a blueprint of the expected behavior, you can use it to create test based on those assumptions and write good tests that others can read and help understand the functionality of the system.
There’s an important thing that you need to consider about use cases that Josh Spilker states on his blog post “What Is A Use Case?” (careful with the popups): Use cases explain behaviors, but not how to built or construct the system, they are quite simple.
Sometimes use cases are represented as diagrams, and in that case are part of UML and known as Use Cases Diagrams, they do not have to be always like that but are one of the common ways to define them.
Final Thoughts
If you read my previous post about Software Life-cycles, I talked about Agile, that approach has some term that might sound familiar to you if you read more about it, called User Stories, which I originally confused with use cases, they are somewhat similar, but they really serve different purposes, I recommend reading User Story vs Use Case by Visual Paradigm to understand the difference if you are struggling with the same problem.
I find quite amazing what people on the 80s-90s built from the necessities they started noticing when they were building software systems back in that time, and that the name Ivar Jacobson appeared again (this guy is everywhere in these blog posts). Use cases are a clear example of that, they are something that is really useful for early and future development because they define part of your requirements, an also you can come up with things you haven’t thought before.
Hivini 
