Business Analysis Training

Business Analysis Training – Use Case Diagrams – Part I

Use Case Diagrams – Part I


When it comes to UML Diagrams, Use Case Diagrams tend to be one of the first diagrams created when modeling requirements. Why is that? Well, it is probably because they provide a high-level overview of requirements. If you’d like a definition, I might say that Use Case Diagrams are used to identify the primary elements and processes of a system. In UML terminology, the elements are referred to as “actors,” and the processes are referred to as “use cases.” Let’s take this definition just a bit further.  When I create Use Case Diagrams, I look for four things:

1. Actors: An actor can portray any kind of entity that interacts with a system. This could be a person or another system. More often than not, actors are drawn as stick figures outside of the system. Here’s an example of what an actor might look like:

(Isn’t it strange that the original form of written language on cave walls used stick figures and, now, an advanced modeling language also uses stick figures??)

2. Use Cases: A use case represents a distinct business process or functionality of a system. Use cases are drawn as ovals inside of the system. Here’s an example of what a use case might look like:

3. System Boundary: The system boundary is what separates the actors from the use cases. It also ensures that the use cases are grouped together based on their related functionality. The system boundary is drawn as a rectangle that spans all of the use cases. Here’s an example that includes the two previous examples with the system boundary:

4. Relationships: The actors need to be connected in some way to the use cases. That is done with relationships. Relationships are drawn as lines between the actors and the use cases. There are also special cases of relationships that are drawn between use cases. Here’s an example in which the line is added to the previous example:

Of course, this is a very simplistic overview. Coming up in a future blog entry, we’ll try a more practical example in which I will give you an actual requirement. Then, we’ll walk through the process of converting the requirement to a Use Case Diagram. Plus, I will provide you with some more details about the various relationships.

P.S. – For those of you who are curious, these diagrams were created using Poseidon for UML Community Edition 8.0. Support the community:


Scott Fabel

Scott Fabel is a senior corporate training consultant with Computer Aid, Inc. He has over 18 years of experience working with various Fortune 1000 companies on Help Desk Implementations, Microsoft Technologies, Business Analysis, and Project Management. This includes both consultative services and customized training programs. He is HDI certified, PMP certified, CBAP certified, and a MCT. Scott has been teaching others business skills, professional skills, and technical skills for more than 13 years. He is a faculty fellow at the University of Delaware and is currently pursuing his doctorate in education for which his dissertation will focus on the benefits of corporate training and mobile learning. He speaks three languages and was recently inducted into the International Martial Arts Hall of Fame. His communication skills, combined with his martial art skills, provide him with a unique combination for keeping his sessions informative, lively, and interactive.

Related Articles

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.