Files
sqa-qc-checklists/wiki/Description.md
T
Tirsvad 6afa542f26 Keep the wiki pages in wiki/ so they are published from the repository
The 13 pages of the existing wiki (Home, Description, Install and AI Prompt Template in English, Danish and Bahasa Malaysia, and _Sidebar) are exported unchanged, with an empty wiki/.publish (no pruning). Pilot of TirSystem/github-action#59.
2026-10-11 03:09:45 +08:00

2.9 KiB

Description

🌐 English · Dansk · Bahasa Melayu

What a checklist contains

Every qc-<type>.md has the same shape:

Section Content
## Metadata ID (e.g. QC-US-001), CrossReference to related checklists, DomainLanguages
## Version History Date, status, author, reviewer, change
## Purpose Why the artifact type exists and what the checklist protects
## Quality Criteria Checklist The numbered criteria table
## Common Defects The mistakes reviewers actually find
## Traceability Rule What the artifact must trace back to and forward to

The criteria table

# Criterion Level ISO/IEC 25010 Characteristic(s) Notes
2 Written in "As a / I want / So that" form Mandatory Usability
  • Mandatory: the baseline every instance must meet.
  • Optional: advanced; may be deferred, with a reason.
  • ISO/IEC 25010 characteristic: which product-quality characteristic the criterion protects (Functional Suitability, Reliability, Usability, Maintainability, Security, Compatibility, ...). It lets a reviewer see what kind of quality a failed criterion puts at risk, not only that it failed.

IDs and versions

  • A checklist ID is QC- plus the short code of the artifact type it covers: QC-BC-001, QC-UC-001, QC-ERD-001.
  • The version is independent of any reviewed document and increments only when the checklist itself is revised.
  • The qc-language-domain.md checklist (QC-LANG-001) is cross-cutting: it applies in addition to the type's own checklist to every document written in the Product Owner's language.

Traceability

Checklists link to each other. The Traceability Rule of a user-story checklist points back to use case diagram, use case and business case checklists and forward to acceptance tests. A reviewer uses this to check that a document does not float free of the ones it depends on.

A review, step by step

  1. Pick the checklist for the artifact type (plus QC-LANG-001 if the language applies).
  2. For every criterion record Pass, Fail or N-A, with evidence.
  3. Give a verdict: Go, Go-with-conditions or No-Go.
  4. Fix or justify every failed criterion, then re-review the delta.
  5. The reviewer is never the author.

The record format (an RC-* review record) is defined by the framework; outside the framework any table with the same columns works.

Source-code checklists

The qc-programming-* checklists assume your team has written down its coding conventions for the language. They check that code follows them; they do not impose a style of their own.

Licence

CC BY-SA 4.0. Share and adapt, including commercially, if you credit TirSystem and release your adaptation under the same licence.