CAPM Practice: Determine how to gather requirements

Requirements should capture what the business needs (outcomes, capabilities), not how to build it (implementation). Prematurely specifying 'how' limits technical creativity and may lead to suboptimal solutions. The solution design is the development team's domain.

**Why not A:** Technical teams do not necessarily prefer "what" focused requirements for simplicity. In fact, some developers prefer detailed "how" specifications. The real reason for documenting "what" is to preserve design freedom and avoid prematurely constraining the solution approach.

**Why not C:** There is no specific PMI certification rule mandating "what" focused documentation. The principle of separating "what" from "how" is a best practice in requirements engineering based on sound reasoning about preserving solution flexibility, not a certification compliance requirement.

**Why not D:** Documenting "how" does not create legal liability. The concern with specifying "how" is that it prematurely constrains the technical team's design options, potentially leading to suboptimal solutions. The issue is about design quality and flexibility, not legal risk.