Use Case Diagram Guidelines for Better Use Cases

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.

A use case diagram mainly consists of actors, use cases and relationships. More complex larger diagrams can include systems and boundaries. We’ll discuss the use case diagram guidelines based on objects.

It is important to remember that these are use case diagram 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, check out our use case diagram tutorial.

Actors

  • 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.
use case diagram guidelines for actor

Some things to consider when creating the actor element in use cases

Use Cases

  • 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.
guidelines to follow when drawing use cases in use case diagrams

Few things to consider when drawing use cases

Relationships

  • 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 don’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 use case diagram guidelines you should follow when creating use case diagrams. However, there could be plenty more use case guidelines 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. It’s a good place to ask questions too :-).

Author

Nishadha

Software engineer turned tech evangelist. I handle marketing stuff here at Creately including writing blog posts and handling social media accounts. In my spare time I love to read and travel. Check out my personal blog Rumbling Lankan where I write about online marketing stuff.

Comments

  1. henok tesfaye

    Extremely Helpful Thanks!!!

  2. fadwa

    i am making use case diagram on functional requirements. in the given scenario system provides selection options to select desire algorithm. user can implement 4 different algorithms (i.e ABCD) for different purpose on the given data set ( only one at a time). by making use case diagram, will these four algorithms be extends or generalize from the use case “select algorithm”?. or these four algorithm will be separate use cases associate with actors?? please give me idea to solve this problem .

  3. addrea

    Excellent information.can i get the detail tutorial of how to find use cases, actors and all relation between them from textual representation of requirment document.

Leave a Comment

*
*

three × three =

Back to top