What columns does a requirements traceability record need, and what does each answer?

juniormust knowfreq 46%

answer

One row per verifiable statement
Two kinds of column, different origins
Some values already exist elsewhere
A verdict means little without its build

basics

~20 s

One row per requirement unit, carrying its identifier and text, the cases that verify it, the latest execution verdict, the build it ran against, and any linked defects. Every column answers one question about that statement's verification.

solid answer

~50 s

A traceability record is a table with one row per verifiable statement, usually an acceptance criterion rather than a whole feature. Its columns split into two kinds. Authored columns are written once because the fact has no other home: the requirement identifier, the criterion identifier and text, and who accepts it. Derived columns are answers pulled from work that already happened: which test cases reference the criterion, at what level, what each last did, the build under test, and the defects raised against it. Keep the second kind derived rather than typed, because a retyped value is a second copy of a fact the work already stores. A quick check on any proposed column: name the reader who asks a question only that column answers, and name where its value comes from. If either has no answer, drop the column.

A traceability record is a table with **one row per verifiable statement**, usually an acceptance criterion rather than a whole feature. Its columns split into two kinds. **Authored columns** are written once because the fact has no other home: the requirement identifier, the criterion identifier and text, and who accepts it. **Derived columns** are answers pulled from work that already happened: which test cases reference the criterion, at what level, what each last did, the build under test, and the defects raised against it. Keep the second kind derived rather than typed, because a retyped value is a second copy of a fact the work already stores. A quick check on any proposed column: name the reader who asks a question only that column answers, and name where its value comes from. If either has no answer, drop the column.

code

pseudocode · 11 lines

pseudocode

TRACE_ROW:
  requirementId    <- authored once, stable for life
  criterionId      <- authored once, stable for life
  criterionText    <- authored: one testable sentence
  acceptor         <- authored: who decides it is met

  verifyingCases   <- derived: cases naming criterionId
  checkLevel       <- derived: level of each such case
  latestVerdict    <- derived: newest result per case
  buildUnderTest   <- derived: build that produced it
  linkedDefects    <- derived: defects naming criterionId

go deeper

for a junior

Be ready to name the columns without prompting: requirement and criterion identifiers, the criterion text, the checks that verify it, the latest verdict, the build tested, and linked defects. Say what question each one answers.

for a middle

Explain the split between authored and derived columns, and why a value that already exists in the work should be read from there rather than retyped. Be ready to justify linking by identifier instead of by title.

for a senior

Show a row shape that survives real projects: several verifying checks per statement, a verdict that names its build, an acceptor, and no column that nobody computes or reads. Say which columns you would refuse.

for a principal

Own the argument for the smallest column set that still answers what your delivery actually asks, and be ready to say what a rejected column would have cost in recurring manual upkeep against what it would have bought.

The unit a row describes

Fix what one row is before arguing about columns. A traceability record holds one row per verifiable statement, and in most products that statement is an acceptance criterion rather than a whole feature. A row whose subject is "Checkout" can never carry a result, because something that large is never simply satisfied or not; a row whose subject is "an order above the free-delivery threshold shows no delivery charge" can. Every column is an attribute of that one statement, so choosing the unit badly makes half the columns meaningless before anyone fills them.

Two kinds of column

Columns divide sharply by where their value comes from, and that division matters more than the exact list.

Authored columns are written once by a person because the fact has no other home. Derived columns are answers to a question about work that already happened somewhere else: a case file, an execution result, a defect record. A derived value that somebody retypes into the record is a second copy of a fact, and two copies of one fact can disagree.

Column	Kind	The question it answers
Requirement identifier	authored	Which requirement does this statement belong to?
Criterion identifier	authored	How does anything else refer to this statement?
Criterion text	authored	What exactly was promised, in one testable sentence?
Acceptor	authored	Who decides the promise is met?
Verifying cases	derived	Which checks name this criterion?
Check level	derived	At what level is it checked: unit, interface, end to end, manual?
Latest verdict per case	derived	What happened the last time each one ran?
Build under test	derived	Which version does that verdict describe?
Linked defects	derived	What is known to be broken against this statement?

What each column is actually for

The criterion text is what makes the record readable by someone who was not in the room. An identifier alone forces every reader to open a second document to learn anything.
The verifying-cases column holds a list, not a single value. One criterion is commonly checked at more than one level, and collapsing that to "verified: yes" throws away exactly the part a reader needs when one of those checks starts failing.
The verdict column is close to worthless without the build column beside it. A pass is a claim about one version of the code; unversioned, it says only that the criterion passed once, at some point, against something.
The defect column connects a promise to the evidence that it is currently broken. It is the column nobody reconstructs from memory later.
The acceptor column is the cheapest to fill and the most often missing. Without it a disputed row has no addressee, and disputed rows are the only rows anyone argues about.

Identifiers, not names

Every column that points somewhere points by identifier, never by title. Titles get edited: a criterion renamed from "free delivery over the threshold" to "free delivery at or above the threshold" silently breaks every link that was made by name, and nothing announces it. Stable identifiers assigned when the requirement is written are what make derivation possible at all, so the reference discipline underneath the record sets the ceiling on how good the record can be.

Columns that look useful and are not

Percentage complete. Nothing computes it, so it becomes a mood. Two figures a machine can produce, how many criteria have at least one passing check on the current build and how many have none, say more and cost nothing to keep.
A free-text status column parallel to the verdict. It exists so somebody can write "mostly working", which is precisely the claim the record was meant to replace.
A priority copied across from the requirement. A copied value ages independently of its source; point at the requirement instead of duplicating its fields.
"Tested: yes/no" with no build and no case list. It answers a question nobody actually asks.

