CAPM Practice: Determine how to gather requirements

Requirements that can't be traced to a business objective may be gold-plating or misaligned scope. Traceability from requirements to business goals ensures the project builds what's truly needed and enables priority decisions based on business impact.

**Why not B:** Consistency with previous project documentation ensures historical alignment but does not confirm alignment with the current project's specific business objectives. Past projects may have had different goals, and repeating prior requirements without validating them against current objectives risks perpetuating misaligned or outdated scope.

**Why not C:** Technical feasibility is an important consideration during solution design, but it is a separate concern from business alignment. A requirement can be technically feasible yet have no connection to the stated business objectives. Confirming feasibility ensures the team can build something — confirming business alignment ensures they are building the right thing.

**Why not D:** Limiting requirements gathering to the highest-ranking stakeholders introduces significant risk of incomplete, biased, or impractical requirements. End users, subject matter experts, and operational staff often possess critical knowledge that executives lack. Business alignment requires understanding objectives at the leadership level, but requirements gathering must be inclusive of all relevant stakeholders.