CAPM Practice: Validate requirements through product delivery

Feature rejection triggers a diagnostic question: did developers implement incorrectly (defect), did requirements misrepresent the need (requirements error), or did the need change since requirements were written (scope change)? Each root cause has a different resolution path.

**Why not A:** Feature rejection during acceptance testing does not mean the project has failed entirely. Rejection is a normal part of the validation process that signals the specific feature needs attention. Projects routinely continue after addressing rejected features through defect fixes or requirements clarification.

**Why not C:** Starting the entire feature over from scratch is an extreme and usually unnecessary response to rejection. The appropriate response depends on the root cause of rejection, which may require only minor fixes if it is a defect, or targeted clarification if it is a requirements misunderstanding.

**Why not D:** Marking rejected features as out of scope without investigation ignores the underlying issue. The feature was originally deemed in scope for a reason, and rejection requires diagnostic analysis to determine whether the problem lies in implementation, requirements, or changed needs before deciding next steps.