CAPM Practice: Validate requirements through product delivery

Acceptance criteria are the testable conditions derived from requirements that define 'done' for a user story or feature. They bridge requirements and testing — the BA or product owner defines them with stakeholder input, and they become the validation standard for each delivered feature.

**Why not B:** Code quality standards — such as test coverage thresholds, linting rules, or performance benchmarks — are defined by engineering teams and belong to the definition of done, not acceptance criteria. Acceptance criteria are derived from stakeholder requirements and specify business-facing behavior, not internal technical quality measures.

**Why not C:** While external auditing bodies may establish compliance frameworks, acceptance criteria for a specific user story or feature are defined internally by the product owner and BA in collaboration with the requesting stakeholders. External standards may inform acceptance criteria but do not replace the requirement-specific, testable conditions that define when a particular feature is complete.

**Why not D:** Commercial acceptability relates to contracts, licensing, or market readiness — not to requirements validation. Acceptance criteria operate at the feature or story level, specifying exactly what conditions must be true for that increment to be considered done by the team and stakeholders, not by a sponsoring organization at a business level.