A requirement is split in two after test cases already link to it — how do you keep both traceability reads intact?

## Why a split is a traceability event, not a rename Requirements do not stand still. One turns out to describe two independent behaviours and is split; two overlapping ones are merged; a criterion is lifted out and promoted. If cases already point at the old shape, the links are now claims about something that no longer exists, and both reading directions become quietly wrong at the same instant. The reason this is worth thinking about in advance is that the two obvious shortcuts fail in opposite directions, and both fail silently. | Shortcut taken at the split | Forward read afterwards | Backward read afterwards | |---|---|---| | Copy every old link to both halves | both halves appear verified, though each case only ever exercised one | every case gains a justification it does not deserve | | Drop the links and start again | both halves appear untested overnight, and real work is repeated | every case loses its justification and becomes a deletion candidate | | Leave the links on the retired identifier | the new halves look unverified; the evidence exists but is unreachable | cases point at something that no longer exists | | Re-point case by case | each half carries the evidence that genuinely applies to it | each case names what it now verifies | ## Doing the split honestly The work is per case, and it is small if it is done at the moment of the split and expensive if it is done a year later. For each case that pointed at the old requirement, read what the case actually asserts and place it: 1. **It verifies one half.** Re-point the link. This is the common case and it is quick. 2. **It genuinely verifies both.** Link it to both, and be honest that it establishes only a slice of each — a case that spans both halves is often a sign the split was along the wrong seam, so it is worth a second look. 3. **It verifies neither cleanly.** The case asserted a behaviour of the old, broader statement that neither half now owns. Either the split is incomplete, or the case is testing something nobody asked for. Both are findings worth surfacing rather than papering over. Then do the same for the criteria: every acceptance criterion of the old requirement must land in exactly one half, or be consciously duplicated. A criterion that lands nowhere is behaviour the split has just dropped on the floor. ## The merge is the mirror image When two requirements become one, the merged requirement's criteria are the **union** of the two sets, and this is where the flattering error lives: the merged item inherits both sets of links and looks extremely well verified. It is not. Each inherited case establishes only the criteria it always established. A merged requirement is verified when every criterion in the union has passing evidence, which is a strictly harder bar than either original faced, not an easier one. The backward read after a merge is easier than after a split — every inherited case still has a justification, it simply points at a broader statement now — but it degrades over time, because the case's stated reason for existing has become vaguer than what the case actually does. ## Keeping history reachable The identifiers are the part teams get wrong most often, because deleting the old one feels like tidying. - **Never reuse a retired identifier for something new.** Old results, defect records and review notes still name it, and a reused identifier makes every one of them silently wrong instead of merely stale. - **Record the supersession.** A stored statement that the old item became these two — or that these two became this one — is what lets a reader from two years ago land somewhere sensible. - **Keep results attached to what they were taken against.** A result belongs to the case and the build it ran on; re-pointing a link must not rewrite what was already observed. - **Do the re-pointing as part of the change.** A split whose links are re-pointed weeks later is the same work done with all the context gone, by someone guessing what the cases were for. ## What good looks like in the interview Say that a split is a change to the links and not only to the wording; name both shortcuts and what each one breaks; describe the per-case re-pointing decision with its three outcomes; and note the merge asymmetry — the union raises the bar rather than lowering it. Then say the part that shows you have lived through it: the case that fits neither half is the most valuable output of the whole exercise, because it is either an incomplete split or a test of something nobody asked for.