Abstract Requirements Technical Debt (RTD) applies the Technical Debt (TD) metaphor to capture the consequences of sub-optimal decisions made concerning Requirements. Understanding the quantification of RTD is key to its management. To facilitate this understanding, we developed a conceptual model, the Requirements Technical Debt Quantification Model (RTDQM). Our work is grounded in the literature found via a systematic mapping study and informed by prior work modeling the quantification of software code-related TD types. The key finding is that although RTD is similar to code-related TD in many aspects, it also has its own components. RTD can be incurred regardless of the presence of code-related TD. Unlike code-related TD, RTD has a feedback loop involving the user. RTD can have a cascading impact on other development activities, such as design and implementation, apart from the extra costs and efforts incurred during requirements engineering activities; this is modeled by the RTD Interest constituents in our model. The model was used to compare and analyze existing quantification approaches. It helped identify what RTD quantification concepts are discussed in the existing approaches and what concepts are supported by metrics for their quantification. The model serves as a reference for practitioners to select existing or to develop new quantification approaches to support informed decision-making for RTD management.

To effectively manage Technical Debt (TD), we need reliable means to quantify it. We conducted a Systematic Mapping Study (SMS) where we identified 39 quantification approaches for Code, Design, and Architecture TD. We analyzed concepts and metrics discussed in these quantification approaches by classifying the quantification approaches based on a set of abstract TD Quantification (TDQ) concepts and their high-level themes, process/time, cost, benefit, probability, and priority, which we developed during our SMS. This helped identify gaps in the literature and to propose future research directions. Among the abstract TDQ concepts discussed in the different quantification approaches, TD item, TD remediation cost, TD interest, and Benefit of remediating TD were the most frequently discussed concepts. They were also supported by some form of measurement. However, some TDQ concepts were poorly examined, for example, the benefit of taking TD. It was evident that cost concepts were more frequently quantified among the approaches, while benefit concepts were not. Most of the approaches focused on remediating TD in retrospect rather than quantifying TD to strategically use it during software development. This raises the question of whether existing approaches reliably quantify TD and suggests the need to further explore TDQ.

Making sub-optimal design decisions during software development leads to the accumulation of Technical Debt (TD) in software projects. There are tools to identify TD Items in software code through static code analysis. However, quantifying TD to support decision-making on whether to keep taking on TD or if it is time to refactor TD is a difficult task, and proposed approaches for this still lack consensus. Prior work observed that TD Interest could be further decomposed into constituents ‘New Code Cost’ and ‘Rework Cost’, which gives an interesting direction of research to explore TD quantification in terms of these costs. Therefore, through our empirical study, we plan to explore the relationship between TD, New Code Cost and Rework Cost in Open-Source Software Projects. This paper reports on an initial motivating study, our plan for future work and implications for researchers.

Requirements Technical Debt (RTD) is a research area where the Technical Debt (TD) metaphor is used to capture the consequences of sub-optimal decisions made concerning Requirements. Understanding the quantification of RTD is key to its management. To facilitate this understanding, we model the quantification of RTD. Our work is grounded in the literature found via a Systematic Mapping Study (SMS) and informed by prior work modeling the quantification of TD for software code-related TD types. This paper reports on the SMS and the development of our model, the RTD Quantification Model (RTDQM). The key observation from our work is that, although RTD is similar in most aspects to TD in software code, it also has its own components. Requirement artifacts have a feedback loop involving the User to precisely capture User Needs. RTD Interest (i.e., additional costs due to sub-optimal decisions concerning Requirements) can incur during both Requirements Engineering and Implementation activities. Furthermore, RTD can incur regardless of the presence of software code-related TD. Similar to benefits accrued by refactoring software code, rectifying RTD can also accrue benefits.