Engineering & Quality Checklists

In Plain Language

Checklists are disciplined safety nets that ensure engineering teams never forget a critical test, accessibility rule, or security check during delivery. Rather than relying on human memory during high-pressure releases, checklists define unambiguous, step-by-step criteria for when a story is ready to build, when code is safe to merge, and when a clinical release is legally compliant.

Why Use Quality Checklists in Regulated Software

Complex software systems fail not from a lack of technical knowledge, but from simple oversights under deadline pressure (e.g. unindexed foreign keys, unencrypted log parameters, missing keyboard focus rings). Structured checklists provide five core operational advantages:

1. Error Reduction

Catches predictable defects and compliance regressions that ad-hoc manual reviews regularly miss.

2. Audit Traceability

Structured identifier codes allow specific checklist sign-offs to be cited as formal due-diligence audit evidence.

3. Consistency at Scale

Enables distributed and growing engineering teams to apply the exact same quality bar every sprint.

4. CI/CD Automation

Allows objective criteria (unit tests, SAST scans, contrast checks) to run automatically in CI/CD runners.

Quality Gates & Checklist Stages Across the SDLC

Section 508 Accessible SVG • Interactive Inspector

Checklists are applied at specific, predictable gates in the engineering lifecycle to prevent defective requirements from entering sprints and unverified code from reaching production. Click any lifecycle gate below to inspect its criteria and verification methods.

Checklists across SDLC Lifecycle DiagramLinear sequence of five quality gates: Definition of Ready (Sprint Planning), 508 Accessibility (UI Dev), Security Pre-Flight (Code Review/Build), Definition of Done (PR Merge), and Compliance Gate (Release Gate).GATE 1DoRSprint PlanningBacklog ClarityGATE 2508UI & Component DevWCAG 2.1 AAGATE 3SECCode Review & CISAST & SecretsGATE 4DoDPR Merge GateTests & Peer ApprovalsGATE 5CMPProduction ReleaseDHF & Audit Seal
Selected Gate: User Story Completion & Pull Request Gate

Definition of Done (DoD)

Open Checklist (5 Items)

The Definition of Done is a shared quality checklist that every piece of code must satisfy before a developer can call it "finished". It prevents hidden technical debt by ensuring tests are written, peer reviews are approved, and security scans are clean before merging into the main codebase.

Anti-Pattern Practice:

Developer marks user story "Done" on the Jira board while automated tests are still failing or documentation is postponed to next sprint.

Verified Standard:

Story status only moves to "Done" after CI/CD pipeline confirms 100% green tests, clean security scans, approved peer review, and updated docs.

Checklist Identifier Standard (Structured Traceability)

To enable unambiguous traceability during regulatory audits and in CI/CD pipeline logs, every checklist item in the Deterministic Unified Process carries a structured, machine-readable identifier code formatted as:

CATEGORY-MODULE-00000-00a0-00
Example: SEC_API_00005_00b0_00 (Security Domain • API Module • Item 5 • Revision B)
1. CATEGORY
Domain Namespace

3-letter code: SEC (Security), ACC (Accessibility), CMP (Compliance), DOD (Done), DOR (Ready).

2. MODULE
Target Component

3-4 letter target: API (Backend/REST), UI (Frontend), DB (Database), CI (Pipeline), IAM (Access).

3. 00000
Base Serial Number

5-digit zero-padded incrementing serial identifying the primary requirement.

4. 00a0-00
Sub-item & Revision

Sub-clause version modifier and revision sequence number.

The Five Standard Checklists

Each checklist addresses a dedicated phase in the delivery pipeline. Open any checklist below to inspect full criteria:

User Story Completion & Pull Request Gate5 Items

Definition of Done (DoD)

Guarantees that every user story meets strict engineering, automated testing, security, and documentation standards before being merged.

Explore Checklist Criteria
Sprint Backlog Refinement & Sprint Planning5 Items

Definition of Ready (DoR)

Ensures user stories are sufficiently clear, estimated, and unblocked before developers pull them into an active sprint.

Explore Checklist Criteria
UI Component Development & End-to-End Testing5 Items

Section 508 & WCAG 2.1 AA Accessibility Checklist

Ensures digital interfaces are accessible to users with visual, motor, auditory, or cognitive disabilities per federal standards.

Explore Checklist Criteria
Code Review, Pre-Commit, and CI/CD Build Gates5 Items

Security Pre-Flight & Code Review Checklist

Verifies that software code is immune to OWASP Top 10 vulnerabilities, contains zero exposed secrets, and adheres to defense-in-depth principles.

Explore Checklist Criteria
Pre-Production Release & Formal Audit Gate5 Items

Regulatory Release Gate & Audit Readiness Checklist

Verifies that software releases comply with statutory healthcare, medical device, and financial regulations before commercial deployment.

Explore Checklist Criteria

CI/CD Automation vs. Human Reviewer Judgment

To maintain engineering velocity without sacrificing rigor, checklist items are explicitly partitioned by automation capability:

CI/CD Automatable Gates

Objective assertions evaluated automatically by continuous integration runners on every commit:

  • Automated unit and integration test coverage (>=85% branch coverage)
  • Static Application Security Testing (SAST) & pre-commit secret detection
  • Software Composition Analysis (SCA) dependency vulnerability scans
  • Automated axe-core WCAG 2.1 AA contrast and accessibility audits

Human Reviewer Judgment Gates

Context-heavy evaluations requiring professional engineering and clinical judgment:

  • Architectural fitness, domain modeling clarity, and maintainability
  • Clinical safety hazard evaluations and ISO 14971 risk mitigations
  • User experience intuition and keyboard navigation flow testing
  • Legal Business Associate Agreement (BAA) and vendor trust review
Try This with AI: Automated Pull Request Checklist Verifier

Copy this prompt into your AI coding assistant to create automated CI verification bots for Definition of Done compliance.

You are a Quality Assurance Automation Lead. Author a GitHub Actions workflow that executes on pull_request events to automatically evaluate: 1. 'DOD-ENG-00010-00a0-00': Vitest branch coverage >=85%. 2. 'DOD-SEC-00030-00a0-00': Gitleaks zero detected secrets. 3. 'DOD-ACC-00050-00a0-00': Playwright axe-core zero accessibility violations. Output a structured PR comment summarizing checklist results with pass/fail indicators.

Next in Governance: ISO Compliance Matrix

Trace how every checklist gate maps to specific ISO 13485:2016 and ISO 27001:2022 clauses.

Open ISO Compliance Matrix

Community Discussion & Feedback

Attributed peer feedback and official Netspective architecture notes.

Was this documentation helpful?(100% found this helpful • 0 ratings)

Leave Feedback or Question

○ Loading user info...
0/2000 chars

Discussion (0)

Loading discussion thread...