# The Role of Environmental Assumptions in Shaping Requirements Technical Debt
## 2 Background and Related Work
### Environmental Assumptions  
[PERSON]'s foundational model [22] offers a conceptual distinction between the system to be built, i.e., the _machine_, and its surrounding context, i.e., the _environment_. This model introduces the _problem domain_, which encapsulates real-world entities and behaviors, and the _machine domain_, which refers to the software artifact under development. The key idea is to differentiate between what already exists independently of the system and what needs to be constructed to meet specific goals. Environmental assumptions, in this framework, refer to expected beliefs about the system's operational context, i.e., conditions assumed to hold regardless of the machine's presence. In contrast, the _machine_ refers solely to the software system created to meet these goals.  
The interaction between the _environment_ and the _machine_ occurs through shared observable events or phenomena. Figure 1 illustrates this interplay: Requirements (denoted as \(R\)) and environmental assumptions (\(\mathcal{E}\)) reside in the problem domain, while implementation-specific components, i.e., the program (\(P\)) and the computing infrastructure (\(C\)), reside within the _machine_ domain. The interface between these domains is governed by a specification (\(S\)) that defines how the _machine_ must behave in response to _environmental_ stimuli.  
Requirements specify desired conditions over environmental events and states that the machine must ensure. To fulfill these requirements, the machine must conform to a defined specification (\(S\)). This specification outlines constraints solely over the shared phenomena that form the interface between the _machine_ and the _environment_. The satisfaction of requirements is expressed as follows:  
\[\mathcal{E},S\vdash R \tag{1}\]  
This indicates that, given the _environment_ behaves according to \(\mathcal{E}\) and the _machine_ behaves according to \(S\), then the requirements \(R\) will be satisfied. Figure 1 also illustrates that the program (\(P\)) and the computing platform (\(C\)) belong exclusively to the _machine_ domain. Here, \(P\) represents the software implementation of the specification, while \(C\) refers to the underlying hardware or execution platform. The correctness of the program with respect to the specification is given by [10; 23]:  
\[P,C\vdash S \tag{2}\]  
Environmental assumptions have been a focus of extensive research across areas such as model checking [24; 25; 26; 27; 28], formal modeling of requirements [29; 30; 31], and testing approaches [32; 33]. Recent efforts have emphasized the challenges of managing and validating these assumptions in increasingly dynamic, distributed, and uncertain systems [34]. A significant issue arises when environmental assumptions remain implicit or undocumented, which is a common source of system failures [23; 32; 35]. For instance, [PERSON] et al. [34] propose the concept of environmentally complex requirements, where a single requirement depends on multiple interrelated environmental assumptions. Their work underscores the importance of explicitly addressing these assumptions in development processes that rely more on natural language specifications, iterative design, and empirical testing, rather than purely formal techniques.