Unambiguous
Bad: should be fast → Good: loads within 1.5 s
The learner can evaluate a requirement against testable quality characteristics: unambiguous, verifiable/testable, consistent, feasible, atomic, and traceable.
Six quality characteristics of a well-formed requirement
What separates a good requirement from a bad one
BABOK lists nine quality characteristics of requirements: atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized, and understandable. This lesson drills the five that cause most defects — unambiguous, verifiable (BABOK says 'testable'; ISO/IEC/IEEE 29148 says 'verifiable'), consistent, feasible and atomic — plus traceable, which BABOK handles as a separate requirements-management task and IEEE 830 / ISO 29148 list as a property of a good specification.
Unambiguous means the requirement has exactly one possible interpretation. Bad: 'The system should be fast.' Good: 'The search results page shall load within 1.5 seconds.' Verifiable (testable) means you can design a test that gives a clear pass or fail. If you cannot write a test for it, the requirement is not good enough. Consistent means it does not contradict any other requirement in the same document or the business goals.
Bad vs good: unambiguous, testable, consistent
Testable
Bad: user-friendly UI → Good: admin deactivates a user in 2 clicks
Consistent
No two requirements contradict each other
Lesson notes
What separates a good requirement from a bad one
BABOK lists nine quality characteristics of requirements: atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized, and understandable. This lesson drills the five that cause most defects — unambiguous, verifiable (BABOK says 'testable'; ISO/IEC/IEEE 29148 says 'verifiable'), consistent, feasible and atomic — plus traceable, which BABOK handles as a separate requirements-management task and IEEE 830 / ISO 29148 list as a property of a good specification.
Unambiguous means the requirement has exactly one possible interpretation. Bad: 'The system should be fast.' Good: 'The search results page shall load within 1.5 seconds.' Verifiable (testable) means you can design a test that gives a clear pass or fail. If you cannot write a test for it, the requirement is not good enough. Consistent means it does not contradict any other requirement in the same document or the business goals.
Three more characteristics: feasible, atomic, traceable
Feasible means the requirement can actually be implemented within the project's constraints of time, budget, and technology. A requirement that the system 'shall predict any user's next purchase with 100% accuracy' is not feasible. Atomic means one requirement = one statement. A requirement that says 'The system shall allow users to register and shall send a welcome email and shall verify the email address' is really three requirements bundled together — split them.
Traceable means every requirement can be linked back to a business need and forward to a design, test case, or delivered feature. Traceability is what lets you answer 'Why does this requirement exist?' and 'Is this business need covered?' Atomicity and testability are especially important to get right early, because an untestable or compound requirement causes confusion all the way through delivery.