Requirement
// Definition
A documented condition or capability a system must satisfy — functional (what it does) or non-functional (how well it does it). Requirements are the source material for test case design: every requirement with no linked test case is a coverage gap, and a requirements traceability matrix makes those gaps explicit.
// Related terms
Requirements Traceability
The ability to link every requirement to the test cases that verify it, and trace every test case back to the requirement it covers. A requirements traceability matrix (RTM) makes gaps explicit: a requirement with no linked test case is a coverage hole; a test case with no requirement link is an orphan that may be testing undocumented behaviour. RTMs are a common audit artefact in regulated industries.
Test Case
A single, executable specification: preconditions, steps, expected result, and pass/fail criteria for one verification.
Test Coverage
A measure of which parts of the requirements or features have been exercised by tests. Distinct from code coverage — focuses on the spec, not the source.
Acceptance criteria
Acceptance criteria are the conditions a feature must meet for a PM to sign it off as done. They define the boundaries of a user story: what the system will do, what it won't, and which edge cases matter. Well-written criteria are specific enough to test ("the export produces a valid CSV within 3 seconds for up to 10,000 rows") but not so prescriptive they dictate implementation. They are not test cases — they are the precondition for writing test cases. QA engineers write acceptance criteria implicitly every time they design a test suite; the PM transition requires writing them explicitly, before code exists, as a negotiated contract between PM, engineering, and QA. The common failure is covering only the happy path — experienced testers instinctively reach for edge cases, which is exactly the right instinct to carry forward.