pith. sign in

arxiv: 1907.10887 · v1 · pith:HUT4FTCKnew · submitted 2019-07-25 · 💻 cs.SE

Towards an Holistic Definition of Requirements Debt

Valentina Lenarduzzi , Davide Fucci This is my paper

Pith reviewed 2026-05-24 16:25 UTC · model grok-4.3

classification 💻 cs.SE
keywords requirements debttechnical debtrequirements engineeringsoftware engineeringdebt managementholistic definition
0
0 comments X

The pith

Requirements debt arises in identifying, formalizing, and implementing requirements, not only later development stages.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper extends the technical debt concept to requirements engineering by proposing a single definition that covers the full lifecycle of requirements work. It draws from prior literature on technical debt to argue that problems at the identification stage, the formalization stage, and the implementation stage all constitute requirements debt. The authors position this definition as the foundation for future monitoring tools that would let teams decide when incurring such debt is acceptable and when repayment is needed. A sympathetic reader would care because unmanaged requirements debt is claimed to harm long-term project outcomes in the same way code-level debt does.

Core claim

Grounded in the existing literature, we present a holistic definition of requirements debt which include 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 the 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.

What carries the argument

The holistic definition of requirements debt that unifies debt across identification, formalization, and implementation phases.

If this is right

  • Teams gain a basis for deciding when to accept requirements debt and when to repay it.
  • A monitoring framework can be built to track requirements debt across the three phases.
  • Stakeholders can weigh the costs of requirements debt against project benefits in concrete terms.
  • Future validation studies can test and refine the definition against real projects.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The definition may allow requirements debt to be tracked alongside code debt in unified project dashboards.
  • It could prompt new practices for early detection of debt during requirements workshops or elicitation sessions.
  • Agile teams that treat requirements as evolving artifacts may need adjusted repayment schedules compared to plan-driven projects.

Load-bearing premise

The debt metaphor transfers from code and technical debt literature to requirements engineering in a way that yields one coherent definition without new primary data.

What would settle it

Empirical cases in which debt incurred during requirements identification cannot be assessed or managed by the same criteria and repayment logic used for debt in requirements implementation.

Figures

Figures reproduced from arXiv: 1907.10887 by Davide Fucci, Valentina Lenarduzzi.

