| name | system-sequence-diagrams |
| description | Creates system sequence diagrams from use-case scenarios. Use when identifying system events, system operations, actor-system boundaries, or operation names before object design. |
System Sequence Diagrams
Overview
A system sequence diagram shows external actors sending events to the system treated as one black-box lifeline. It discovers system operations before internal object collaboration is designed.
When to Use
- A use-case scenario needs precise actor-system event ordering.
- You need system operation names for contracts or controller design.
- Scope boundaries are unclear between UI, external systems, and the application.
- Do not use to show messages among software objects; use
use-case-realization for that.
Workflow
- Choose one scenario. Start with a main success scenario or a significant extension.
- Draw the system as one lifeline. Do not decompose into controllers, services, databases, or UI widgets.
- Identify external actors. Include people and external systems that directly send or receive events.
- Convert steps to system events. Each actor intent that crosses the boundary becomes a message to
:System.
- Name operations by intent. Use operation names such as
enterItem(id, quantity) or makePayment(amount).
- Add parameters from actor-provided data. Include data crossing the boundary, not internal lookup results.
- Show system responses only when meaningful. Include returned information that affects the next actor decision.
- Repeat for important extensions. Model alternate scenarios when they introduce different events or ordering.
Output Template
## SSD: [Use Case] - [Scenario]
Actors:
- [Actor]
System Events:
1. [actor] -> System: [operation(parameters)]
2. System -> [actor]: [response, if relevant]
Discovered System Operations:
- [operation(parameters)]: [intent]
Red Flags
- The diagram contains
Controller, Repository, Database, domain objects, or UI components.
- Message names are physical UI gestures such as
clickSubmit.
- Internal data appears as a parameter even though the actor did not provide it.
- A complex use case has no SSD before contracts or design.
Verification
