53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
# Quality Criteria: System Sequence Diagram (SSD)
|
|
|
|
## Metadata
|
|
| Key | Value |
|
|
| --- | --- |
|
|
| ID | QC-SSD-001 |
|
|
| CrossReference | [QC-UC-001], [QC-DM-001], [QC-OC-001] |
|
|
| DomainLanguages | IT Professional English |
|
|
|
|
## Version History
|
|
| Date | Status | Author | Reviewer | Change | Commit |
|
|
| --- | --- | --- | --- | --- | --- |
|
|
| 2026-10-01 | Accepted | Jens Tirsvad Nielsen | S07 | First public release (1.0.0) | — |
|
|
|
|
---
|
|
|
|
## Purpose
|
|
|
|
The System Sequence Diagram illustrates the interaction between an actor and the system as a black box, for one use case scenario. Its quality ensures that the boundary between external actors and internal system behavior is captured accurately before internal design begins.
|
|
|
|
## Quality Criteria Checklist
|
|
|
|
Level: **Mandatory** criteria are the baseline every instance must meet; **Optional** criteria are advanced and may be deferred.
|
|
|
|
| # | Criterion | Level | ISO/IEC 25010 Characteristic(s) | Notes |
|
|
| --- | --- | --- | --- | --- |
|
|
| 1 | Input/output messages match the corresponding Use Case's main success scenario step-for-step | Mandatory | Functional Suitability | The primary purpose of an SSD; deviations must be justified |
|
|
| 2 | Actor and System are treated strictly as black boxes (system shown as `:System`) | Mandatory | Maintainability, Compatibility | No internal object interactions may appear on an SSD |
|
|
| 3 | Object creation/destruction of the System instance handled explicitly where relevant | Optional | Functional Suitability | Applies mainly to session/transaction-scoped interactions |
|
|
| 4 | Return values are shown for operations that produce one, using dashed return arrows | Mandatory | Functional Suitability | Missing return arrows hide important system responses |
|
|
| 5 | Alternate/exceptional flows are represented separately (or explicitly out of scope noted) | Mandatory | Reliability | Prevents conflating happy-path and error-path in a single diagram |
|
|
| 6 | Message names are verb phrases consistent with the use case's system responsibilities | Optional | Usability, Maintainability | Improves traceability to Operation Contracts |
|
|
| 7 | Diagram references the specific Use Case (name and ID) it depicts | Mandatory | Maintainability | Required for backward traceability |
|
|
|
|
## Common Defects
|
|
|
|
- Showing internal objects or classes instead of a single `:System` lifeline
|
|
- Message sequence not matching the use case's main success scenario
|
|
- Missing return values for queries or commands that report a result
|
|
- Mixing multiple use case scenarios into a single SSD without separation
|
|
- No reference to the source Use Case
|
|
|
|
## Traceability Rule
|
|
|
|
- Backward: Must trace to a specific Use Case checklist ([QC-UC-001]) main success scenario and the Domain Model checklist ([QC-DM-001]) concepts used as message parameters/return types
|
|
- Forward: Feeds into the Operation Contract checklist ([QC-OC-001]), one per system operation (message) shown on the SSD
|
|
|
|
---
|
|
|
|
[QC-UC-001]: ./qc-use-case.md
|
|
[QC-DM-001]: ./qc-domain-model.md
|
|
[QC-OC-001]: ./qc-operation-contract.md
|