Technical Debt and Waste in Non-functional Requirements Documentation: An Exploratory Study

Robiolo, Gabriela; Scott, Ezequiel; Matalonga, Santiago; Felderer, Michael

doi:10.1007/978-3-030-35333-9_16

Cited by 9 publications

(16 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Although there are studies that investigate documentation in ASD [6,15,21,28,[33][34][35], those that specifically examine the documentation of QRs are few. Additionally, detailed investigation of practices of documentation of QRs in ASD is missing.…”

Section: Related Workmentioning

confidence: 99%

“…They identified that the lack of QRs identification and the lack of information were related to high proportions of documentation debt. Robiolo et al [28], explored the indicators of technical debt and waste resulting from QR documentation based on survey findings.…”

Section: Related Workmentioning

confidence: 99%

“…For instance, Mendez et al [21] examined the impact of documentation debt (i.e., technical debt that is caused by incomplete and insufficient requirements artifacts) in ASD. Robiolo et al [28] explored the indicators of potential technical debt (identifying QRs that have not been documented although marked as important) and waste (identifying QRs documented but marked as not important), by surveying practitioners. Behutiye et al [6], examined the challenges and practices of documentation of QRs in ASD.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Documentation of Quality Requirements in Agile Software Development

Behutiye

Seppänen

Rodríguez

et al. 2020

Proceedings of the Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

Context: Quality requirements (QRs) have a significant role in the success of software projects. In agile software development (ASD), where working software is valued over comprehensive documentation, QRs are often under-specified or not documented. Consequently, they may be handled improperly and result in degraded software quality and increased maintenance costs. Investigating the documentation of QRs in ASD, would provide evidence on existing practices, tools and aspects considered in ASD that other practitioners might utilize to improve documentation and management of QRs in ASD. Although there are some studies examining documentation in ASD, those that specifically investigate the documentation of QRs in depth are lacking. Method: we conducted a multiple case study by interviewing 15 practitioners of four ASD cases, to provide empirical evidence on documentation of QRs in ASD. We also run workshops with two of the cases, to identify important aspects that ASD practitioners consider when documenting QRs in requirements management repositories. Result and conclusions: ASD companies approach documentation of QRs to fit the needs of their context. They used tools, backlogs, iterative prototypes, and artifacts such as epic, and stories to document QRs, or utilized face-face communication without documenting QRs. We observed that documentation of QRs in ASD is affected by factors such as context (e.g. product domain, and size) and the experience of practitioners. Some tools used to document QRs also enhanced customer collaboration, enabling customers report and document QRs. Aspects such as levels of abstraction, the traceability of QRs, optimal details of information of QRs and verification and validation are deemed important when documenting QRs in ASD requirements management repositories.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Documentation of Quality Requirements in Agile Software Development

Behutiye

Seppänen

Rodríguez

et al. 2020

Proceedings of the Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

show abstract

“…Los requisitos no funcionales son restricciones en los servicios o funciones que ofrece el sistema, incluyendo restricciones de tiempo, restricciones en los procesos y estándares de desarrollo [3]. Algunos autores reconocen prácticas relacionadas con requisitos no funcionales [1]- [10], pero para nombrarlas emplean diferentes elementos: productos de trabajo y descripciones completas de funcionamiento [4], [5], restricciones [6] y nombres de métodos [7]. En otros casos emplean verbos junto con sustantivos [4], [6]- [10].…”

Section: Introductionunclassified

“…Algunos autores reconocen prácticas relacionadas con requisitos no funcionales [1]- [10], pero para nombrarlas emplean diferentes elementos: productos de trabajo y descripciones completas de funcionamiento [4], [5], restricciones [6] y nombres de métodos [7]. En otros casos emplean verbos junto con sustantivos [4], [6]- [10]. Barón [11] establece que una práctica bien nombrada en ingeniería de software debería contener un verbo nominalizado, un sustantivo y un adjetivo que identifique la forma en que se realiza la acción que se define con el verbo nominalizado.…”

Section: Introductionunclassified

Nombramiento de prácticas relacionadas con requisitos no funcionales en el proceso de desarrollo de software

Jaramillo

2020

Ing.USBMed

View full text Add to dashboard Cite

En ingeniería de software, es usual hablar de prácticas a diferentes niveles, como grupos de actividades que se repiten y que entregan buenos resultados con su uso. Los requisitos no funcionales (entendidos como restricciones en los servicios o funciones del sistema) también tienen prácticas asociadas. Sin embargo, existen formas de nombramiento que no permiten generar un consenso alrededor de dichas prácticas, pues se utilizan productos de trabajo, restricciones, descripciones y otros elementos que impiden reconocer la práctica y su uso. Por ello, en este artículo se nombra un conjunto de prácticas sobre requisitos no funcionales a partir de su descripción en la literatura y tomando en consideración los elementos que requiere el buen nombramiento. Se espera que este conjunto de prácticas de requisitos no funcionales sirva como punto de partida para la representación detallada en estándares gráficos que se definan para ese fin.

show abstract

LEAP – A Process for Identifying Potential Technical Debt in Iterative System Development

Kleinwaks,

Batchelor,

Bradley

et al. 2023

INCOSE International Symp

View full text Add to dashboard Cite

Systems engineering has seen a rise in the use of iterative methods to design and develop both hardware and software systems which allow for system refinement to be responsive to user needs. However, focusing on items with high value to the user can result in technical debt, where technical compromises made for short‐term gain impact the long‐term health of the system. Current methods for identifying technical debt focus on finding existing technical debt items within a system and not on proactive identification of technical debt during the iterative system planning process. This paper presents a novel technique to identify technologies that impact the ability of the system to satisfy the needs of its stakeholders. The method is used to evaluate different choices of technological implementations in both the temporal and the functional dimensions to reduce the risk of incurring technical debt which prevents the successful delivery of the system.

show abstract

Technical Debt and Waste in Non-functional Requirements Documentation: An Exploratory Study

Abstract: Background: To adequately attend to non-functional require-

Cited by 9 publications

References 26 publications

Documentation of Quality Requirements in Agile Software Development

Documentation of Quality Requirements in Agile Software Development

Nombramiento de prácticas relacionadas con requisitos no funcionales en el proceso de desarrollo de software

LEAP – A Process for Identifying Potential Technical Debt in Iterative System Development

Contact Info

Product

Resources

About