Why verification status should be computed, and what it costs when it isn't.

The requirement isn't finished when you write it

Every requirement carries an implicit promise: somebody will prove this. The promise is discharged by evidence. Until that happens, a requirement is a statement of intent wearing the costume of a fact.

In most programs the requirement and the evidence live in different places. Requirements sit in DOORS or Jama, and tests live in Excel, a dedicated test management tool, a CI pipeline, a lab notebook, or in the head of an engineer who knows which cases actually matter. The relationship between the two is maintained by hand.

That manual maintenance is where verification fails. The team might run every test, but an undercurrent of mistrust pervades the coverage. The hand-maintained mapping becomes a structural problem representing a snapshot of a moment that has passed, and it degrades from the instant it's written.

What it costs

At best, double entry. At worst, no coverage until a ceremony or audit. Either way, every test exists twice, with no connection between source and record. Two representations which agreed on the day they were synced but go stale and are forgotten until the next ceremony.

Statusing becomes a research project. "What percentage of L2 requirements are verified?" should be a query that returns in a second. Instead, an engineer has to spend three days reconciling two sources that should have been connected in the first place. The number goes stale the day after it's produced, everyone knows it, and that's exactly why it has to be produced again next month.

Impact analysis runs backwards. When a requirement changes, which tests are now invalid? In a hand-maintained world you find out by asking around, and you find out late, or never at all. The second case causes you to ship against evidence that demonstrates a requirement which no longer exists in that form, and nothing in the process was ever going to tell you unless you do the work all over again, every single time.

The audit chain gets reconstructed rather than recorded. When a regulator, a customer, or your own quality organization asks why was this test performed and what does it prove, the honest answer in most programs is that the chain is assembled in a rush, after the fact, using artifacts that weren't built to link to one another. And, to be fair, that process still works. It's expensive, it sucks, and it is absolutely the wrong time to discover traceability issues that might cost 100x to fix after you've deployed 100 aircraft to a customer, but the job gets done and everyone praises the firefighter. Until the next time, when you have to do it all over again. Sitting underneath all of that is a practical complaint. Nobody wants another tool. Every additional system is another integration, license, admin, onboarding, and place for the truth to be partially wrong and silently stale.

Verification status is a computed property

Nobody should ever set a requirement's verification status by hand. It should fall out of the data.

A requirement is verified when a test that claims to verify it has executed against a version of the requirement that matches what has been approved to design against, and produces results that satisfy the criteria defined in the requirement which was frozen before the test.

Look at how many independent conditions that sentence contains. Each is a place where a hand-maintained column in a spreadsheet can be wrong without anyone finding out. None of which are visible when verification status is a dropdown somebody set in March.

There are no requirements, only tests

We only do tests here

No you don't. You write requirements as test cases because you've been burned by the wasted time trying to connect the two together. So instead, you "omit" one of them so they're never apart. What you give up is the ability to determine if the tail is wagging the dog when tests prescribe features that shouldn't have existed in the first place. The irony is, you've written implicit requirements into the tests that have no record of their approval or value to the end customer. You've created the same problem, in the opposite direction.

Staleness is the signal nobody has

Once status is computed, a category of work disappears and a category of signal appears. The most valuable of that signal is staleness: a test that passed, against a version of something that has since changed.

Staleness is invisible to spreadsheets. A failed test announces itself. A stale pass looks identical to a valid pass in every artifact your program produces: the same green cell, the same signed report, the same line in the VCRM. It is the most common mechanism by which verification coverage becomes fiction, and it's undetectable without a system that knows both what the evidence was tied to and what has happened since.

The questions a verification system has to answer

Coverage dashboards are easy to build and mostly decorative. The real measure of whether verification data is doing its job is whether it can answer these live, with no human assembling anything.

Are my requirements still verified? The tense is the whole question. What most trace matrices record is that something was demonstrated at some point. What a program actually needs to know is whether that demonstration still holds against today's requirement text. Did what just rolled off the manufacturing line actually meet the requirements it was designed against?

Is my architecture still verified? Verification obligations don't stop at the requirements layer. Interfaces, allocations, and behaviors carry them too, and a component swap can invalidate evidence at the architecture level well before anyone edits a single requirement. How does that change propagate to the engineers who need to know it before they spend 2 weeks designing the wrong part?

How bad is it, in quantity and in quality? Forty unverified requirements in a subsystem that hasn't begun integration is a schedule fact. Four unverified safety-critical requirements two weeks from a design review is an all hands crisis. A single coverage percentage flattens that distinction, which makes it the least useful number a verification system can produce.

When something is wrong, how does it become work? A finding that doesn't turn into an assignable, trackable, closable action is anxiety-with-a-timestamp. The gap and the response to it belong in the same system.

How does the person executing the test know when to retest? The tester sits downstream of a change they never see. They re-run when someone tells them to, and someone tells them when someone else remembers. The retest signal should automatically come from the same mechanism that detects staleness, and it must reach the person executing the work without a meeting in between.

Definition and execution are different objects

A test definition is a reusable artifact. It states what is being tested, under what conditions, and what constitutes a pass. Written once, it can be reused across variants, across programs, across builds and campaigns. A test execution is a distinct event with its own evidence, operator, date, and configuration under test.

Collapse those into a single object (which is what a spreadsheet row does) and reuse degenerates into copy-paste. Every copy begins to diverge immediately. Pass criteria get quietly relaxed in one lineage and tightened in another. Nobody can say with confidence whether two programs tested the same thing the same way. Keeping definition and execution separate is what makes reuse trustworthy, and it's what turns the answer to "why was this test performed" into a link instead of an essay. But the key is that they must be connected.

There's a second reason to keep pass criteria attached to the definition: it fixes them in time. Criteria written before a campaign are engineering judgment. Criteria interpreted at 2am in the lab, three days behind schedule, are something else, and the difference never shows up in the results file.

What this asks of the discipline

Systems engineering has treated the requirement-to-evidence link as clerical work because it has always had to be. It gets delegated, it gets batched, it gets caught up on before reviews. The tooling reflects that judgment: the link is a text field, a column, an attachment, a naming convention, and the firefighter is always praised in a crisis.

In fact, it is the most load-bearing relationship in all of engineering. Every claim a program makes about its own readiness eventually devolves into a conversation about whether that link is true. A verification program is exactly as sound as the mechanism maintaining it, and for years that mechanism has been a person, a spreadsheet, and a good memory.

Instead of being a firefighter, become the fire marshal. Surface the problems before they have a chance to burn the program, and prove that's why you're still on schedule.

So what do you actually do about it

Stop maintaining the requirement-to-evidence link by hand, and stop buying tools that ask you to. Mapping requirements to the things that verify them is derivable. It has been derivable for a long time, which is the whole reason a person has been able to do it manually all these years.

So pick a system that derives it. One where requirements, architecture, and verification live in the same model instead of in three tools joined by an export. That is the only arrangement in which status is computed rather than declared, and it's the difference between a number you trust and a number you republish every month because nobody trusts the last one.

When you evaluate a tool, the test is short. Can it tell you, right now and without anyone assembling a report, which requirements are verified, which evidence has gone stale, and what work that creates? If the answer starts with "first you export," you're looking at a spreadsheet with a nicer login screen.

That’s exactly why we built test management directly into Trace.Space. Test cases, test runs, executions, requirements, and traceability all live in the same system, so verification stays connected to the engineering work it belongs to. Coverage is always up to date, evidence stays linked to the requirements it verifies, and you don’t need to reconstruct the audit trail when it’s time for a review.