PlantUML Use Case Diagram: System Requirements
Define system requirements visually with PlantUML use case diagrams. Model actors, use cases, include/extend relationships, and system boundaries.
Detailed Explanation
Use Case Diagrams for System Requirements
Use case diagrams capture what a system does from the perspective of external actors. They are essential for requirements gathering and stakeholder communication.
Basic Structure
@startuml
left to right direction
actor Customer
actor Admin
actor "Payment Gateway" as PG
rectangle "Online Store" {
usecase "Browse Products" as UC1
usecase "Add to Cart" as UC2
usecase "Checkout" as UC3
usecase "Manage Inventory" as UC4
usecase "View Analytics" as UC5
}
Customer --> UC1
Customer --> UC2
Customer --> UC3
Admin --> UC4
Admin --> UC5
UC3 --> PG
@enduml
Layout Direction
left to right direction arranges actors on the left and the system on the right. The default is top to bottom, which works better for smaller diagrams.
Include and Extend
usecase "Checkout" as UC3
usecase "Apply Coupon" as UC6
usecase "Process Payment" as UC7
usecase "Verify Address" as UC8
UC3 ..> UC7 : <<include>>
UC3 ..> UC8 : <<include>>
UC3 <.. UC6 : <<extend>>
Include: UC3 always requires UC7 and UC8 to complete. The arrow points from the base use case to the included use case.
Extend: UC6 optionally extends UC3. The arrow points from the extension to the base use case.
Actor Generalization
actor User
actor Admin
actor SuperAdmin
User <|-- Admin
Admin <|-- SuperAdmin
Admin inherits all of User's use cases, and SuperAdmin inherits all of Admin's.
System Boundaries
Use rectangle to draw the system boundary. Actors sit outside the boundary (they are external to the system). Use cases sit inside.
Package Grouping
rectangle "E-Commerce Platform" {
package "Shopping" {
usecase "Browse" as B
usecase "Search" as S
}
package "Checkout" {
usecase "Pay" as P
usecase "Ship" as SH
}
}
Packages within the system boundary organize related use cases into logical groups.
Use Case
Gathering requirements during project kickoff meetings, creating system scope documentation for contracts, communicating feature boundaries to stakeholders, and documenting the scope of an MVP for product planning.