Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Esta obra est´a bajo una Licencia
Creative Commons Atribuci´on
4.0 Internacional.
Tipo de art´ıculo: Art´ıculos de revisi´on
Tem´atica: Ingenier´ıa de software
Recibido: 3/6/2025 |Aceptado: 17/7/2025 |Publicado: 30/9/2025
Identificadores persistentes:
DOI: 10.48168/innosoft.s24.a292
ARK: ark:/42411/s24.a292
PURL: 42411/s24.a292
Revisi´on Sistem´atica de la Literatura de la Deuda de
Requisitos: Sus Causas y Medici´on.
Systematic Review of the Debt Requirements Literature: Its
Causes and Measurement.
Maria Janai Sanchez Hern´andez1[0000-0002-3005-5235]*, Maria Guadalupe Medina
Barrera2[0000-0003-3074-0029], Jos´e Federico Ram´ırez Cruz3[0000-0002-4468-4171], Blanca Estela
Pedroza-M´endez4[0000-0002-9819-635X]
1Tecnol´ogico Nacional de M´exico / Instituto Tecnol´ogico de Apizaco. Apizaco, M´exico.
d96370620@apizaco.tecnm.mx
2Tecnol´ogico Nacional de M´exico / Instituto Tecnol´ogico de Apizaco. Apizaco, M´exico.
guadalupe.mb@apizaco.tecnm.mx
3Tecnol´ogico Nacional de M´exico / Instituto Tecnol´ogico de Apizaco. Apizaco, M´exico.
federico.rc@apizaco.tecnm.mx
4Tecnol´ogico Nacional de M´exico / Instituto Tecnol´ogico de Apizaco. Apizaco, M´exico.
blanca.pm@apizaco.tecnm.mx
∗Autor para correspondencia: d96370620@apizaco.tecnm.mx
Resumen
La Deuda T´ecnica de Requisitos se define como la diferencia entre los requisitos inicialmente planteados y el
producto final de software. Este estudio tuvo como objetivo realizar una Revisi´on Sistem´atica de la Literatu-
ra, basada en una metodolog´ıa estructurada en tres fases: definici´on de un protocolo de b´usqueda, selecci´on
de fuentes cient´ıficas relevantes y aplicaci´on de criterios de inclusi´on y exclusi´on, seguido de la s´ıntesis de
la informaci´on recopilada. Se analizaron investigaciones de los ´ultimos cinco a˜nos, considerando un total de
trece art´ıculos. Los resultados indican que las principales causas de la Deuda T´ecnica de Requisitos incluyen
la falta de documentaci´on formal, la presi´on por cumplir con plazos de entrega, la deficiente comunicaci´on
entre el cliente y el equipo de desarrollo, as´ı como la ausencia de herramientas automatizadas que optimicen la
trazabilidad de los requisitos, entre otros factores. Respecto a su medici´on, se han propuesto estrategias como
el an´alisis costo-beneficio y la estimaci´on de costos de rectificaci´on; sin embargo, a´un no se han validado en
contextos reales, lo que limita su aplicabilidad pr´actica. En conclusi´on, la Deuda T´ecnica de Requisitos repre-
senta un desaf´ıo en la ingenier´ıa de software, afectando directamente la calidad y el ´exito de los proyectos. Este
trabajo proporciona un panorama actualizado que puede servir como fundamento para futuras investigaciones
en el ´area, con el fin de desarrollar estrategias m´as efectivas para su gesti´on y posible mitigaci´on.
Palabras claves: Deuda de requisitos, deuda t´ecnica de requerimientos, olores de requisitos, causas, medici´on.
Abstract
Technical Requirements Debt is defined as the difference between the initially stated requirements and the final
software product. This study aimed to conduct a systematic literature review based on a methodology structured
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
217
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
in three phases: definition of a search protocol, selection of relevant scientific sources, and application of
inclusion and exclusion criteria, followed by a synthesis of the collected information. Research from the last
five years was analyzed, considering a total of thirteen articles. The results indicate that the main causes
of Technical Requirements Debt include the lack of formal documentation, pressure to meet deadlines, poor
communication between the client and the development team, as well as the absence of automated tools that
optimize requirements traceability, among other factors. Regarding its measurement, strategies such as cost-
benefit analysis and rectification cost estimation have been proposed; however, these have not yet been validated
in real-world contexts, which limits their practical applicability. In conclusion, Technical Requirements Debt
represents a challenge in software engineering, directly affecting project quality and success. This work provides
an updated overview that can serve as a basis for future research in the area, with the goal of developing more
effective strategies for its management and possible mitigation.
Keywords: Debt of requirements, technical debt of requirements, requirement smells, causes, measurement.
*
Introducci´on El concepto de deuda t´ecnica - Technical Debt - (TD) fue introducido por Cunningham en
1993 [1] y posteriormente desarrollado por McConnell en 2008 [2]. Este t´ermino se refiere al costo futuro que
implica tomar decisiones apresuradas en el desarrollo de software. Aunque un lanzamiento acelerado puede
ser beneficioso inicialmente, las mejoras necesarias deben implementarse a tiempo; de lo contrario, la deuda
acumulada puede derivar en problemas m´as complejos y costosos de resolver [3]y[4]. En la Tabla 1 se muestra
la ampliaci´on del concepto de TD realizada por [5] y [2]. Aqu´ı, la TD es categorizada en cuatro tipos que
considera las diferentes decisiones estrat´egicas que un equipo puede tomar de forma prudente o imprudente.
Tabla 1. Tipos de deuda t´ecnica y sus decisiones estrat´egicas. Adaptada de Fowler [5].
Prudente Imprudente
Deliberado “Debemos enviar ahora y asu-
mir lo que venga despu´es”.
“No tenemos tiempo para el
dise˜no”.
Involuntario “Ahora sabemos c´omo deb´ıa
haber sido”.
“¿Qu´e es dise˜no por capas?”.
Inicialmente, la deuda t´ecnica se asociaba principalmente con el c´odigo fuente. Sin embargo, en [6] ampliaron
la met´afora a otras ´areas del ciclo de vida del software, incluyendo los requerimientos, pruebas y dise˜no.
Uno de los tipos de deuda menos explorados es la Deuda T´ecnica de Requisitos - Requirement Technical Debt-
(RTD). Al respecto, [7] se˜nala que “se ha prestado poca atenci´on a los requisitos a lo largo del tiempo en
el software: los requisitos a menudo est´an muy desincronizados con la implementaci´on o no se utilizan en
absoluto. Sin embargo, los requisitos son la validaci´on definitiva del ´exito del proyecto, ya que representan los
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
218
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
deseos de las partes interesadas para el sistema”.
Ahora bien, por su parte [8] identificaron que la deuda t´ecnica puede clasificarse en diez tipos, cada uno
con subtipos basados en sus causas. Entre ellos, la RTD que es de particular inter´es en este estudio por lo
que se realiza una Revisi´on Sistem´atica de la Literatura (RSL) con el objetivo de identificar causas, as´ı como
analizar si hay propuestas de modelos de medici´on. Los resultados de esta RSL podr´ıan apoyar a investigaciones
enfocadas a la evaluaci´on de su impacto y evoluci´on durante el desarrollo de proyectos de software.
En la siguiente secci´on, se exponen los antecedentes de la RTD, proporcionando un marco que contextualiza el
tema de RTD y permite entender su fundamento. A continuaci´on, se desarrolla el proceso de la RSL, detallando
los pasos clave, m´etodos empleados y su relevancia dentro del contexto de la investigaci´on. Finalmente, en el
apartado 4 se presentan los hallazgos y conclusiones de este trabajo de revisi´on, donde se analizan los resultados
obtenidos y se proponen futuras ´areas de investigaci´on.
Deuda T´ecnica de Requisitos (RTD)
La fase de requisitos es una de las fases iniciales del ciclo de vida del desarrollo de software y se considera
fundamental debido a su impacto en el ´exito del producto final. En esta fase, se llevan a cabo actividades
como la elicitaci´on, an´alisis, negociaci´on, documentaci´on y validaci´on de requisitos. Dado que es el punto en
el que los usuarios expresan sus necesidades y se eval´ua la viabilidad de desarrollo, existe la posibilidad de
incurrir en RTD. En este sentido, la RTD se diferencia de otros tipos de deuda t´ecnica debido a un factor
clave: la participaci´on del usuario. En [9], a diferencia de otros tipos de deuda t´ecnica, en la RTD el usuario
juega un papel fundamental en la definici´on de los requisitos y el bucle de retroalimentaci´on, lo que hace que
su participaci´on sea especialmente cr´ıtica para el ´exito del proyecto.
Seg´un N. Ernst la RTD se define como “la distancia entre la soluci´on ´optima a un problema de requisitos y la
soluci´on real, con respecto a alg´un espacio de decisi´on” [7]. De manera similar, en [9] se explica que la RTD
captura las consecuencias de decisiones sub´optimas tomadas en relaci´on con los requisitos, ya sea de forma
deliberada, por razones estrat´egicas, o inadvertida, debido a cambios en el contexto. Estas decisiones pueden
ocurrir durante la identificaci´on, formalizaci´on e implementaci´on de los requisitos.
En [10] ampl´ıan la definici´on de N. Ernst y proponen una clasificaci´on de la RTD en tres tipos:
Tipo 0: Se incurre en esta deuda cuando no se consideran adecuadamente las necesidades de los usuarios,
a pesar de que estas han sido expresadas a trav´es de los canales de comunicaci´on establecidos.
Tipo 1: Surge cuando el ingeniero de requisitos, analista de negocios o desarrollador formaliza las necesi-
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
219
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
dades de los usuarios utilizando “olores de requisitos” -Requirement Smells- (RS), es decir, formulaciones
ling¨u´ısticas que violan est´andares como ISO 29148. Esto puede generar requisitos amb´ıguos que, si no se
corrigen, pueden impactar negativamente la implementaci´on.
Tipo 2: Se presenta cuando los desarrolladores implementan una soluci´on basada en un conjunto de
requisitos, pero estos requisitos cambian y la implementaci´on no se ajusta a dichos cambios.
En este mismo sentido, [11], [12] se˜nalan que, incluso en contextos ´agiles de desarrollo de software, actividades
como la documentaci´on, el modelado, la priorizaci´on de los requisitos y la participaci´on de los interesados son
pr´acticas recomendadas. No obstante, estas actividades suelen llevarse a cabo de forma separada e informal,
lo que dificulta la comprensi´on de necesidades, la intergraci´on y el seguimiento. Cuando estas actividades se
ejecutan de manera inadecuada, es inminente la aparicipon de fallos en el desarrollo de software, por lo tanto
se incurre en la aparici´on y acumulaci´on de deuda t´ecnica, espec´ıficamente en forma de deuda de requisitos.
Revisi´on Sistem´atica de Literatura de la RTD
El objetivo principal de esta RSL es obtener un vistazo actualizado sobre el concepto de Deuda T´ecnica de
Requisitos, desde 2018 hasta la fecha. Para llevar a cabo esto, se implement´o la metodolog´ıa propuesta por [13]
que permite identificar, evaluar e interpretar la investigaci´on actual en el ´ambito de la Ingenier´ıa de Software,
la cual se sintetiz´o por [14]. De esta manera, esta RSL busca identificar estudios que aborden y clarifiquen las
causas de RTD, as´ı como conocer propuestas de modelos de medici´on o cuantificaci´on.
Seg´un el procedimiento establecido por [13] la RSL comienza con la definici´on y revisi´on de un protocolo
que especifica las preguntas de investigaci´on a responder y describe los m´etodos empleados en el desarrollo
de la revisi´on. La RSL tambi´en establece estrategias de b´usqueda que permiten evaluar la relevancia de la
literatura en diversas bases de datos cient´ıficas, garantizando que los estudios seleccionados sean de alta
calidad. Asimismo, se deben definir claramente los criterios de inclusi´on y exclusi´on para cerciorar que los
estudios seleccionados contribuyan efectivamente a la esta RSL.
En este contexto los autores de [14] describen el proceso de la RSL en tres fases: Planificaci´on, Conducci´on y
Documentaci´on, cada una con actividades clave espec´ıficas, las cuales se ilustran en la Figura 1 y se detallan
en los siguientes apartados de este art´ıculo.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
220
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Figura 1. Proceso de RSL. Elaboraci´on propia con base en Tebes et al. [14].
Planeaci´on
Preguntas de investigaci´on
El objetivo de esta Revisi´on Sistem´atica de la Literatura (RSL) es identificar y analizar de manera rigurosa
si existen estudios que ofrezcan una definici´on clara y objetiva del concepto de “deuda t´ecnica de requisi-
tos”. En caso afirmativo, se pretende que dichos estudios contribuyan a responder las siguientes preguntas de
investigaci´on:
P1. ¿ Cu´ales son las causas que originan la deuda t´ecnica de requisitos (RTD)?
P2. ¿Qu´e estrategias se han propuesto para la medici´on de la RTD?
Conducci´on
Selecci´on de fuentes y cadena de b´usqueda
El m´etodo de b´usqueda utilizado en este estudio consisti´o en la selecci´on de bibliotecas digitales relevantes
para el ´area de conocimiento, previamente utilizadas y referenciadas en otras revisiones sistem´aticas, como se
detalla en la Tabla 2. Para ello, se eligieron cinco de las principales bibliotecas digitales que ofrecen art´ıculos
de acceso abierto.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
221
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Tabla 2. Bibliotecas digitales
Springer Link
Science Direct
IEEEXplore
ACM Digital Library
ArXiv
Para llevar a cabo el proceso de exploraci´on en las bibliotecas digitales, fue necesario dise˜nar una cadena
de b´usqueda compuesta por los t´erminos clave relevantes para este estudio, conectados mediante operadores
l´ogicos. Dado que la mayor´ıa de las publicaciones relevantes en el ´area se encuentran redactadas en ingl´es, la
cadena de b´usqueda se formul´o exclusivamente en dicho idioma. La expresi´on final utilizada fue la siguiente:
(“Requirement debt” OR “Requirements Smells”) AND
(Features OR Causes OR Dimensions OR Factors OR Attributes) AND
(Measure OR Quantifying)
Extracci´on de datos
La b´usqueda se llev´o a cabo en cada una de las bibliotecas digitales seleccionadas, utilizando la cadena de
b´usqueda previamente definida. Los resultados preliminares obtenidos se presentan en la Figura 2. Como
se puede observar, esta b´usqueda inicial arroj´o un total de 175 documentos. Durante esta primera etapa
automatizada, se aplicaron filtros correspondientes al rango de fechas, la disciplina o ´area de conocimiento, y
el tipo de acceso (limitado a publicaciones de acceso abierto).
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
222
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Figura 2. Distribuci´on de art´ıculos en primera b´usqueda
La selecci´on de los art´ıculos se realiz´o mediante un enfoque de lectura en profundidad, comenzando por el t´ıtulo
y continuando con el resumen, las palabras clave, la conclusi´on y, finalmente, el texto completo del art´ıculo.
Durante esta etapa, se aplicaron los criterios de inclusi´on y exclusi´on previamente establecidos. Se incluyeron
aquellos estudios que abordaban las causas y los modelos de cuantificaci´on de la deuda t´ecnica de requisitos,
as´ı como aquellos que presentaban estudios de caso en los cuales se describ´ıa, directa o indirectamente, el
concepto de RTD.
Criterios de calidad
Los criterios de inclusi´on y exclusi´on desempe˜nan un papel fundamental en la realizaci´on de una selecci´on
objetiva de estudios. Si estos criterios son demasiado amplios, pueden comprometer la calidad de la RSL y
disminuir la confianza en los resultados obtenidos. La Tabla 3 presenta los criterios aplicados durante el proceso
de b´usqueda y selecci´on de art´ıculos.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
223
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Tabla 3. Criterios de inclusi´on y exclusi´on
Criterios de Inclusi´on Publicaciones entre el a˜no 2018- 2024. Pu-
blicaciones del ´area de computaci´on e in-
genier´ıa de software. Publicaciones que in-
cluyan los t´erminos “deuda t´ecnica de re-
quisitos” o “deuda de requerimientos”
Criterios de Exclusi´on Publicaciones de acceso restringido. Publi-
caciones que no contengan deuda de requi-
sitos. Publicaciones sin descripci´on de me-
todolog´ıa. Comentarios publicados en me-
morias u otros medios.
El Listado de art´ıculos incluidos en esta revisi´on se presenta en la Tabla 4.
Tabla 4. Demograf´ıa de Publicaciones relevantes para la RSL
T´ıtulo A˜no Autores Publicado
Art 1 23 shades of self-admitted
technical debt: an empirical
study on machine learning
software
2022 [15] ACM
Art 2 Towards Quantifying Requi-
rements Technical Debt for
Software Requirements con-
cerning Veracity: A Perspecti-
ve and Research Roadmap
2024 [16] ArXiv
Art 3 Integrating Traceability
within the IDE to Prevent
Requirements Documentation
Debt
2018 [17] IEEE. 44th Euro-
micro
Art 4 Quantifying Requirements
Technical Debt: A Systema-
tic Mapping Study and a
Conceptual Model
2023 [9] IEEE
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
224
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
T´ıtulo A˜no Autores Publicado
Art 5 Towards a Holistic Definition
of Requirements Debt
2019 [10] IEEE
Art 6 A systematic literature re-
view on Technical Deb priori-
tization: Strategies, processes,
factors, and tools
2021 [18] Science Direct
Art 7 Architectural design decisions
that incur technical debt-An
industrial case study
2021 [19] Science Direct
Art 8 Identification and measure-
ment of Requirements Techni-
cal Debt in software develop-
ment: A systematic literature
review
2022 [20] Science Direct
Art 9 An initial theory to unders-
tand and manage require-
ments engineering debt in
practice
2023 [21] Science Direct
Art 10 Stakeholder influence on tech-
nical debt management in the
public sector: An embedded
case study
2022 [22] Science Direct
Art 11 Modelling the quantification
of requirements technical debt
2024 [23] Springer
Art 12 Natural Language Require-
ments Testability Measure-
ment Based on Requirement
Smells
2024 [24] Springer
Art 13 Technical Debt and Waste in
Non-Functional Requirements
Documentation: An Explora-
tory Study
2019 [25] Springer
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
225
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Extracci´on de datos y s´ıntesis
Se llev´o a cabo una s´ıntesis de tipo cualitativo, en la cual los estudios seleccionados fueron agrupados seg´un los
dos ejes tem´aticos principales de esta RSL: causas y medici´on de la deuda t´ecnica de requisitos. Posteriormente,
se realiz´o un an´alisis comparativo de las distintas propuestas con el objetivo de identificar causas comunes de
la RTD, as´ı como enfoques y m´etodos utilizados para su cuantificaci´on o medici´on.
Documentaci´on
La redacci´on del informe se estructur´o en funci´on de cada pregunta de investigaci´on dise˜nada en esta RSL. En
la siguiente secci´on, se presentan los hallazgos obtenidos a partir del an´alisis de los estudios seleccionados.
Hallazgos
Causas de la RTD
P1. ¿ Cu´ales son las causas que originan la deuda t´ecnica de requisitos (RTD)?
La deuda t´ecnica de requisitos (RTD) puede originarse a partir de diversos factores. En su investigaci´on,
Melo et al. identifican 15 causas principales asociadas a la RTD, las cuales fueron extra´ıdas de la revisi´on
sistem´atica que llev´o a cabo [20]. Adem´as, el autor desarrolla una red que ilustra las relaciones entre dichas
causas. Por ejemplo, se destaca que un proceso inadecuado de elicitaci´on de requisitos se encuentra relacionado
con una deficiente planificaci´on de entrevistas, lo que impide que el cliente exprese con claridad sus necesidades.
Esto da lugar a requisitos ambiguos, incompletos o con un bajo nivel de detalle. Asimismo, la ambig¨uedad
de los requisitos se asocia con un estilo de redacci´on deficiente y problemas gramaticales, lo que dificulta su
interpretaci´on y comprensi´on.
De manera similar, en [21] se documentan las causas de la RTD surgidas a partir de entrevistas realizadas con
profesionales del sector, agrup´andolas en cuatro categor´ıas: tiempo, producto, personas y artefactos. En cuanto
a las causas relacionadas con el tiempo, estas est´an asociadas principalmente con los plazos de entrega del
producto de software. Las causas vinculadas a las personas se deben, en gran medida, a la falta de conocimiento
especializado para implementar ciertos requisitos por parte del equipo, as´ı como a la mala comunicaci´on entre
los miembros del equipo y el cliente. Adem´as, la falta de documentaci´on adecuada de los requisitos genera una
costosa reelaboraci´on. En este mismo sentido, [23] presenta una recopilaci´on de causas e indicadores de la RTD
extra´ıdos de un mapeo sistem´atico de literatura, destacando aspectos como la ambig¨uedad en la formalizaci´on
de los requisitos, la entrega de requisitos incompletos, las soluciones sub´optimas, la falta de trazabilidad entre
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
226
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
los requisitos y el c´odigo, la ausencia de documentos formales y las limitaciones de tiempo.
En la Tabla 4 se describen las principales causas identificadas en la literatura que pueden generar la RTD. Entre
ellas se incluyen la ambig¨uedad (tambi´en conocida como “olores de requisitos”), los plazos de entrega, la falta
de documentaci´on formal, la ausencia de estrategias de verificaci´on y validaci´on de los requisitos, problemas de
comunicaci´on, la escasez de recursos, la experiencia del equipo y la falta de herramientas especializadas para
llevar a cabo este proceso.
En cuanto a la ambig¨uedad, los estudios reportados en Art2, Art4, Art6, Art8 y Art12 coinciden en que la
ambig¨uedad de los requisitos es una causa clave de la RTD. Un requisito que no utiliza un lenguaje claro y
preciso puede dar lugar a malinterpretaciones de las necesidades, como lo menciona en [16]: “Una desviaci´on
menor de los requisitos es estrictamente un fallo que puede causar da˜nos fundamentales al producto de software
definitivo”. La ambig¨uedad puede analizarse a trav´es de la presencia o ausencia de sustantivos, verbos, adverbios
y adjetivos dentro de la definici´on de los requisitos.
Por otro lado, la causa relacionada con el tiempo es mencionada en los estudios Art3, Art6, Art7, Art9, Art10 y
Art11, desde la perspectiva de que los plazos limitados frecuentemente obligan a tomar decisiones apresuradas
(intencionadas), resultando en la entrega de productos de software que no cumplen completamente con las
especificaciones, o en productos que cumplen parcialmente pero no son efectivos ni eficientes. Esto, a su
vez, contribuye a la presencia de RTD en los proyectos. Esta variable est´a estrechamente vinculada con la
priorizaci´on de los requisitos, como se describe en los estudios Art2, Art8 y Art11, que se˜nalan que a menudo
se seleccionan requisitos que no aportan valor inmediato al cliente.
Adem´as, los trabajos Art3, Art4, Art5, Art8, Art9, Art10, Art11, Art12 y Art13 destacan que la falta de
un documento formal que describa las necesidades del cliente o usuario, junto con una redacci´on deficiente,
dificulta la comprensi´on de los requisitos, lo que impacta negativamente en la aparici´on de RTD.
De igual manera, las propuestas presentadas en Art10, Art11 y Art12 abordan el concepto de verifica-
ci´on/validaci´on de los requisitos. Se considera que un requisito que pasa por una fase de revisi´on alcanza
un nivel de confianza, mientras que la ausencia de verificaci´on aumenta la probabilidad de que el proyecto
enfrente RTD en las etapas posteriores del ciclo de vida del software.
Finalmente, los estudios Art1, Art2, Art10 y Art11 subrayan que los cambios (volatilidad) en los requisitos
o en el contexto del proyecto pueden ser problem´aticos, ya que pueden dar lugar a una falta de trazabilidad
entre los requisitos y el c´odigo, tal como lo menciona Art3.
En relaci´on con las causas, la comunicaci´on, ya sea entre los miembros del equipo, entre diferentes ´areas o
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
227
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
con el cliente, juega un papel crucial. Si los canales de comunicaci´on no son adecuados, la informaci´on puede
volverse deficiente, lo que a su vez genera una falta de comprensi´on de los requisitos, tal como se se˜nala en los
estudios Art2, Art8 y Art11. Adem´as, la complejidad de los requisitos es otro factor identificado como causa
de RTD, seg´un Art2 y Art8.
Una causa que es mencionada exclusivamente en el estudio Art7 es la limitaci´on de recursos. Este factor podr´ıa
considerarse relevante, ya que, en ausencia de recursos suficientes para abordar la complejidad del proyecto,
es com´un que se prioricen actividades m´as econ´omicas de desarrollar, dejando de lado aquellas que aportan
mayor valor al usuario o cliente.
Asimismo, la falta de conocimientos o experiencia del equipo frente a un proyecto determinado se considera
una causa significativa de la RTD, como se menciona en Art11 y Art13. De manera similar, la ausencia de
herramientas automatizadas especializadas para la definici´on de requisitos tambi´en se identifica como una
causa relevante de la RTD, seg´un Art3, Art12 y Art13.
Tabla 5. Causas de la RTD identificadas en la literatura
N´um. de Art´ıculo Causas identificadas
Art 1 Cambios en las especificaciones de requisitos, intenciones poco claras y
actualizaciones en cascada. Requisitos funcionales que requieren cambios
futuros Requisitos No funcionales, que no cumplen con los est´andares
(rapidez, memoria, seguridad, etc)
Art 2 Inadecuada recopilaci´on/ambig¨uedad Priorizaci´on de requisitos Imple-
mentaci´on parcial Complejidad de los requisitos Variabilidad contextual
Art 3 Requerimientos insuficientes o incompletos (casos de uso, historias de
usuario, SRS) baja calidad Requisitos obsoletos Trazabilidad de los re-
quisitos Comunicaci´on entre los departamentos Limitaci´on de tiempo
(falta de comprensi´on) Falta de comunicaci´on con los clientes Uso de
aplicaciones distintas para documentar
Art 4 Falta de entendimiento de las necesidades de los clientes Ambig¨uedades
Olores de requisitos Requisitos incompletos
Art 5 Documentaci´on ineficiente de requerimientos (olores de requisitos)
Art 6 Tiempo empresarial Falta de claridad de los requisitos Pr´acticas de re-
factorizaci´on insuficientes
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
228
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
N´um. de Art´ıculo Causas identificadas
Art 7 Limitaci´on de tiempo Limitaci´on de recursos Baja comprensi´on de los
requisitos
Art 8 Bajo nivel de documentaci´on Requerimientos ambiguos No definici´on de
requerimientos no funcionales Requerimientos vagos o incompletos Falta
de comunicaci´on con el cliente Atajos y soluciones alternativas Presiones
de calendario No reflejar las necesidades del cliente Falta de experien-
cia Inadecuada priorizaci´on de requisitos Mala redacci´on Entrevistas no
planeadas Falta de guiones Requisitos complejos Mala elicitaci´on
Art 9 Tiempo Producto Personas Artefactos
Art 10 Calendario (tiempo) Mala documentaci´on Falta de verificaci´on de requi-
sitos Cambios de contexto
Art 11 Las ineficiencias en la identificaci´on y estimaci´on de los requisitos Inefi-
ciencias en la especificaci´on de los requisitos u olores de los requisitos
Brecha de comunicaci´on entre los miembros del equipo Fechas de entrega
(limitaciones de tiempo) Volatilidad de los requisitos Falta de comunica-
ci´on con los clientes Falta de pruebas de requisitos Falta de experiencia
y conocimientos Falta de documentaci´on
Art 12 Requerimientos olorosos (escritos con lenguaje subjetivo, ambig¨uedades)
Interpretaci´on err´onea de los requisitos dado el lenguaje ambiguo y sub-
jetivo Longitud de los requisitos Falta de comprobaci´on de los requisitos
Falta de metodolog´ıas para documentar los requisitos.
Art 13 La falta de documentaci´on de los requisitos No funcionales (mantenibili-
dad, fiabilidad, usabilidad y rendimiento) Tama˜no del proyecto Tipo de
proyecto Falta de conocimiento para documentar este tipo de requisitos
Falta de herramientas
En la Figura 3 se presenta la distribuci´on de las principales causas identificadas en cada investigaci´on, desta-
cando que las causas m´as frecuentemente citadas son: la ambig¨uedad en la redacci´on de los requisitos (conocida
como “olores de requisitos”), los problemas relacionados con el tiempo, la ausencia de un documento formal
de requisitos, la volatilidad de los requisitos y los problemas de comunicaci´on.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
229
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Figura 3. Distribuci´on de causas de RTD encontrada en art´ıculos
Estrategias de medici´on de la RTD
P2. ¿Qu´e estrategias se han propuesto para la medici´on de la RTD?
El proceso de medici´on se entiende como la actividad de analizar y cuantificar los costos y esfuerzos necesarios
para gestionar adecuadamente la deuda t´ecnica [8], [9]. En este sentido, es crucial contar con estrategias de
medici´on y cuantificaci´on que permitan evaluar el impacto de la deuda t´ecnica y facilitar una toma de decisiones
m´as efectiva.
Una propuesta relevante de medici´on es la presentada en [16], los autores introducen el concepto de “Veracidad
de requisitos”, una categor´ıa espec´ıfica vinculada a la confianza, autenticidad y demostrabilidad. Los requisitos
de veracidad pueden ser tanto funcionales como no funcionales. Para los requisitos funcionales, se debe verificar
que los datos integrados al software sean correctos. En el caso de los requisitos no funcionales, se debe evaluar
la fiabilidad, disponibilidad y rendimiento, es decir, la manera en que los datos son accedidos, almacenados,
mantenidos y recuperados, como parte de sus atributos de calidad. Seg´un esta perspectiva, la RTD debe
cuantificarse considerando tanto los requisitos funcionales como no funcionales, dependiendo del contexto de
desarrollo.
La propuesta de Perera et al. [16] se alinea con los conceptos del M´etodo de An´alisis Costo-Beneficio (CBAM),
que implica identificar los requisitos con deuda, evaluar el costo de su correcci´on, valorar los beneficios esperados
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
230
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
de dicha correcci´on y calcular cu´ales aportan mayor valor con menor esfuerzo, prioriz´andolos en consecuencia.
Adem´as, se toma en cuenta la Teor´ıa Moderna de la Cartera (MPT), que organiza los requisitos en t´erminos de
su valor y el riesgo asociado a su implementaci´on, seleccionando aquellos que minimicen el riesgo y maximicen
el beneficio. La estimaci´on de la deuda de requisitos de veracidad puede influir significativamente en la selecci´on
de la arquitectura que se implementar´a.
Adem´as, Perera et al. [9], [23] identificaron 57 conceptos relacionados con la cuantificaci´on de la RTD, los cuales
fueron clasificados en cuatro categor´ıas: proceso o tiempo, costo, beneficio y probabilidad. Estos conceptos
fueron agrupados en un total de 14 elementos, los cuales se representaron en un mapa relacional dise˜nado para
modelar los aspectos clave de la cuantificaci´on de la RTD.
a) Costo de implementaci´on de requisitos: Las necesidades del usuario se capturan en requisitos que generan
un costo, el cual corresponde al costo total de la implementaci´on de uno o m´as requisitos formalizados.
b) Modelado de artefactos: Esto incluye aspectos como los “olores de requisitos”, requisitos insuficientes,
incompletos o desfasados.
c) Costo de rectificaci´on de la RTD: Se modela el proceso de rectificaci´on de la RTD, el cual puede incurrir
en un costo dependiendo de la etapa en que se realice. Este costo tambi´en est´a asociado con la atenci´on de
necesidades descuidadas.
d) Inter´es y probabilidad de la RTD: Se considera el costo asociado a la aclaraci´on de un requisito ambiguo, la
realizaci´on de entrevistas adicionales, o la resoluci´on de desajustes. Adem´as, se eval´ua la probabilidad de que
un requisito no tenga impacto.
e) Modelado de componentes de inter´es: Esto incluye el costo adicional relacionado con la realizaci´on de
entrevistas adicionales con los usuarios si las necesidades capturadas est´an incompletas.
f) Beneficio de la rectificaci´on: Se eval´ua tanto el beneficio de rectificar la RTD como el beneficio de abordar
la RTD a corto plazo.
Otra propuesta de medici´on es la presentada en [10], quienes proponen estrategias para cuantificar los tres
tipos de deuda t´ecnica que ellos definen de la siguiente manera:
Tipo 0: Cuantificar el costo de implementar necesidades no atendidas. Esto debe considerar el inter´es
relacionado con la etapa de desarrollo actual, ya que, a medida que se avanza en el desarrollo, el costo
de abordar estas necesidades aumentar´a.
Tipo 1: Cuantificar el costo de corregir los “olores de requisitos”. En este caso, se debe tener en cuenta
el impacto que esta correcci´on tendr´a en otras actividades del proyecto.
Tipo 2: Cuantificar la diferencia entre la implementaci´on actual y los “olores de requisitos”. Esto implica
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
231
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
comparar la implementaci´on existente con los posibles cambios, considerando tanto el costo principal
como el inter´es involucrado. La soluci´on propuesta debe ser la mejor posible para optimizar los resultados.
Por su parte, Melo et al. [20] identificaron 16 estrategias para identificar y medir la RTD, que incluyen la
revisi´on de los requisitos con el cliente, la comunicaci´on, la revisi´on entre pares, el an´alisis de costo-beneficio,
enfoques de cuantificaci´on, el enfoque de vecinos m´as cercanos, diagramas de causa y efecto, acciones de
prevenci´on, mapas de pagos, identificaci´on a trav´es de normas ISO/IEC/IEEE 29148:2018 [26] y plantillas
de documentaci´on. Adem´as, se identificaron varias m´etricas que pueden ser utilizadas para la medici´on, tales
como:
Principal: Esfuerzo requerido para completar una tarea que no ha sido atendida.
Inter´es: Se refiere a la penalizaci´on que se deber´a pagar, es decir, el trabajo adicional necesario para
alcanzar la completitud o correcci´on de los requisitos.
En [20] tambi´en consideran el enfoque de decisi´on si-if, que establece que la deuda debe ser pagada cuando el
costo principal es m´as bajo que el inter´es. Otro enfoque propuesto es el cu´ando-when, que determina cu´ando
debe pagarse la deuda, evaluando si es conveniente hacerlo en el periodo actual o si puede esperar.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
232
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
Figura 4. Temas identificados en la literatura
Discusi´on
Esta Revisi´on Sistem´atica de Literatura (RSL) nos permiti´o investigar el estado actual en cuanto a las causas
de la deuda de requisitos y las propuestas de medici´on realizadas en los ´ultimos cinco a˜nos. Se revisaron 13
art´ıculos que se consideraron relevantes para responder las preguntas de investigaci´on planteadas inicialmente.
Conclusiones y trabajos futuros
Las decisiones tomadas para alcanzar los objetivos dentro de una organizaci´on enfocada en el desarrollo de
software recaen sobre los miembros del equipo y pueden tener un impacto significativo en el producto, el equipo,
el cliente y la empresa. Esta RSL ha permitido identificar que el tema de RTD es un ´area de oportunidad para
profundizar en la investigaci´on.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
233
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
*
Agradecimientos Agradecemos al Tecnol´ogico Nacional de M´exico / Instituto Tecnol´ogico de Apizaco, as´ı como
al Consejo Nacional de Humanidades, Ciencias y Tecnolog´ıas, por el apoyo brindado para la realizaci´on de
este trabajo.
*
Contribuci´on de Autor´ıa Maria Janai Sanchez Hern´andez: Conceptualizaci´on,Investigaci´on,Metodolog´ıa,Re-
dacci´on - borrador original. Maria Guadalupe Medina Barrera: Conceptualizaci´on,Supervisi´on,Escritura,
revisi´on y edici´on. Jos´e Federico Ram´ırez Cruz: Metodolog´ıa,An´alisis formal. Blanca Estela Pedroza-M´endez:
Validaci´on,Curaci´on de datos.
Referencias
[1] W. Cunningham, “The WyCash portfolio management system,” ACM SIGPLAN OOPS Messenger, vol. 4,
no. 2, pp. 29–30, 1993.
[2] S. McConnell, “Managing Technical Debt,” 2008, available: www.construx.com/whitepapers.
[3] Z. S. H. Abad and G. Ruhe, “Using real options to manage Technical Debt in Requirements Engineering,”
in 2015 IEEE 23rd International Requirements Engineering Conference (RE), 2015, pp. 230–235.
[4] C. Berenguer et al., “Technical Debt is not Only about Code and We Need to be Aware about It,” in XX
Brazilian Symposium on Software Quality, 2021, pp. 1–12.
[5] F. Martin, “Technical Debt Quadrant,” 2025, available: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html.
[6] N. Brown et al., “Managing technical debt in software-reliant systems,” in Proceedings of the FSE/SDP
workshop on Future of software engineering research, 2010, pp. 47–52.
[7] N. A. Ernst, “On the role of requirements in understanding and managing technical debt,” in 2012 3rd
International Workshop on Managing Technical Debt (MTD), 2012, pp. 61–64.
[8] 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.
[9] J. Perera, E. Tempero, Y. C. Tu, and K. Blincoe, “Quantifying Requirements Technical Debt: A Systematic
Mapping Study and a Conceptual Model,” in 2023 IEEE 31st International Requirements Engineering
Conference (RE), 2023, pp. 123–133.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
234
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
[10] V. Lenarduzzi and D. Fucci, “Towards a Holistic Definition of Requirements Debt,” in International
Symposium on Empirical Software Engineering and Measurement, 2019.
[11] V. Bonfim and F. Benitti, “Requirements debt: causes, consequences, and mitigating practices,” 2022,
pp. 13–18.
[12] V. D. Bonfim and F. B. V. Benitti, “Ontored: Requirements debt ontology,” 2024.
[13] B. Kitchenham et al., “Systematic literature reviews in software engineering – A systematic literature
review,” Inf Softw Technol, vol. 51, no. 1, pp. 7–15, 2009.
[14] G. Tebes et al., “Proceso para Revisi´on Sistem´atica de Literatura y Mapeo Sistem´atico,” 2020.
[15] D. OBrien et al., “23 shades of self-admitted technical debt: an empirical study on machine learning
software,” in Proceedings of the 30th ACM Joint European Software Engineering Conference, 2022, pp.
734–746.
[16] J. Perera et al., “Towards Quantifying Requirements Technical Debt for Software Requirements concerning
Veracity,” 2024, arXiv: 2407.00391.
[17] S. Charalampidou et al., “Integrating traceability within the IDE to prevent requirements documentation
debt,” in 44th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 2018,
pp. 421–428.
[18] V. Lenarduzzi et al., “A systematic literature review on Technical Debt prioritization: Strategies, proces-
ses, factors, and tools,” Journal of Systems and Software, vol. 171, 2021.
[19] M. Soliman, P. Avgeriou, and Y. Li, “Architectural design decisions that incur technical debt — An
industrial case study,” Inf Softw Technol, vol. 139, 2021.
[20] A. Melo et al., “Identification and measurement of Requirements Technical Debt in software development:
A systematic literature review,” Journal of Systems and Software, vol. 194, p. 111483, 2022.
[21] J. Frattini et al., “An initial theory to understand and manage requirements engineering debt in practice,”
Inf Softw Technol, vol. 159, p. 107201, 2023.
[22] M. E. Nielsen and C. Madsen, “Stakeholder influence on technical debt management in the public sector:
An embedded case study,” Gov Inf Q, vol. 39, no. 3, 2022.
[23] J. Perera et al., “Modelling the quantification of requirements technical debt,” Requir Eng, vol. 29, no. 4,
pp. 421–458, 2024.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
235
Revista Innovaci´on y Software
Vol. 6, No. 2, Mes Septiembre - Febrero, 2025
ISSN: 2708-0935
P´ag. 217-236
https://revistas.ulasalle.edu.pe/innosoft
[24] M. Zakeri-Nasrabadi and S. Parsa, “Natural Language Requirements Testability Measurement Based on
Requirement Smells,” 2024, arXiv: 2403.17479.
[25] G. Robiolo et al., “Technical Debt and Waste in Non-Functional Requirements Documentation: An Ex-
ploratory Study,” 2019, arXiv: 1909.12716.
[26] ISO/IEC/IEEE, “Systems and software engineering – Life cycle processes – Requirements engineering,”
2025, available: https://standards.ieee.org/ieee/29148/6937/.
Facultad de Ingenier´ıa
Universidad La Salle, Arequipa, Per´u
facin.innosoft@ulasalle.edu.pe
236
