Requirements-Related Software Failures

Abstract

Purpose: Software failures that reach operation are often traced, after the event, to decisions made while requirements were elicited, written, linked and validated, yet defect records usually describe the symptom rather than that origin. This article asks which classes of requirements defect produce escaped failures, why late detection multiplies their cost, and which lifecycle controls contain them. Method: A critical integrative review of empirical software engineering research, requirements and testing standards, and public investigation findings, synthesised through fault-chain and latent-condition theory and a phase-containment cost model. Findings: Five defect classes (elicitation failure, ambiguity, inconsistency, traceability loss and validation failure) differ in where they are injected, how far they travel before detection and which controls intercept them. Well-documented public failures, including Ariane 5 Flight 501, the Mars Climate Orbiter and the Therac-25 accidents, are dominated by unexamined operating assumptions and validation against the wrong reference rather than by wording defects. Contribution: The Requirements Defect Origin and Containment (RDOC) framework places five containment gates across the lifecycle, defines phase containment, requirements leakage and severity-weighted escape distance as metrics, and states six falsifiable propositions with tests. Implications: Prevention depends on revalidating reused assumptions, auditing trace links whenever requirements change, and feeding blame-free causation analysis of escaped defects back into gate controls.