Requirements & Acceptance Criteria Maturity Model

Current maturity score: 0

Chaotic / Undefined
  • Acceptance Criteria and Requirements are used interchangeably.
  • Acceptance Criteria are not numbered, and Requirements are not numbered.
  • There is no shared or complete repository of Requirements.
  • Requirements are not categorized (e.g. Functional, Non-Functional, etc.).
  • Requirements are not uniquely identified.
  • No indication of importance or risk level (High, Medium, Low).
  • Tests are not linked to Requirements.
  • It is unclear which tests cover which Requirements.
Initial Awareness
  • Basic distinction between Acceptance Criteria and Requirements.
  • Some Requirements are documented, but inconsistently.
  • Partial and fragmented storage of Requirements.
  • Limited categorization is attempted but not enforced.
  • Numbering exists in some places, but is not unique or consistent.
  • Importance and risk are occasionally discussed but not recorded.
  • Tests exist, but traceability to Requirements is mostly missing.
Defined but Incomplete
  • Clear conceptual difference between Acceptance Criteria and Requirements.
  • Most Requirements are documented in a shared location.
  • Requirements are grouped into standard types (e.g. Functional, Non-Functional).
  • Unique identifiers exist, but are not always enforced.
  • Importance and risk levels are defined but inconsistently applied.
  • Some tests are linked to Requirements.
  • Coverage is visible, but not complete.
Managed & Traceable
  • Acceptance Criteria and Requirements are clearly separated and consistently used.
  • All Requirements are stored in a shared, complete repository.
  • Requirements are categorized across all standard types.
  • Each Requirement has a unique identifier.
  • Importance and risk levels (High, Medium, Low) are mandatory.
  • Tests are systematically linked to Requirements.
  • Traceability and coverage are transparent.
Optimized & Controlled
  • Requirements and Acceptance Criteria follow strict definitions and governance.
  • A single source of truth exists for all Requirements.
  • Requirements are fully categorized and standardized.
  • Unique identification is enforced automatically.
  • Importance and risk drive prioritization and testing strategy.
  • All tests are explicitly linked to Requirements.
  • Full traceability from Requirement to test results is available.
How to get to section 5? https://softwaretestingbreak.com/ranges2.php