Use case diagram. A simple visualization of use cases.
What are use case diagrams? How are they created and what advantages do they offer?
“Actually, we had something completely different in mind.” Not a sentence that you want to hear from a customer. But it happens. Because reality always shows us how different people communicate differently, or misunderstand things – Paul Watzlawick, the Austrian-American communication scientist, sends his greetings. When requirements in your software are misunderstood, imprecisely communicated or just not mentioned by the customer, that doesn’t just lead to uncomfortable conflict, it also costs you time and money. That is why use cases and use case diagrams have proven themselves in project management: a graphic visualization of the behavior of a system from the view of the user, described through defined visual means of UML (Unified Modeling Language). They offer great support when finding and defining requirements.
Use case diagram: a short definition
A use case diagram is a behavior diagram and visualizes the observable interactions between actors and the system under development. The diagram consists of the system, the related use cases and actors and relates these to each other:
System: What is being described?
Actor: Who is using the system?
Use Case: What are the actors doing?
What isn’t a use case diagram?
A use case diagram doesn’t describe the order in which the use cases are carried out. For example, let’s define the use case Withdraw money. This process is carried out in many steps, like Insert card, Enter PIN, Select amount, take out amount and take card out. Of course, these are activities are all from the customer’s point of view – but this sequence should not be covered by the use case diagram. Other diagrams are recommended for that, like the activity diagram. A use case diagram should describe the desired functionality of the system and relates it to use cases and actors. That way it can represent existing viewpoints of the system and how they are interpreted differently – only through this can requirements be completely understood.
