Requirements Completeness Audit
Definition
Confirm that the product does what it must do for production. Treat requirements as user journeys plus observable acceptance conditions, not just ticket text.
Questions To Ask
- What journeys are must-have for this release?
- Which acceptance conditions define success for each journey?
- Which roles, permissions, states, and failure paths must be included?
- What requirements are explicitly out of scope?
- What proof shows each condition works?
Existing Project Comparison
- Compare
FEATURE_MAP.md, FEATURE_DESIGN.md, tickets, docs, tests, and current behavior.
- Trace each must-have journey to code, test evidence, and manual or automated verification.
- Mark unknown, ambiguous, or untested requirements as readiness risks.
Suggestive Plan
- List all must-have journeys and acceptance conditions.
- Map each condition to evidence.
- Run or inspect verification for missing evidence.
- Classify gaps as blocker, accepted risk, or out of scope.
- Update
PRODUCTION_READINESS.md.
Example
For invoicing, confirm create invoice, edit draft, approve, send, pay, void, and export journeys work for every required role.
Vocabulary
- Must-have journey: user path required for production launch.
- Acceptance condition: observable proof that a journey works.
- Traceability: link from requirement to implementation and evidence.
- Scope boundary: explicit line between included and excluded behavior.
Expected Outcome
Produce a requirements audit showing every must-have journey, its acceptance evidence, gaps, blockers, accepted risks, and open questions.
1---2name: requirements-completeness-audit3description: Audit production requirements completeness for a release, feature set, or system. Use when confirming every must-have user journey, acceptance condition, non-goal boundary, and documented requirement works before production readiness.4---56# Requirements Completeness Audit78## Definition910Confirm that the product does what it must do for production. Treat requirements as user journeys plus observable acceptance conditions, not just ticket text.1112## Questions To Ask1314- What journeys are must-have for this release?15- Which acceptance conditions define success for each journey?16- Which roles, permissions, states, and failure paths must be included?17- What requirements are explicitly out of scope?18- What proof shows each condition works?1920## Existing Project Comparison2122- Compare `FEATURE_MAP.md`, `FEATURE_DESIGN.md`, tickets, docs, tests, and current behavior.23- Trace each must-have journey to code, test evidence, and manual or automated verification.24- Mark unknown, ambiguous, or untested requirements as readiness risks.2526## Suggestive Plan27281. List all must-have journeys and acceptance conditions.292. Map each condition to evidence.303. Run or inspect verification for missing evidence.314. Classify gaps as blocker, accepted risk, or out of scope.325. Update `PRODUCTION_READINESS.md`.3334## Example3536For invoicing, confirm create invoice, edit draft, approve, send, pay, void, and export journeys work for every required role.3738## Vocabulary3940- Must-have journey: user path required for production launch.41- Acceptance condition: observable proof that a journey works.42- Traceability: link from requirement to implementation and evidence.43- Scope boundary: explicit line between included and excluded behavior.4445## Expected Outcome4647Produce a requirements audit showing every must-have journey, its acceptance evidence, gaps, blockers, accepted risks, and open questions.
harsh817