# The Role of Environmental Assumptions in Shaping Requirements Technical Debt
## 1 Introduction  
Technical debt refers to the long-term consequences of making quick decisions during software development that prioritize short-term goals, such as fast delivery or tight deadlines, over long-term system quality and maintainability [1]. While these decisions may yield immediate benefits, they often incur \"interest\" in the form of maintenance overhead, quality degradation, or missed opportunities for architectural improvement [2, 3]. Historically, research in technical debt has concentrated on its manifestations in code quality, testing, and architecture [4]. More recently, however, there has been a growing awareness that technical debt can originate earlier in the development process, particularly during the requirements engineering phase [2, 4, 5, 6, 7, 8]. In real-world settings, teams can postpone or make approximate decisions on requirements in order to satisfy scheduling pressures or defer premature commitments in the presence of uncertainty. While such decisions may appear rational or even necessary, they often defer critical clarity and completeness, which must eventually be reconciled. This creates what is now known as requirements technical debt (RTD). [PERSON] [4] describes RTD as the gap between the ideal solution to a requirements problem and the solution that is actually implemented within a particular decision-making context. That \"distance\" can accumulate through vague requirements or the deferral of necessary but complex decisions. Moreover, failure to track requirement changes systematically over time can make it difficult to identify when and how debt has accumulated, as it often only becomes apparent when the system encounters failures or requires extensive revisions. A major source of RTD stems from environmental assumptions [9], which can be defined as the implicit or explicit beliefs developers hold about the system's operating context [10]. These assumptions may concern hardware limitations, sensor fidelity, communication latency, environmental variability (e.g., wind, temperature), user interaction models, or system interoperability. [PERSON] et al. [11] note that many of these assumptions are embedded in requirements artifacts, which makes their early identification and management crucial. Yet in most real-world projects, assumptions are rarely treated as first-class citizens. They may be informally discussed, remain undocumented, or evolve alongside development without clear documentation or linkage to requirements. This creates significant risks. Developers may proceed under outdated or inaccurate assumptions that later undermine the correctness or applicability of the system behavior. [PERSON]'s foundational distinction between the _machine_ and the _environment_[10] offers a rigorous basis for reasoning about system behavior in context. In this model, the _machine_ denotes the software system under construction, while the _environment_ denotes the external conditions and entities with which the system interacts. Environmental assumptions, in this view, are propositions taken to be true about the real world, independently of whether the system is ever realized. If these assumptions are inaccurate, change over time, or remain unverified, then even a system that is correctly implemented according to its specification may fail to operate as intended in its deployed setting. Misunderstanding or neglecting environmental assumptions has historically led to costly failures. A well-known case is the Ariane 5 rocket failure [12], where assumptions from Ariane 4 about velocity thresholds were reused without validation. This led to an unhandled overflow and ultimately mission failure [13]. Such examples underscore how environmental mismatches can directly lead to technical debt by forcing costly redesigns or causing systems to fail once deployed in contexts that do not match design-time assumptions.