What does a missing requirement-to-case traceability link cost on each side, and why are the two noticed at different moments?
answer
- Two different bills from one absence
- One side looks untested but was tested
- The other side cannot be pruned
- Only one has a forcing event
basics
~20 sOn the requirement side it looks unverified though it was tested, so the work is repeated. On the case side nobody can justify the case, so it is never pruned. Only the first has a forcing moment.
solid answer
~50 sOne absent link damages both reads, but the damage is asymmetric. **Requirement side:** the forward read shows nothing behind something that was, in fact, tested. Somebody re-tests it, or the team argues about evidence on the day it is least affordable, and confidence in the whole record drops — one false hole teaches people the record lies. **Case side:** the backward read shows a case with no stated reason to exist. It is too risky to delete and too unjustified to defend, so it stays, runs forever, and slows the pack. Or someone braver deletes it and takes real protection with it. The timing is the point. The requirement-side cost lands at a scheduled, noisy moment, so it gets fixed. The case-side cost has no such moment; it accrues quietly for years, which is why it is usually the larger of the two.
code
pseudocode · 16 lines-- the same absent link, read from each end
forward_side(requirement):
if no linked cases:
cost = { repeated_testing, argument_at_release, record_loses_authority }
surfaces_at = "the next release decision" -- loud, scheduled, gets fixed
backward_side(case):
if no linked requirement:
cost = { cannot_retire, cannot_diagnose_its_failures, slower_feedback }
surfaces_at = "nothing on the calendar" -- quiet, compounding
repair(requirement, case):
-- one link often settles both bills at once
if read_assertions(case) satisfies some criterion of requirement:
link(requirement, criterion, case)go deeper
Be ready to say that a missing link hurts in two directions at once: something that was tested can look untested, and a case that matters can look pointless.
Explain the two concrete costs — repeated testing and an argument about evidence on one side, an unprunable case on the other — and why finding the existing case beats writing a new one.
Demonstrate the timing argument: one side has a scheduled forcing event so it gets fixed, the other has none so it compounds silently. Say how you would deliberately create a forcing event for the quiet side.
Own the consequence at organisational scale: how repeated false holes destroy the record's authority, what an unprunable suite eventually costs in feedback time, and how you would fund the side nobody is blocked by.
## One absent link, two different bills A link is a single small record, so it is tempting to treat its absence as an administrative untidiness. It is not: the same missing link produces two distinct costs, paid by different people at different times, and only one of them ever announces itself. The asymmetry is worth understanding precisely, because it explains a pattern almost every long-lived team has: the release picture is broadly trustworthy, and the test suite is full of cases nobody can explain. ## The requirement side: a false hole Read forward, the requirement shows no evidence. The behaviour may well have been thoroughly tested — by a case that was written against a different requirement, or during exploratory work whose findings were never linked back — but the read cannot see that. The costs are concrete: - **Repeated work.** Somebody tests it again, because that is the rational response to a hole in the evidence. - **An argument at the worst moment.** The gap surfaces during a release conversation, when the person who knows it was tested is trying to remember which case did it, and the room has to decide whether to trust a memory. - **Erosion of the record's authority.** This is the expensive one. A single false hole is cheap; a handful teaches everyone that the record under-reports, and from then on every genuine hole is discounted too. A record people argue with is worse than no record, because it costs upkeep and buys nothing. ## The case side: a case nobody can justify Read backward, the case has no stated reason to exist. It probably does have a reason — it was written for a defect, or for a requirement that has since been reworded — but the reason lives in somebody's memory or in nobody's. - **It cannot be retired.** Deleting it means accepting an unknown risk, so a careful engineer leaves it. Multiply that by years and the pack is full of cases that are individually undeletable and collectively expensive. - **It cannot be maintained well either.** When it fails, nobody can say what it was protecting, so the cheapest resolution is to adjust the case until it passes — which converts a real check into a decoration. - **Or it is deleted, and takes real protection with it.** The braver move sometimes removes the only thing standing between a rare data path and production. ## Why the two are noticed at different moments | | Requirement side | Case side | |---|---|---| | What the read shows | something asked for with no evidence | a case with no stated justification | | Who feels it | whoever must answer are we done | whoever owns the suite runtime and upkeep | | When it surfaces | at a scheduled, noisy decision point | at no scheduled moment at all | | Typical response | re-test it, or argue about memory | leave it alone, indefinitely | | How the cost accrues | in a visible spike, then it gets fixed | quietly, compounding for years | | Usual end state | corrected, because it was loud | never corrected, because nobody is blocked | The mechanism is simply that one side has a forcing event and the other does not. Releases happen on dates and someone is accountable for the answer, so forward-side gaps get found and closed. Nothing on the calendar ever asks why this case exists. No one is blocked by an unjustifiable case; the suite just gets slower, and slowness is absorbed rather than escalated until the feedback loop is long enough that people route around it. That is why the case-side cost is usually the larger of the two even though the requirement-side cost is the one that gets discussed. ## Acting on the asymmetry - **Do not wait for the loud moment.** Read forward over a requirement while it is being built, when the person who knows what tested it is still in the conversation. The cheapest moment to repair a link is the moment the knowledge is still in someone's head. - **Give the quiet side a forcing event of its own.** Because nothing naturally prompts it, the backward read only happens if it is deliberately scheduled — most usefully when the suite's runtime, not its correctness, becomes the complaint. - **Re-point before you delete.** A case with no justification is a case whose justification is undiscovered. Read what it asserts, find what that behaviour belongs to, and link it. Retire it only when you can say what is being given up. - **Repair the requirement side by finding the case, not by writing a new one.** The default reflex is to author a fresh case, which pays for the same coverage twice and leaves the unlinked case still unjustifiable — one missing link quietly generating both costs at once.
- Why is a repeatedly false hole on the requirement side worse than an occasional one?Because it retrains the reader. One false hole costs a round of re-testing. A pattern of them teaches everyone that the record under-reports, so genuine holes get discounted along with the false ones and the record stops changing anyone's decision. At that point the team is paying the upkeep of traceability and receiving none of its benefit, which is strictly worse than not keeping it.
- A slow case has no linked requirement. What do you do before proposing to delete it?Read what it actually asserts and try to place that behaviour against something the product promises. Very often it belongs to a requirement that was reworded, or it guards a defect that was fixed years ago — either way, link it and the deletion question answers itself. Retire it only when you can state in one sentence what protection is being given up, and record that sentence.
An uninsured claim gets noticed the day you try to claim; an insurance policy on something you no longer own gets noticed never, and quietly bills you every month.
saying these in an interview costs you the question
- Assumes an unlinked requirement was simply never tested
- Treats a missing link as a documentation problem with no cost
- Says both sides surface at the same moment
- Repairs the gap by authoring a duplicate case instead of finding the existing one
- Deletes an unjustifiable case without reading what it asserts