Use Cases

--Originally published at Computer Systems Engineering

Use cases are a tool for organizing system requierements when we want to develope a program. A way to define what a use case is a descripion of all the ways that the user wants to use the system, this way we define the limits of the system by taking into account what the user will be able and will not be able to do.

A use case is different from a requirement definition in the sense that it adds a flow of how the program should work in a specific situation, makin us think beyond and not just on the first step, they make us think of the ways that the program could go wrong in each step of use and make us more cautious about those kind of things. They mark the goals that we should aspire to achieve. We can say that a use case is a diferent scenario for how things could go.

We need to be clear on what should and shouldn’t be included when doing the use cases: we need to think of the user, what type of user is and what is hin/her gonna do in the system, the steps that they will take to fulfill their desires and how the program should respond to those actions. This must not include technical stuff about what programing language to use or the specifics of interfaces.

There are several elements that we need to take into acount when doing use cases:

  1. Actor: the subject that is using the system, the one that performs an action.
  2. Pre-conditions: the things that must be true before the use case runs
  3. Post-conditions: it’s what resulted of the use case
  4. Triggers: the event that causes the use case to iniciate
  5. Main sucess sceanrios: normal path of the use case in
    Restaurant_Model
    nothing goes wrong and the actor follows what we predicted
  6. Alternative Paths: variations and exceptions to consider in the system in case anything goes wrong.

Let’s see this with an example:

In the image above we can see that the actors are the waiter, chef, patron and cashier. Let’s focus on the patron, a trigger to iniciate an action is when this subject places an order, and the main flow is that the waiter recieves the order, and proceeds with another action that is confirm the order to the cheff that is the trigger for the chef to cook food. This is the main flow but we can also see the alternative paths like if the patron wants to order wine it is seen as an alternative of the normal behaviour that is expected from that actor.

There are certiain advantages and disadvantages of using use cases. The advantages of using them is that because it makes us think of the behaviour that the user will have while using our system, we are more likely to develope a program that fulfill their needs but the disadvantages are that they are not usefull to capture non-interaction based requirements and when the interactions of user-system have too many flows the use case can become quite complex and prove to be useless when tried to be used and understood for the developement phase.

Use cases can be good to  make us think what we want our program to use, what functionalities to add and what the clients will be able to do with it, they can hepl us realize what our idea is lacking, what other functionalities we could add and much more things. Also, when we put them on a diagram its easier to see the different behaviors that each actor can have and make us visualize things better.

References: