Requirements, traceability and acceptance tests

45 min
0/4 practice checks

Requirements, traceability and acceptance tests

A requirement becomes testable when it describes observable behaviour and conditions. “The system should be easy to use” is too vague until it becomes something that can be checked, such as “a learner can resume the last lesson with keyboard-only navigation”. Acceptance criteria define the evidence a stakeholder will use to decide whether the work meets the need.

Traceability links a requirement to design, code, tests and results. This makes change safer: if the requirement changes, the team can find what must be reviewed. It also prevents a test suite from becoming a random list of inputs that nobody can explain. A clear identifier and short rationale are often enough for a small project.

Worked reasoning. Requirement R12 says a learner may export their progress. Acceptance criteria specify that the export contains the learner’s own course progress, is downloadable in a clear format and does not expose another learner’s records. Tests trace from R12 to the export service, permission check and a sample output.

Exam lens. Write criteria in a form someone can observe or test. Then state which component and test provide evidence for each one.

Which statement is the most defensible principle for Requirements, traceability and acceptance tests?

Enter the key term for Requirements, traceability and acceptance tests. What observable condition tells a user that a requirement has been met?

“Users can reset a password” is a requirement. Which sentence is a better acceptance criterion?

Name the concise safeguard or principle that completes this lesson’s scenario: “Users can reset a password” is a requirement. Which sentence is a better acceptance criterion?