CAPM Practice: Determine how to gather requirements

Requirements reviews catch defects before they propagate into design and code. Finding and fixing a requirements error before development is exponentially cheaper than discovering it during testing or production — a fundamental principle of quality management.

**Why not B:** Obtaining management approval for the project to proceed is a governance gate decision, not the purpose of a requirements review. While review results may inform go/no-go decisions, the review itself focuses on inspecting requirements quality to find and fix issues before development begins.

**Why not C:** Assigning each requirement to a specific developer is a work allocation activity done during sprint planning or development planning, not during a requirements review. The review focuses on identifying quality issues in requirements, not on distributing implementation responsibilities.

**Why not D:** Finalizing the project budget based on the number of requirements is a cost estimation activity. Requirements reviews focus on quality inspection to catch ambiguity, incompleteness, and conflicts while changes are still inexpensive, not on deriving budget figures from requirements counts.