Sequence Diagram
A diagram showing the order of interactions between components or actors over time, illustrating how messages flow between participants to accomplish a specific scenario or use case.
Purpose
Sequence diagrams make the dynamic behaviour of a system visible, showing exactly how components collaborate to fulfil a request. They are invaluable for understanding complex interactions, identifying performance bottlenecks, and communicating behaviour to developers.
When to Use
Create sequence diagrams for complex interactions involving multiple components, especially where timing, ordering, or error handling is important. Use them during alpha/beta to communicate design intent to developers.
How to Build
Identify the scenario or use case you want to illustrate. Choose a specific, concrete example rather than trying to show all possible paths in one diagram.
List the participants (actors and components) involved in this interaction. Arrange them left to right in the order they are first involved.
Draw the interactions as horizontal arrows between participant lifelines, ordered from top to bottom chronologically. Label each arrow with the message or method call.
Show return values where they add clarity. Include alt/opt/loop fragments for conditional logic, but keep these minimal — separate diagrams for separate scenarios is often clearer.
Annotate with timing constraints or notes where relevant for non-functional requirements.
Tips
- One scenario per diagram — do not try to show all paths in one sequence diagram.
- Show the happy path first, then create separate diagrams for error scenarios.
- Include response/return messages to show what data flows back.
- Use activation bars to show when a component is actively processing.
- Number messages if the sequence is complex and you need to reference specific steps.
Common Mistakes
- Trying to show too many scenarios in one diagram, making it unreadable.
- Omitting return messages, making it unclear what data flows back to the caller.
- Not showing error/exception paths that are critical for implementation.
- Making diagrams too detailed with every method call — focus on significant interactions.
- Not aligning with the actual component names used in the architecture.
Government Context
In UK government, sequence diagrams are useful for demonstrating how security controls operate in practice — showing authentication flows, authorisation checks, and audit logging. They support GDS service assessment evidence by showing how the service handles user journeys technically. For cross-government integrations, they clarify the interaction protocol between departments.