# The Role of Environmental Assumptions in Shaping Requirements Technical Debt
## 2 Background and Related Work
### Requirements Technical Debt  
Technical debt, a concept introduced by [PERSON] in 1992 [36], describes the long-term costs associated with short-term decisions in software development that prioritize speed over quality [37]. These decisions, e.g., bypassing design rigor or compromising code quality to meet a deadline, result in \"debt\" that must be addressed later to avoid system degradation [3]. Although the term originally referred to issues at the implementation level, it has since been broadened to include other development artifacts such as requirements. Technical debt at the requirements level, like its code-level counterpart, may arise intentionally, when decisions are consciously deferred or simplified, or unintentionally, due to evolving needs or limited expertise [6]. However, RTD differs in its origin, manifestation, and overall impact on the project, particularly because it occurs early in the software lifecycle and can influence foundational design and alignment with stakeholder goals [38]. To illustrate how requirements-related debt compares with implementation-level debt, Table 1 presents a summary of their distinguishing characteristics. For example, technical debt in the requirements phase can be attributed to the fact that requirements are not clear, complete, or well-defined. It usually occurs when teams rush through the planning phase or do not clearly understand the business needs [7]. This debt might also occur because of a lack of alignment between stakeholders and developers or because of delayed decisions  
Figure 1: The _Machine_ and the _Environment_, where \(R\) and \(\mathcal{E}\) are private to the environmental domain, \(P\) and \(C\) are private to the machine domain, and \(S\) resides in the shared phenomena; (adapted from [10; 23]). about important system features. In contrast, technical debt in the implementation phase is directly attributed to code quality, system architecture, or technical decisions during development. This type of debt often comes from taking shortcuts in coding, not refactoring code, insufficient testing, or choosing quick but inefficient solutions [1; 2; 3]. While these types of debt arise at different stages, their long-term consequences can be equally significant. Technical debt at the requirements level often results in fundamental system misalignments. These may include missing features, misinterpretation of business goals, or failure to anticipate future needs. As a result, entire sections of the system may need to be redesigned later. In contrast, technical debt originating in the implementation phase primarily affects code quality and maintainability. It makes the system more prone to bugs and more difficult to scale or extend. Although it may not immediately affect the design of the core system, it often leads to higher maintenance costs and frequent bug fixes. RTD has gained recognition as a unique category within the broader technical debt landscape, though it remains less extensively explored than code-related debt [6; 38]. Initially conceptualized by [PERSON] [4], RTD refers to the discrepancy between the ideal solution to a requirements problem and the solution that is actually implemented. [PERSON] characterizes technical debt in this context as the result of trade-offs developers make when determining which requirements to fulfill. He also introduces a lightweight modeling tool, RE-KOMBINE, which enables comparisons between an existing implementation and alternative solutions, allowing the identification of technical debt as the gap between current implementations and revised requirement sets [4]. Building on this foundation, [PERSON] and [PERSON] [40] propose a classification of RTD into three types: Type 0, Type 1, and Type 2, based on factors such as unfulfilled user needs, indicators of poor requirements quality (i.e., smells), and inconsistencies between requirements and implementation. This taxonomy provides a basis for organizations to detect and address RTD in a structured way. In a broader effort to map the field,