Use Case Diagram - The Basics
/USE CASE DIAGRAM - Includes Free Template
A use case diagram provides a high-level description of what your system should be able to do and who/what will interact with it. It’s a technique for specifying functional requirements.
Because use cases are easier to draw (when compared with other UML models), I'll just provide a guideline of the rules to follow and some examples below:
- An actor can be a person, company, gadget, software or external entity that interacts with your system. For example, a customer, a restaurant, or database can be referred to as actors. They are usually modelled as being external to the system boundary.
- A use case is the action that is performed within the system. It is usually represented as a combination of a verb and a noun, e.g. “deliver product”, “prepare invoice”, etc.
- The <<uses>> and <<includes>> text when added to a relationship and drawn from A to B means that doing A involves doing B at least once.
- You may choose to insert a boundary across the use case diagram to indicate the system functionalities that fall within that boundary.
A common confusion with use case diagramming is the difference between <<extends>> and <<uses>>. I like to define "extends" as an optional functionality. Think of a use case called “pay for item”. This can be achieved by “pay by credit card”, “pay cash on delivery” or “pay by PayPal”.
According to BABOK V2, "extends" allows the analyst to demonstrate additional behaviour of the base use case. The base use case is completely functional on its own and can do without the extending use case. An extension is functionally identical to an alternate flow, but is captured in a separate use case for convenience.
I'll now use an e-commerce site as an example. Placing an order requires the customer to first select an item. The base use case "place order" thus uses the "select item" use case. In a similar vein, placing an order on the website in this example, requires creating an account first.
The distinction between <<includes>> and <<uses>> should also be understood. The include relationship implies that the base use case includes the functionality of another use case (inclusion use case) while the uses relationship implies that the base use case cannot be complete without the use case it requires.
Use cases can be supported by textual descriptions known as use case descriptions to provide a greater level of detail on system functionality. Use cases focus on the "what" and not the "how"; they also do not indicate or suggest the order in which the system functionality is performed. Click here for an extensive review of techniques for identifying use cases.
Download the use case diagram template here (It's in Visio XML format and can be opened with Microsoft Visio).
An example is shown below:
Sample Use Case Diagram for an e-commerce site
**Check out Laura Brandenburg's training course on Use Cases and Wireframes.**
