Why requirements management is not systems engineering

What requirements management actually does

A requirements management tool tracks compliance records. It stores requirements, links them to subsystem allocations, records verification methods, and maintains a coverage matrix. Done well, it tells you whether every requirement has a stated verification approach and a link to a lower-level requirement that addresses it.

This is useful. It is also insufficient.

The problem is that a requirement can be correctly linked, fully approved, and completely disconnected from the current reality of the design, and the tool will not tell you. It tracks what is recorded, not what is true.

The disconnect that compounds quietly

A spacecraft program at detailed design phase. The requirements tool shows full coverage. Every system requirement is linked to subsystem requirements. The compliance matrix is green.

Three months before CDR, the thermal team updates their analysis. The revised results push the operating temperature range for a payload instrument outside the margin specified in a subsystem requirement. The requirement was written eighteen months ago, when the thermal environment was estimated more conservatively.

The team responsible for the instrument did not know the thermal analysis had been updated. The ICD between the thermal subsystem and the instrument had not been revised. The instrument design was not flagged for review.

From the requirements tool's perspective, nothing changed. The requirement was still linked. The verification method was still recorded. The compliance matrix was still green.

The program discovered the conflict at the system-level CDR.

Why the tools reinforce this pattern

Requirements tools were designed for compliance management. Their job is to give a program a defensible record: every requirement has an owner, a verification method, and a link to the design element responsible for satisfying it. That record is necessary. It is what auditors and customers ask for.

But compliance management is a record of intent. It documents what was planned. It does not maintain a live connection between the requirement and the system state it describes.

When the system changes, whether a thermal result shifts, a mass estimate is revised, or a supplier changes a material, the requirements tool does not react. It has no way to. The link it recorded points to a design element, not to a value. Whether the design element still satisfies the requirement is a question the tool cannot answer.

What it costs

Late discovery is the most expensive consequence. Requirements conflicts found in test cost an order of magnitude more to fix than those found in design. The further into the program a conflict propagates before surfacing, the more work has been completed on top of a flawed baseline.

Programs that rely on requirements tools for assurance can also develop a false confidence in their baseline. The tool says compliant. The system has moved. The gap between those two statements is invisible until something forces it into the open.

Verification planning compounds the problem. Test cases are written to requirements. If the requirements do not reflect the current system, the test cases are testing the wrong thing. The verification campaign passes, and the defect is found by the customer.

What the difference looks like in practice

The difference between requirements management and systems engineering is structural, not a matter of tooling.

In a requirements management approach, requirements and design are parallel artifacts linked by records. Keeping them consistent is manual work: someone has to notice that a design change affects a requirement and take action.

In a systems engineering approach, requirements are connected to the model that represents the current system. A change to the design that affects a requirement surfaces that connection as a live signal, not as an action item for someone to remember. The requirement is not just tracked. It is actively maintained against the system state it constrains.

This is what transforms requirements from a compliance exercise into an engineering tool.

The question that reveals the gap

Pick one requirement that was written in the first quarter of your current program.

Ask: does the current design still satisfy this requirement, given every change made since it was written?

Then ask: how confident are you in that answer, and how long did it take to form it?

If the answer required asking several people, checking several documents, and still left some uncertainty, the distance between that answer and "I know because the system tells me" is the distance between requirements management and systems engineering.