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 several quality characteristics every requirement should satisfy. Six of the most critical are: unambiguous, verifiable (testable), consistent, feasible, atomic, and traceable.
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.
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.
Lesson notes
What separates a good requirement from a bad one
BABOK lists several quality characteristics every requirement should satisfy. Six of the most critical are: unambiguous, verifiable (testable), consistent, feasible, atomic, and traceable.
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.
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.