Do you remember the burgers I was talking about last time? I feel like I need to bring them up once again for this particular topic. Even if there are multiple recipes for the same kind of food, there will always be key elements that could mean the difference between what’s good and what’s not, in the case of burgers, I would say that the patty is the main ingredient: even if everything else is just fine, a raw or overcooked patty could ruin it all.
So far, I’ve talked about two ways of assist software development, but this time, I won’t be covering something as wide as the whole process, but rather a method that, just like patties, draw the fine line between a well and a poorly managed project.
If you recall from the SDLC entry, one of the stages in the software development process involves the definition of requirements for the respective project. These requirement, just like a patty, must be correctly done if you want an, at least, decent application.
When you try to list requirements for a project, some may slip your mind. You don’t want this to happen: this could later translate into a missing function inside your software or into your users not seeing their needs fulfilled. Fortunately, there’s a way to help yourself know what requirements have been completely covered and where there’s a lack of implementation.
Use cases are methodologies used to find, clarify and classify user requirements. The way I see it, they’re one of the most simple methods present in any stage from the software development process, since they involve very intuitive diagrams that make it easy to visualize what’s missing from certain scenario.
This method consists of imagining all the possible interactions between users and the software, what goals could everyone involved have in each of these interactions, how could they be achieved and what concrete actions are to be taken. Particularly, use cases are the situations for which you have multiple possible paths that could take a user to their goal. Notice that I previously used the word scenario. User case scenarios are the specific paths selected to achieve goals. This page includes clearer definitions for use case components, if you wish to know a little more about that.
The diagrams used for use cases have many elements: every type of user (or actor) has to be present; the relationships between actors is important too; generally, situations are clear and point to all the involved actors along with what action is being performed by each of them, conditional or additional events may be added too.
Use cases have to follow certain course of action, it’s important for situations to trigger other events, for which different actors could be involved.
But here’s where the fun part comes in. You can tackle this situation in, at least, three different ways: you could take each of your actors and ask yourself “What are this actor’s chores?” to then put them together into the different situations to be considered for your project; you could go through all your requirements and associate each of them to certain user case; finally, the one I would least recommend is to think of every situation that could come up during the operation of your programm to then associate actors to each of them. It doesn’t matter what technique you prefer, this way of working with requirements makes it very clear as to what is missing from your diagram once you start simulating different possible situations.
There are, at least, a couple of possibilities in which you don’t have to think about the scenarios all by yourself. Your clients could have already worked on it and definded by themselves all possible paths, outcomes or situations. You’d only have to break them down into simple actions for every actor involved.
If you don’t have a client or just if you have the possibility I’d say it’s better to find actual people who could represent the actors considered for your project, preferably if they have actual experience with their role. You can simply ask them what kind of things they have to do, from the most basic to the most obscure and little known. They could have an easier time thinking of scenarios that could come up during the use of your software.
One thing to have in mind, though, is that it wouldn’t be as useful if you took too many cases or too many variables. It’s better to keep it as simplified as possible so you don’t have to navigate through 200 different scenarios.
Just because I feel like this is necessary: the most common repreesntation of use cases is UML (Unified Modeling Language), which consists on a graphical representation where you have: a stickman for every actor, an oval for each action and different kinds of lines to represent maybe consequences, variants or optional paths. This particular topic (UML) is covered in the next mastery, so I’d recommend checking that one out.
For now, I want to include an example of a use case diagram I made for another course some time ago. It’s in Spanish and there’s only one actor, but I think it could serve as a reference:
Like every other method I’ve talked about so far, it is a very useful tool if you use it properly. Since it already involves actors you could think of it as a play. If you have too little actors or even if you have too many the experience may be compromised, if there’s no scenery or if it doesn’t fit the theme at all you may be confused as to what’s happening. Always keep in mind that you will also have to review and revisit your diagram over and over again, so it’s better for you if you just keep it simple.
TL; DR: Use cases are a way of defining who can make what and with whom.