Requirements Technical Debt (RTD) refers to the accumulation of issues, compromises, or incomplete decisions related to the requirements phase of a software development project. When requirements are defined, they are often based on assumptions about the operating environment. Industrial experience indicates that it is often easier to miss an environment behavior than to miss a system specification. This is due to the fact that environment assumptions are rarely documented and evolving as developers build the system. In this paper, we looked at RTD through the lens of environment assumptions. Specifically, we examine and identify instances of RTD caused by environment assumptions using an illustrative example of safety requirements from the literature. We then performed a systematic mapping study to identify tools or models that incorporate environment assumptions in the system development. Our findings demonstrate that environment assumptions can act as early indicators of potential issues that may lead to RTD, especially when these assumptions are incomplete or incorrect. From our systematic mapping study, we identify seven models that support effective identification of environment assumptions to mitigate RTD risks. To that end, our study helps fill the gap in the literature by explicitly addressing the role of environment assumptions in the identification of RTD.

Traceability plays an essential role in assuring that software and systems are safe to use. Automated requirements traceability faces the low precision challenge due to a large number of false positives being returned and mingled with the true links. To overcome this challenge, we present a mutation-driven method built on the novel idea of proactively creating many seemingly correct tracing targets (i.e., mutants of a state machine diagram), and then exploiting model checking within process mining to automatically verify whether the safety requirement's properties hold in the mutants. A mutant is killed if its model checking fails; otherwise, it is survived. We leverage the underlying killed-survived distinction, and develop a correlation analysis procedure to identify the traceability links. Experimental evaluation results on two automotive systems with 27 safety requirements show considerable precision improvements compared with the state-of-the-art.

Complementarity between activities reveals that doing any one of them increases the returns to doing the others. In other words, complementarity leads to the synergistic effect that the whole is greater than the sum of its parts. Identifying and exploiting complementarity can benefit many cybernetic activities, where human-machine interactions are inherent and dominant. One such activity is requirements tracing that helps stakeholders to track the status of their goals. Although various kinds of support for human analysts in requirements tracing have been proposed, little is known about the nature of complementarity when different tracing practices are involved. In this paper, we explore the role of complementarity by considering together the tagging-to-trace (T2T) and learning-to-trace (L2T) activities. We present a novel approach to examining which T2T and L2T practices enhance the qualities of each other. Our approach also uncovers the environmental factors which the complementarity is sensitive to. Applying our approach to the logs of 140 analyst-tracing units offers operational insights into the rigorous detection of complementarity and shows the importance of understanding the cybernetic conditions under which the requirements tracing practices may in fact be complementary.

Automated production systems are critical enablers for Industry 4.0 because these design-to-order, custom-built mechatronic systems are not only capable of delivering automation capabilities to satisfy the stakeholder requirements in the manufacturing/production domain, but doing so for a long period of time (e.g., several decades) during which numerous changing needs shall also be accounted for. Although traceability has long been recognized as key to sustain changes, little is known about how the traceability information is managed in place, i.e., in the native environments where the engineering artifacts reside. We contribute in this paper a survey of traceability support within state-of-the-practice tools: seven for programming logic controllers and six for building models in systems modeling language. We draw the similarities and differences from our survey results, and further present a design by leveraging the in-place traceability to better support the development and evolution of automated production systems.