Towards a Holistic Definition of Requirements Debt

Abstract

When not appropriately managed, technical debt is considered to have negative effects to the long term success of software projects. However, how the debt metaphor applies to requirements engineering in general, and to requirements engineering activities in particular, is not well understood. Grounded in the existing literature, we present a holistic definition of requirements debt which includes debt incurred during the identification, formalization, and implementation of requirements. We outline future assessment to validate and further refine our proposed definition. This conceptualization is a first step towards a requirements debt monitoring framework to support stakeholders decisions, such as when to incur and eventually pay back requirements debt, and at what costs.

The Technical Debt Dataset

“…Moreover, we are planning to investigate further datasets such as [30] that could be used to complement the data of our dataset. Moreover, we are planning to extend our previous work with this version of the dataset, applying NLP on requirements and Jira issues [18], and analyzing the relationship between technical debt and coupling [4]. Moreover we are planning to analyze differences between technical debt issues in open source projects and in SMEs [21] and to use the results as baseline for continuous quality monitoring approaches [16], [24].…”

“…SonarQube Quality Profiles: https://docs.sonarqube.org/display/SONAR/Quality+Profiles Last Access:June 201918 https://docs.sonarqube.org/display/DEV/API+Basics…”

An Initial Theory to Understand and Manage Requirements Engineering Debt in Practice

“…This definition exceeds the perspective of requirements documentation and considers general requirements problems. However, the definition is still limited to only one specific requirements problem-i.e., what Lenarduzzi and Fucci [4] refer to as mismatch implementation. The latter extends the definition of RED by including two additional requirements problems related to stakeholder discovery-i.e., the debt accrued by involving only part of the stakeholders in the RE process, and requirements artifact smells-i.e., the debt accrued due to quality violation in the requirements specification, such as using ambiguous language.…”

“…In Requirements Engineering (RE), Ernst [3] proposed an initial application of the debt metaphor-i.e., requirements engineering debt (RED). Subsequently, Lenarduzzi and Fucci [4] provided a vision for a broader definition of how debt can be accumulated in requirements engineering activities.…”

An Empirical Study on Technical Debt in a Finnish SME

“…The risk of a roadblock through a "TD bankruptcy" increases when new requirements emerge and need attention, leading to the rewriting of existing features, which should be avoided by estimating the costs of TD. Moreover, outsourcing part of the development to consultants, also increase the risk of requirement TD [14] related to misunderstandings [15] and increase the communication overhead [16].…”