A requirement is only as useful as it is well-written. BABOK defines specific quality criteria that every requirement should meet.
The core set:
- Atomic — each requirement expresses exactly one need. "The user can search, filter, and export" is three requirements.
- Unambiguous — only one interpretation is possible. If two developers read it and picture different things, it's ambiguous.
- Testable — there is a clear way to determine if the requirement is met. "The system shall be fast" is not testable. "The system shall respond within 2 seconds for 95% of requests" is.
- Consistent — no contradiction with other requirements or stated business rules.
- Feasible — achievable within the project's constraints.
- Traceable — linked to a source: a stakeholder need, a regulation, or a business goal.
In agile delivery, acceptance criteria serve the same function. A story without testable acceptance criteria is a low-quality requirement by any standard.
"They must be testable — a clear pass/fail result must be specified. They are written BEFORE work on the task begins." — from User Stories notes on Acceptance Criteria
Writing ACs before development begins is the rule, not the option. I've seen plenty of projects where ACs were written after the fact to "document what was built" — at which point they're not acceptance criteria, they're a changelog.
The most common quality failures I encounter: requirements that sound clear but have hidden ambiguity ("the system shall notify the user" — when? how? about what?), and requirements that are too broad to test meaningfully.
Exam tip: CBAP exam questions often present a requirement and ask which quality characteristic it violates. Ambiguity (multiple valid interpretations) and incompleteness (missing information) are different defects with different fixes.