CAPM Practice: Determine how to gather requirements

When stakeholders can't articulate requirements verbally, prototyping makes requirements concrete and testable. Stakeholders react to visual or interactive models much more specifically than to abstract questions, enabling iterative requirement refinement.

**Why not B:** Immediately escalating the stakeholder's statement as a project risk is premature and adversarial. The phrase "I'll know it when I see it" signals that the stakeholder has difficulty articulating requirements abstractly, which is common. The appropriate BA response is to use visual elicitation techniques like prototyping or wireframes to help them express their needs concretely.

**Why not C:** Simply asking for written requirements does not address the underlying problem. The stakeholder has already indicated they struggle to define requirements in the abstract. Requesting documentation they cannot produce will frustrate the relationship and fail to yield useful results.

**Why not D:** Documenting the stakeholder's quote and marking the requirement as complete is irresponsible. The BA's role is to elicit and clarify requirements, not to accept vague statements as finished artifacts. This approach would leave the development team without actionable guidance and virtually guarantee rework.