A test for any proposed column

Before adding a column, answer two questions in one sentence each: which reader asks something that only this column answers, and where does its value come from. If the first has no answer, the column is decoration. If the second answer is "somebody types it in" while the fact already exists elsewhere, the column is a copy that will disagree with its original. Eight columns that survive both questions beat twenty that do not, because every hand-filled column is a recurring tax charged against work the team has already done once.

## The unit a row describes Fix what one row is before arguing about columns. A traceability record holds **one row per verifiable statement**, and in most products that statement is an acceptance criterion rather than a whole feature. A row whose subject is "Checkout" can never carry a result, because something that large is never simply satisfied or not; a row whose subject is "an order above the free-delivery threshold shows no delivery charge" can. Every column is an attribute of that one statement, so choosing the unit badly makes half the columns meaningless before anyone fills them. ## Two kinds of column Columns divide sharply by where their value comes from, and that division matters more than the exact list. **Authored columns** are written once by a person because the fact has no other home. **Derived columns** are answers to a question about work that already happened somewhere else: a case file, an execution result, a defect record. A derived value that somebody retypes into the record is a second copy of a fact, and two copies of one fact can disagree. | Column | Kind | The question it answers | |---|---|---| | Requirement identifier | authored | Which requirement does this statement belong to? | | Criterion identifier | authored | How does anything else refer to this statement? | | Criterion text | authored | What exactly was promised, in one testable sentence? | | Acceptor | authored | Who decides the promise is met? | | Verifying cases | derived | Which checks name this criterion? | | Check level | derived | At what level is it checked: unit, interface, end to end, manual? | | Latest verdict per case | derived | What happened the last time each one ran? | | Build under test | derived | Which version does that verdict describe? | | Linked defects | derived | What is known to be broken against this statement? | ## What each column is actually for - **The criterion text** is what makes the record readable by someone who was not in the room. An identifier alone forces every reader to open a second document to learn anything. - **The verifying-cases column** holds a list, not a single value. One criterion is commonly checked at more than one level, and collapsing that to "verified: yes" throws away exactly the part a reader needs when one of those checks starts failing. - **The verdict column** is close to worthless without the **build column** beside it. A pass is a claim about one version of the code; unversioned, it says only that the criterion passed once, at some point, against something. - **The defect column** connects a promise to the evidence that it is currently broken. It is the column nobody reconstructs from memory later. - **The acceptor column** is the cheapest to fill and the most often missing. Without it a disputed row has no addressee, and disputed rows are the only rows anyone argues about. ## Identifiers, not names Every column that points somewhere points by **identifier**, never by title. Titles get edited: a criterion renamed from "free delivery over the threshold" to "free delivery at or above the threshold" silently breaks every link that was made by name, and nothing announces it. Stable identifiers assigned when the requirement is written are what make derivation possible at all, so the reference discipline underneath the record sets the ceiling on how good the record can be. ## Columns that look useful and are not 1. **Percentage complete.** Nothing computes it, so it becomes a mood. Two figures a machine can produce, how many criteria have at least one passing check on the current build and how many have none, say more and cost nothing to keep. 2. **A free-text status column** parallel to the verdict. It exists so somebody can write "mostly working", which is precisely the claim the record was meant to replace. 3. **A priority copied across from the requirement.** A copied value ages independently of its source; point at the requirement instead of duplicating its fields. 4. **"Tested: yes/no"** with no build and no case list. It answers a question nobody actually asks. ## A test for any proposed column Before adding a column, answer two questions in one sentence each: *which reader asks something that only this column answers*, and *where does its value come from*. If the first has no answer, the column is decoration. If the second answer is "somebody types it in" while the fact already exists elsewhere, the column is a copy that will disagree with its original. Eight columns that survive both questions beat twenty that do not, because every hand-filled column is a recurring tax charged against work the team has already done once.

Which of those columns should never be typed in by hand, and why?
Every derived column: the verifying cases, the verdict, the build under test and the linked defects. Each of those facts already exists where the work happened, so writing it into a second place creates a copy that can disagree with its source and gives no warning when it does. Authored columns are only the ones with no other home, such as the criterion text and its acceptor.
Why does a recorded verdict mean less without the build it ran against?
A verdict is a claim about one version of the code, not about the requirement forever. Without the build identifier a reader cannot tell whether the pass describes what is about to ship or something from three weeks and forty changes ago. The row then says only that the criterion passed once, which is not the question anyone brought to the record.

Treat it as a receipt rather than a plan: each line names one thing promised and what happened to it, and a line nobody can price does not belong on a receipt.

saying these in an interview costs you the question

Uses one row per feature instead of per verifiable statement
Types the latest verdict into the record by hand
Adds a percentage-complete column that nothing computes
Records that a case exists but never its outcome
Omits which build produced the recorded verdict
Links by title rather than by stable identifier

What columns does a requirements traceability record need, and what does each answer?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The unit a row describes

Two kinds of column

What each column is actually for

Identifiers, not names

Columns that look useful and are not

A test for any proposed column

▾common follow-ups2 questions

▾analogy~10 s

▾red flags6 flags

The unit a row describes

Two kinds of column

What each column is actually for

Identifiers, not names

Columns that look useful and are not

A test for any proposed column

answer

go deeper