Initial public release of the QC checklists (1.0.0), CC BY-SA 4.0

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-01 20:38:48 +08:00
commit b74bdffd83
23 changed files with 1616 additions and 0 deletions
@@ -0,0 +1,52 @@
+# 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