---

name: v-model-requirements-acceptance description: Pairs requirements and issue acceptance criteria with acceptance-level validation. Use when closing the top of the V for a feature or release slice. Third person.

V-model: requirements ↔ acceptance

Links left: requirements (2.x) and well-formed issue-acceptance-criteria with right: acceptance-oriented validation (8.x).

When to use

• Defining or refining an issue so each AC maps to observable evidence.
• Preparing stakeholder demo, UAT, or audit evidence for “what we said we would deliver.”

Instructions

1. Ensure acceptance criteria are testable (copy-pastable steps where possible).
2. For each AC, name the validation method: automated check, scripted test, manual checklist, or monitored metric.
3. Use validation-draft to derive scenarios; refine with validation-detail once behaviour is known.
4. If requirements docs exist (goals, constraints, scope from 2.x), add explicit forward references from AC to those clauses where helpful.

Pitfalls

• Duplicate prose: keep one canonical statement of intent; link instead of copying long specs into both issue and docs.
• Mushy AC: “works well” → replace with measurable or binary checks.

Related

• v-model-mapping
• issue-workflow