Use Case Diagram, Document & Templates Overview

Instructor: Geoff Miller

Geoff is a technical project manager and software developer. He has a bachelor's degree in IT and is a certified Professional Scrum Master.

Use cases are commonly used in software and system design, and they come in many forms. Learn about the different tools used for documenting use cases, including UML diagrams, written documents, and templates to aid in using a consistent use case format.

What is a Use Case?

A use case is a method of capturing requirements for software and system design. Use cases document the actions of external actors (usually humans, but external systems are also considered actors) interacting with a system to achieve a specific goal. There are many different ways in which use cases are documented, but the most common forms are diagrams using UML (Unified Modeling Language) and written documents of varying degrees of detail (from 1-2 sentence descriptions to multiple pages).

The chosen method(s) of documenting use cases can vary greatly between organizations and even individual projects within the same organization. In many cases, some combination of UML diagrams and brief written descriptions is sufficient. However, some projects may require more detailed and formal descriptions. When a very specific format is required for documenting use cases, it is helpful to create a template, so whoever is creating the use cases can focus on filling in the necessary information without needing to memorize the format.

Take, for example, Jason who is a business analyst working on a new CMS (content management system). He has to create use cases, but he is not yet sure how he wants to document them. He decides to try using UML diagrams.

A simple use case diagram
A simple use case diagram

Use Case UML Diagrams

UML is a standardized visual language for creating a wide variety of diagrams, usually related to software development. The most common kind of UML diagram for use cases is referred to simply as a use case diagram. Use case diagrams are very high-level representations of one or more use cases for a system. They capture the interactions between actors and the system, but generally do not provide adequate detail to capture all requirements. A typical use case diagram will have one or more actors (usually portrayed as simple stick figures, although non-human actors may use a different icon), one or more use cases with two or three word descriptions (e.g. Write Article), and lines indicating the relationships between actors and use cases (e.g. a line from the Writer actor to the Write Article use case).

A use case diagram alone is usually not sufficient documentation. Sequence diagrams are better suited for capturing detailed requirements. A sequence diagram is a representation of all the actions in a particular use case (or group of related use cases) arranged horizontally. In a typical sequence diagram, actors are on the far left, vertical bars representing each system component follow to the right, and horizontal arrows with descriptions of each action connect the actors and the bars. There is a wide degree of freedom in the level of detail captured in a sequence diagram. It's possible to capture requirements down to the technical level of the objects and functions that will be used in the code when the system is written.

Let's return to our hypothetical business analyst Jason. He creates some use case diagrams for the system. He finds that they are great for documenting all the use cases needed for the CMS, but he needs a better way to capture the detailed requirements. He experiments with sequence diagrams, but he decides that written documents would be clearer.

Use Case Documents

Diagrams are not necessary for documenting use cases. Many projects are just fine with written use case documents. There is no standard format for a written use case, but at a minimum a written use case should contain a title, the primary actor, any secondary actors, and a description with enough detail for the system's developers to implement it. Commonly, this means a step-by-step guide to the actions of the actors and the system, expected states before and after the use case occurs, and alternative flows through the use case (e.g. denying the user if they have insufficient access). There may also be other information such as a justification of the need for the system to satisfy the use case, a list of the use case's stakeholders, and non-functional requirements (e.g. the system must provide 24/7 access).

To unlock this lesson you must be a Study.com Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use Study.com

Become a Study.com member and start learning now.
Become a Member  Back
What teachers are saying about Study.com
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account
Support