Table of Contents
Fetching ...

Towards Quantifying Requirements Technical Debt for Software Requirements concerning Veracity: A Perspective and Research Roadmap

Judith Perera, Ewan Tempero, Yu-Cheng Tu, Kelly Blincoe, Matthias Galster

TL;DR

The paper addresses the challenge of managing requirements-related truth, trust, and verifiability in software by introducing Veracity Debt (Veracity RTD) and outlining a research roadmap to quantify it. It proposes extending the existing RTD Quantification Model (RTDQM) to incorporate veracity dimensions—regulatory, data, financial data, cultural, and process—and uses a New Zealand Organic Supply Chain case to illustrate the practical relevance of functional and non-functional veracity requirements. An illustrative approach based on Modern Portfolio Theory and sustainability-driven RTD methods shows how architectures can be ranked by expected veracity benefits against costs and risks. The authors plan industry engagement (surveys and interviews) to validate VRTDQM, derive metrics, and guide practitioners toward veracity-aware software, with implications for domains like SEA, AI, and data governance. This work establishes a structured path to measure and manage veracity debt in software systems across multiple domains."

Abstract

Software practitioners can make sub-optimal decisions concerning requirements during gathering, documenting, prioritizing, and implementing requirements as software features or architectural design decisions -- this is captured by the metaphor `Requirements Technical Debt (RTD).' In our prior work, we developed a conceptual model to understand the quantification of RTD and support its management. In this paper, we present our perspective and the vision to apply the lens of RTD to software requirements concerning veracity, i.e., requirements related to truth, trust, authenticity, and demonstrability in software-intensive systems. Our goal is to cultivate awareness of veracity as an important concern and eventually support the management of RTD for software requirements concerning veracity, what we term as `Veracity Debt,' through its quantification.

Towards Quantifying Requirements Technical Debt for Software Requirements concerning Veracity: A Perspective and Research Roadmap

TL;DR

The paper addresses the challenge of managing requirements-related truth, trust, and verifiability in software by introducing Veracity Debt (Veracity RTD) and outlining a research roadmap to quantify it. It proposes extending the existing RTD Quantification Model (RTDQM) to incorporate veracity dimensions—regulatory, data, financial data, cultural, and process—and uses a New Zealand Organic Supply Chain case to illustrate the practical relevance of functional and non-functional veracity requirements. An illustrative approach based on Modern Portfolio Theory and sustainability-driven RTD methods shows how architectures can be ranked by expected veracity benefits against costs and risks. The authors plan industry engagement (surveys and interviews) to validate VRTDQM, derive metrics, and guide practitioners toward veracity-aware software, with implications for domains like SEA, AI, and data governance. This work establishes a structured path to measure and manage veracity debt in software systems across multiple domains."

Abstract

Software practitioners can make sub-optimal decisions concerning requirements during gathering, documenting, prioritizing, and implementing requirements as software features or architectural design decisions -- this is captured by the metaphor `Requirements Technical Debt (RTD).' In our prior work, we developed a conceptual model to understand the quantification of RTD and support its management. In this paper, we present our perspective and the vision to apply the lens of RTD to software requirements concerning veracity, i.e., requirements related to truth, trust, authenticity, and demonstrability in software-intensive systems. Our goal is to cultivate awareness of veracity as an important concern and eventually support the management of RTD for software requirements concerning veracity, what we term as `Veracity Debt,' through its quantification.
Paper Structure (17 sections)