In a traceability record linking requirements to test cases and defects, which gap and orphan findings appear, and what does each call for?

## What the analysis is reading A traceability record is a set of links. Each requirement points at the acceptance criteria that make it checkable, each criterion at the test cases meant to verify it, each case at the executions that produced a result, and each defect at the case that found it. Gap and orphan analysis is nothing more than walking that set and reporting the ends that do not join up. It is mechanical and cheap, and its whole value is that **the four ways a link can be missing mean four different things**. Say which end is dangling and you have already said what has to happen next. ## The four findings | Finding | What it says | What it calls for | |---|---|---| | Requirement with no linked case | Something was asked for and nothing verifies it | Write a case, or retire the requirement if it is no longer wanted | | Test case with no linked requirement | A case asserts an expectation nobody has written down | Attach it to the statement it actually serves, or delete it | | Defect with no linked case | A failure was found by a route the suite does not repeat | Add a case that reproduces it and link it to the requirement it violated | | Link whose case has never executed | Intent was recorded; evidence was not produced | Schedule the execution, or read the criterion as unverified until it happens | ### A requirement with no linked case This is the finding most people mean by "gap", and it is the cheapest of the four to act on because the work is obvious: write the missing case. The second legitimate outcome is that nothing should be written at all, because the statement is verified by a means other than a test case — a review, an inspection, a constraint the build enforces. That is a fine answer exactly once: it has to be recorded as the verification method, or the same finding reappears every time the analysis runs and somebody re-argues it. ### A test case with no linked requirement The orphan, in the traceability sense. It is a **question, not a defect**. Two things produce it. The case may encode a real invariant that nobody ever wrote down as a requirement, in which case the repair is on the requirement side: write the statement, link it, and the case becomes defensible. Or the case is residue from a feature that was removed, in which case it should go. The test a reviewer applies is simple: *if this case fails tomorrow, who decides whether that is a bug?* If no one can answer, the case has no requirement behind it and deleting it costs nothing. ### A defect with no linked case An unlinked defect record tells you how the failure was found — by exploration, by an operator, by a customer — and therefore that the suite does not reproduce it. Adding a case turns a one-off finding into standing evidence: the fix becomes confirmable and the failure becomes catchable if it returns. Closing the defect without that step leaves the route unexercised and loses the only moment when somebody knew exactly how to trigger it. ### A link with no execution behind it This is the trap of the four, because link presence and verification look identical in anything built on links. The requirement has a case; the case has never run; the record shows a joined-up chain. The finding is real but it is a **scheduling** problem, not a planning one, and mixing it in with the other three misdirects the work. ## Why one number is not enough Reporting "seventeen gaps" collapses four different pieces of work into one figure that nobody can act on. - The four findings have **different owners**: whoever writes requirements, whoever writes cases, whoever decides what runs. - They have **different costs**. Joining an existing case to an existing requirement is a five-minute edit; writing a case from nothing is a day's work. - One of them is not a planning defect at all. An unexecuted link needs a slot, not a design decision. - A gap and an orphan are frequently **the same underlying fact seen from two ends** — the case exists, the link does not. Match them before you count, or you will report two problems and pay for one twice. A useful report is therefore grouped by finding type, addressed to the person who can close it, and deduplicated across the two directions first. ## What the analysis cannot tell you It reads the record, not the system. A tidy record can sit over a suite whose cases assert almost nothing, and a scruffy one can sit over a well-tested product. The findings are the opening of a conversation with the people who own each requirement — a list of places where the written intent and the written evidence disagree — and not, on their own, a judgement about the state of the release.