What is a Use Case?
A use case is a description of a sequence of interactions between a user and a system that leads to some goal being achieved for that user.
For example, imagine a thirsty person wants to buy a can of coke from a coke machine. The goal in this case would be the thirsty person obtaining their can of coke. A simple use case description for this might be:
“The thirsty person selects his/her chosen beverage from the list of beverages available in the machine. The system responds by showing the amount of cash that should be inserted. The thirsty person inserts a sequence of coins that add up to the specified amount. The system drops a can of coke into the dispensing tray. The machine updates its inventory and cash ledger.”
Use cases are intended to be black box descriptions of system behaviour. By this we mean that the text should describe inputs and responses observable from outside the system. It should not include internal implementation behaviour. Occasionally it is useful to record internal information changes, if they will be observable as part of other use cases, but this should not be implementation detail. For example, in our description above, we mentioned that the machine updated its inventory and cash ledger. There will be other use cases that allow external users to review stock levels, or to do cash balancing when emptying/restocking the machine. Note though that the use case did not describe how this happens.
Use cases need external entities that have a goal the system can deliver. These external entities are known as actors. Actors might be human beings interacting with the system via some kind of user interface. They might be other systems or equipment interfaced to the system being modelled via some kind of networked or electronic connection. They might be external entities that trigger electro-mechanical equipment, such as trains passing over track sensors on a railway signalling system, or a timer in an elevator control system that shuts the elevator doors. In any event, these external entities are considered (a) outside the system being designed, and (b) to have a will of their own (the system cannot predict when or what input they might give to the system at any moment in time).
Use cases form the main part of functional requirements documents. As such, it is important that they are written using terminology familiar to the stakeholders from whom the requirements are elicited. This is necessary so that requirements analysts or agile product owners can take the use case descriptions back to the stakeholders and do walk-throughs with them to confirm the requirements are complete, unambiguous, and sufficient.