CAPM Practice: Determine how to gather requirements

Testable requirements are specific and measurable — they define the exact condition that must be true. 'The system must be fast' is not testable. 'The system must respond to search queries within 2 seconds for 95% of requests under peak load' is testable.

**Why not A:** The number of stakeholders who reviewed a requirement speaks to how thoroughly it was validated through stakeholder engagement, but it has no bearing on whether the requirement is testable. A requirement reviewed by ten stakeholders can still be vague and untestable, while a requirement written by one person can be precise and fully testable.

**Why not C:** Whether a requirement can be completed in a single sprint is a sizing or scoping consideration for development planning, not a quality attribute of the requirement itself. Large requirements can be split into smaller implementable pieces while remaining testable, and a small requirement can still be vague and impossible to test objectively.

**Why not D:** Technical language in a requirement addresses whether developers can understand how to implement it, but technical phrasing alone does not make a requirement testable. A requirement must define a measurable condition or expected outcome — without a clear pass/fail criterion, even technically worded requirements cannot be objectively verified.