Figure 1
Figure 1. Figure 1: Types of Requirements Debt (ReD) incurred, their [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Study design for ReD concept validation. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
read the original abstract

When not appropriately managed, technical debt is considered to have negative effects on the long term success of a software project. 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 include 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 the 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

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

0 major / 3 minor

Summary. The manuscript proposes a holistic definition of requirements debt, grounded in the technical debt literature, that encompasses debt incurred during the identification, formalization, and implementation of requirements. It outlines future assessment to validate the definition and positions it as the first step towards a requirements debt monitoring framework to support stakeholder decisions.

Significance. This conceptual synthesis extends the debt metaphor to requirements engineering activities. If the definition holds up under validation, it could facilitate better management of requirements-related issues in software projects by providing a coherent framework for identifying, incurring, and repaying such debt. The paper's explicit framing as an initial step without empirical claims is a positive aspect.

minor comments (3)
  1. [Abstract] Abstract: the proposed definition is described at a high level but not stated explicitly; including the precise wording of the definition would improve clarity for readers.
  2. The manuscript would benefit from a dedicated section or subsection that isolates and presents the final proposed definition in a highlighted or boxed format.
  3. Future assessment section: the outline of validation steps is high-level; adding even brief examples of potential assessment methods or metrics would strengthen the forward-looking component without altering the conceptual scope.

Simulated Author's Rebuttal

0 responses · 0 unresolved

We thank the referee for the positive assessment of our manuscript and the recommendation for minor revision. The work is positioned explicitly as a conceptual first step toward a requirements debt monitoring framework, and we appreciate the recognition of this framing.

Circularity Check

0 steps flagged

No significant circularity detected

full rationale

The paper is a conceptual synthesis proposing a holistic definition of requirements debt grounded in prior technical debt literature across identification, formalization, and implementation phases. It contains no equations, fitted parameters, predictions, or derivations that reduce to self-referential inputs by construction. The work explicitly positions itself as an initial step requiring future validation and does not advance empirical claims or untested extensions. The central claim draws from external published literature rather than self-citation chains or ansatzes that would create circularity, rendering the derivation self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The paper rests on the assumption that the technical debt metaphor transfers usefully to requirements work and that literature synthesis alone suffices for an initial definition.

axioms (1)
  • domain assumption The debt metaphor applies to requirements engineering in general and to its activities in particular
    Stated directly in the abstract as the motivation for the work.
invented entities (1)
  • requirements debt no independent evidence
    purpose: To name and organize costs arising in requirements identification, formalization, and implementation
    New term introduced to extend technical debt concepts; no independent evidence such as measured instances is provided.

pith-pipeline@v0.9.0 · 5621 in / 1224 out tokens · 20519 ms · 2026-05-24T16:25:24.941132+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

32 extracted references · 32 canonical work pages

  1. [1]

    The wycash portfolio management system,

    W. Cunningham, “The wycash portfolio management system,” in OOP- SLA ’92, 1992

    work page 1992

  2. [2]

    Investigating architectural technical debt accumulation and refactoring over time: A multiple-case study,

    A. Martini, J. Bosch, and M. Chaudron, “Investigating architectural technical debt accumulation and refactoring over time: A multiple-case study,” Information and Software Technology , vol. 67, pp. 237 – 253, 2015

    work page 2015

  3. [3]

    Embrac- ing technical debt, from a startup company perspective,

    T. Besker, A. Martini, R. E. Lokuge, K. Blincoe, and J. Bosch, “Embrac- ing technical debt, from a startup company perspective,” in International Conference on Software Maintenance and Evolution (ICSME) , Sep. 2018, pp. 415–425

    work page 2018

  4. [4]

    Managing technical debt in software-reliant systems,

    N. Brown, Y . Cai, Y . Guo, R. Kazman, M. Kim, P. Kruchten, E. Lim, A. MacCormack, R. Nord, I. Ozkaya, R. Sangwan, C. Seaman, K. Sul- livan, and N. Zazworka, “Managing technical debt in software-reliant systems,” in Workshop on Future of Software Engineering Research , 2010, pp. 47–52

    work page 2010

  5. [5]

    A systematic mapping study on technical debt and its management,

    Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping study on technical debt and its management,” Journal of Systems and Software , vol. 101, pp. 193 – 220, 2015

    work page 2015

  6. [6]

    On the role of requirements in understanding and managing technical debt,

    N. A. Ernst, “On the role of requirements in understanding and managing technical debt,” in Proceedings of the Third International Workshop on Managing Technical Debt, ser. MTD ’12, 2012, pp. 61–64

    work page 2012

  7. [7]

    On the limits of the technical debt metaphor some guidance on going beyond,

    K. Schmid, “On the limits of the technical debt metaphor some guidance on going beyond,” in 4th International Workshop on Managing Technical Debt (MTD), 2013, pp. 63–66

    work page 2013

  8. [8]

    Towards an ontology of terms on technical debt,

    N. S. R. Alves, L. F. Ribeiro, V . Caires, T. S. Mendes, and R. O. Sp´ınola, “Towards an ontology of terms on technical debt,” in International Workshop on Managing Technical Debt , 2014, pp. 1–7

    work page 2014

  9. [9]

    Mvp explained: A systematic mapping study on the definitions of minimal viable product,

    V . Lenarduzzi and D. Taibi, “Mvp explained: A systematic mapping study on the definitions of minimal viable product,” in 42th Euromi- cro Conference on Software Engineering and Advanced Applications (SEAA), Aug 2016, pp. 112–119

    work page 2016

  10. [10]

    Comparing requirements decomposition within the scrum, scrum with kanban, xp, and banana development processes,

    D. Taibi, V . Lenarduzzi, A. Janes, K. Liukkunen, and M. O. Ahmad, “Comparing requirements decomposition within the scrum, scrum with kanban, xp, and banana development processes,” in Agile Processes in Software Engineering and Extreme Programming . Springer Interna- tional Publishing, 2017, pp. 68–83

    work page 2017

  11. [11]

    Technical debt prioritization: State of the art. a systematic literature review,

    V . Lenarduzzi, T. Besker, D. Taibi, A. Martini, and F. A. Fontana, “Technical debt prioritization: State of the art. a systematic literature review,” 2019

    work page 2019

  12. [12]

    Toward data-driven requirements engineering,

    W. Maalej, M. Nayebi, T. Johann, and G. Ruhe, “Toward data-driven requirements engineering,” IEEE Software , vol. 33, no. 1, pp. 48–54, 2015

    work page 2015

  13. [13]

    The financial aspect of managing technical debt: A systematic literature review,

    A. Ampatzoglou, A. Ampatzoglou, A. Chatzigeorgiou, and P. Avgeriou, “The financial aspect of managing technical debt: A systematic literature review,” Information and Software Technology , vol. 64, pp. 52 – 73, 2015

    work page 2015

  14. [14]

    An exploration of technical debt,

    E. Tom, A. Aurum, and R. Vidgen, “An exploration of technical debt,” Journal of Systems and Software , vol. 86, no. 6, pp. 1498 – 1516, 2013

    work page 2013

  15. [15]

    Measuring and monitoring technical debt,

    C. B. Seaman and Y . Guo, “Measuring and monitoring technical debt,” Advances in Computers , vol. 82, pp. 25–46, 12 2011

    work page 2011

  16. [16]

    An empirically developed method to aid decisions on architectural technical debt refactoring: Anacondebt,

    A. Martini and J. Bosch, “An empirically developed method to aid decisions on architectural technical debt refactoring: Anacondebt,” in 38th International Conference on Software Engineering Companion, ser. ICSE ’16, 2016, pp. 31–40

    work page 2016

  17. [17]

    App store mining is not enough for app improvement,

    M. Nayebi, H. Cho, and G. Ruhe, “App store mining is not enough for app improvement,” Empirical Software Engineering , vol. 23, no. 5, pp. 2764–2794, Oct 2018

    work page 2018

  18. [18]

    Rapid quality assurance with requirements smells,

    H. Femmer, D. M. Fern ´andez, S. Wagner, and S. Eder, “Rapid quality assurance with requirements smells,” Journal of Systems and Software , vol. 123, pp. 190–213, 2017

    work page 2017

  19. [19]

    Measure it? manage it? ignore it? software practitioners and technical debt,

    N. A. E., S. Bellomo, I. Ozkaya, R. L. Nord, and I. Gorton, “Measure it? manage it? ignore it? software practitioners and technical debt,” in Joint Meeting on Foundations of Software Engineering , ser. ESEC/FSE 2015, 2015, pp. 50–60

    work page 2015

  20. [20]

    Naming the pain in requirements engineering,

    D. M. Fern ´andez, S. Wagner, M. Kalinowski, M. Felderer, P. Mafra, A. Vetr`o, T. Conte, M.-T. Christiansson, D. Greer, C. Lassenius et al., “Naming the pain in requirements engineering,” Empirical software engineering, vol. 22, no. 5, pp. 2298–2338, 2017

    work page 2017

  21. [21]

    Are all code smells harmful? a study of god classes and brain classes in the evolution of three open source systems,

    S. M. Olbrich, D. Cruzes, and D. Sjøberg, “Are all code smells harmful? a study of god classes and brain classes in the evolution of three open source systems,” in IEEE International Conference on Software Maintenance, ICSM, 09 2010, pp. 1–10

    work page 2010

  22. [22]

    Quantify- ing the effect of code smells on maintenance effort,

    D. Sjøberg, A. Yamashita, B. Anda, A. Mockus, and T. Dyb ˚a, “Quantify- ing the effect of code smells on maintenance effort,” IEEE Transactions on Software Engineering , vol. 39, pp. 1144–1156, 08 2013

    work page 2013

  23. [23]

    Some code smells have a significant but small effect on faults,

    T. Hall, M. Zhang, D. Bowes, and Y . Sun, “Some code smells have a significant but small effect on faults,” ACM Trans. Softw. Eng. Methodol. , vol. 23, no. 4, pp. 33:1–33:39, Sep. 2014. [Online]. Available: http://doi.acm.org/10.1145/2629648

    work page doi:10.1145/2629648 2014

  24. [24]

    On the diffuseness and the impact on maintainability of code smells: A large scale empirical investigation,

    F. Palomba, G. Bavota, M. D. Penta, F. Fasano, R. Oliveto, and A. De Lucia, “On the diffuseness and the impact on maintainability of code smells: A large scale empirical investigation,” Empirical Softw. Engg., vol. 23, no. 3, pp. 1188–1221, Jun. 2018

    work page 2018

  25. [25]

    The technical debt dataset,

    V . Lenarduzzi, , and N. S. D. Taibi, “The technical debt dataset,” in The Fifteenth International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE’19) , 2019

    work page 2019

  26. [26]

    How developers perceive smells in source code: A replicated study,

    D. Taibi, A. Janes, and V . Lenarduzzi, “How developers perceive smells in source code: A replicated study,” Information and Software Technology, vol. 92, pp. 223 – 235, 2017

    work page 2017

  27. [27]

    An empirical model of technical debt and interest,

    A. Nugroho, J. Visser, and T. Kuipers, “An empirical model of technical debt and interest,” in Workshop on Managing Technical Debt, ser. MTD ’11, 2011, pp. 1–8

    work page 2011

  28. [28]

    Comparing four approaches for technical debt identification,

    N. Zazworka, A. Vetro’, C. Izurieta, S. Wong, Y . Cai, C. Seaman, and F. Shull, “Comparing four approaches for technical debt identification,” Software Quality Journal , vol. 22, no. 3, pp. 403–426, Sep. 2014

    work page 2014

  29. [29]

    A portfolio approach to technical debt manage- ment,

    Y . Guo and C. Seaman, “A portfolio approach to technical debt manage- ment,” in Workshop on Managing Technical Debt, ser. MTD ’11, 2011, pp. 31–34

    work page 2011

  30. [30]

    In search of a metric for managing architectural technical debt,

    R. L. Nord, I. Ozkaya, P. Kruchten, and M. Gonzalez-Rojas, “In search of a metric for managing architectural technical debt,” in WICSA-ECSA, 2012, pp. 91–100

    work page 2012

  31. [31]

    Using real options to manage technical debt in requirements engineering,

    Z. S. H. Abad and G. Ruhe, “Using real options to manage technical debt in requirements engineering,” in 23rd International Requirements Engineering Conference (RE) , 2015, pp. 230–235

    work page 2015

  32. [32]

    Identifying design and requirement self-admitted technical debt using n-gram idf,

    S. Wattanakriengkrai, R. Maipradit, H. Hata, M. Choetkiertikul, T. Sunetnanta, and K. Matsumoto, “Identifying design and requirement self-admitted technical debt using n-gram idf,” in Workshop on Empir- ical Software Engineering in Practice (IWESEP) , 2018, pp. 7–12

    work page 2018