The Difference Between “Working Software” and “Correct Systems”

The Difference Between “Working Software” and “Correct Systems”

Working software is not the same thing as a correct system. Software can execute successfully, pass its own tests, and still be wrong in the only sense that matters: it does not align with the intended system behavior, operational need, or stakeholder expectation.

This distinction is easy to forget because implementation success is visible. If the feature runs and the test passes, the team feels done. But what has been proven at that point may be only that the software is consistent with its own assumptions, not that it is correct against the real system definition.

Implementation proves realization, not always correctness

Software can work exactly as coded while still violating the intended use case, system constraint, or requirement rationale behind the feature. That is especially common when requirements were ambiguous and tests were built around local interpretation rather than stable intent.

Correctness depends on alignment across the chain

To claim a correct system, teams need stronger alignment between stakeholder need, requirement, implementation, and proof. If any one of those layers drifts, “working” becomes a dangerously weak success criterion.

NASA’s requirements management process explicitly ties requirements to design documents and test plans and procedures through bidirectional traceability.

NASA Systems Engineering Handbook, Requirements Management Process

That is exactly because correctness is not contained inside the software artifact alone. It is established through alignment across the engineering chain.

Final thought

Working software proves that implementation exists. Correct systems prove that implementation, intent, and evidence still match.

If the project cannot show that chain clearly, then “it works” may only mean “it works according to the wrong definition.”

References

• NASA Systems Engineering Handbook: Crosscutting Technical Management