When it comes to analyzing the requirement of a system use case diagrams are second to none. They are visual and usually very easy to understand. The following use case diagram guidelines will help you to create better use cases that are appreciated by your clients and peers alike.
It is important to remember that these are guidelines and not rules. It’s alright to deviate if it improves the overall quality of the diagram. To get a deep understanding of use case diagrams checks out our use case diagram tutorial.
- Give meaningful business relevant names for actors – For example if your use case interacts with an outside organization it’s much better to name it with the function rather than the organization name. (Eg: Airline Company is better than PanAir)
- Primary actors should be to the left side of the diagram – This enables you to quickly highlight the important roles in the system.
- Actors model roles (not positions) – In a hotel both the front office executive and shift manager can make reservations. So something like “Reservation Agent” should be used for actor name to highlight the role.
- External systems are actors – If your use case is send-email and if interacts with the email management software then the software is an actor to that particular use case.
- Actors don’t interact with other actors – In case actors interact within a system you need to create a new use case diagram with the system in the previous diagram represented as an actor.
- Place inheriting actors below the parent actor – This is to make it more readable and to quickly highlight the use cases specific for that actor.
- Names begin with a verb – A use case models an action so the name should begin with a verb.
- Make the name descriptive – This is to give more information for others who are looking at the diagram. For example “Print Invoice” is better than “Print”.
- Highlight the logical order – For example if you’re analyzing a bank customer typical use cases include open account, deposit and withdraw. Showing them in the logical order makes more sense.
- Place included use cases to the right of the invoking use case – This is done to improve readability and add clarity.
- Place inheriting use case below parent use case – Again this is done to improve the readability of the diagram.
- Arrow points to the base use case when using <<extend>>
- <<extend>> can have optional extension conditions
- Arrow points to the included use case when using <<include>>
- Both <<extend>> and <<include>> are shown as dashed arrows.
- Actor and use case relationship doesn’t show arrows.
Check out the link to learn more about use case diagram relationships.
Systems / Packages
- Use them sparingly and only when necessary
- Give meaningful and descriptive names to these objects
More Use Case Diagram Guidelines
I have covered some of the most common guidelines you should follow when creating use case diagrams. However, there could be more plenty more depending on the circumstance. For example you might have a company standard for naming objects. Do take those into consideration when creating your use case diagram.
Of course if you think I’ve missed a critical point or a commonly followed standard make sure to mention it in the comments. Its a good place to ask questions too :-).