Resumen Técnico: Cómo la calidad de los requisitos determina (o arruina) la recuperación de enlaces de trazabilidad

Planteamiento del problema

Los enlaces de trazabilidad (TL, por sus siglas en inglés) que conectan los requisitos con el código fuente son críticos para el mantenimiento de software; sin embargo, establecerlos manualmente es propenso a errores y laborioso. Se han desarrollado enfoques de Recuperación de Enlaces de Trazabilidad (TLR) automatizados para abordar esto, pero a menudo se asume que su rendimiento está influenciado por la calidad de los artefactos de los requisitos. Si bien investigaciones recientes sugieren que defectos específicos de calidad (por ejemplo, oraciones que carecen de sintagmas nominales o niveles de abstracción inconsistentes) pueden impactar la TLR, existe una falta de evidencia empírica que confirme estos efectos o cuantifique su fuerza. En consecuencia, las decisiones sobre si remediar defectos de calidad específicos siguen basándose en conjeturas en lugar de evidencia, y las organizaciones carecen de orientación sobre qué algoritmos de TLR son más adecuados para sus perfiles de calidad de requisitos específicos.

Metodología

Este estudio emplea un enfoque observacional para investigar empíricamente el impacto de los factores de calidad de los requisitos en el rendimiento de la TLR automatizada.

Recolección y anotación de datos:

• Conjuntos de datos: Los autores utilizaron dos conjuntos de datos establecidos, eTour (dominio de Turismo) e iTrust (dominio de Salud), que contienen 189 descripciones de casos de uso vinculadas a código fuente Java con enlaces de trazabilidad de estándar de oro establecidos manualmente.
• Factores de calidad: A partir de una ontología de factores de calidad de requisitos, los autores seleccionaron 66 factores potenciales. Mediante la experiencia en el dominio y discusiones, redujeron esto a 36 factores relevantes y, finalmente, operacionalizaron 28 factores medibles (13 etiquetados manualmente y 15 etiquetados automáticamente mediante PLN).
• Proceso de anotación: Dos autores etiquetaron manualmente 599 oraciones y 189 casos de uso. La confiabilidad inter-evaluador fue alta (el kappa de Cohen alcanzó el 100% en las iteraciones posteriores). El etiquetado automático utilizó técnicas de PLN y heurísticas (por ejemplo, coincidencia de palabras clave para "Negativos", conteo de enlaces de trazabilidad para "Requisitos Entrelazados").
• Consolidación de factores: Los factores a nivel de oración se agregaron al nivel de caso de uso (usando proporciones para variables booleanas y máximos para variables numéricas). Los factores con distribución insuficiente (por ejemplo, sin instancias de "Duplicación Funcional") fueron excluidos, dejando 16 factores para el análisis.

Ejecución experimental:

• Enfoques de TLR: Se ejecutaron cinco enfoques distintos de TLR no supervisados en los conjuntos de datos para recuperar los enlaces:
  1. VSM (Modelo de Espacio Vectorial)
  2. LSI (Indexación Semántica Latente)
  3. FTLR (TLR de grano fino utilizando incrustaciones de palabras/embeddings)
  4. LiSSA_IR-only (Solo recuperación basada en embeddings)
  5. LiSSA (Generación aumentada por recuperación utilizando LLMs)
• Métricas: El rendimiento se midió utilizando Precisión, Recall, F1-score y F2-score a nivel de caso de uso.

Análisis estadístico:

• Los autores aplicaron un marco de Análisis de Datos Bayesianos (BDA) dentro de un paradigma de inferencia causal estadística.
• Modelado: Se construyó un Grafo Acíclico Dirigido (DAG) para modelar las relaciones causales, tratando el conjunto de datos y el enfoque de TLR como variables de confusión.
• Estimación: Se entrenaron modelos de regresión utilizando distribuciones Beta de uno-cero infladas para estimar la fuerza y la dirección del efecto de cada factor de calidad en el rendimiento de la TLR.
• Significancia: Los efectos se evaluaron basándose en intervalos de credibilidad (CI), considerando que los factores con un CI del 95% que no se solapaba con cero eran estadísticamente significativos y un CI del 50% que no se solapaba con cero mostraba un impacto débil. Se analizaron los efectos condicionales para determinar si diferentes enfoques de TLR respondían de manera distinta a los mismos factores de calidad.

Principales contribuciones

1. Dataset: Un nuevo conjunto de datos de 28 tipos de defectos de calidad de requisitos anotados en 189 descripciones de casos de uso de dos proyectos del mundo real.
2. Estudio empírico: El primer estudio observacional que cuantifica el impacto de factores específicos de calidad de requisitos en el rendimiento de múltiples enfoques de TLR automatizados.
3. Información basada en evidencia: Evidencia estadística que demuestra que la calidad de los requisitos impacta significativamente la TLR, pero que la dirección (positiva o negativa) y la magnitud del impacto varían según el tipo de defecto y el enfoque de TLR.

Resultados

Impacto de los factores de calidad (RQ1)

De los 16 factores investigados, 13 mostraron al menos un efecto débilmente significativo en las métricas de rendimiento de la TLR.

• Impactos negativos: Los factores tradicionalmente considerados defectos generalmente obstaculizaron el rendimiento. Específicamente, los Requisitos Dispersos, los Requisitos Largos, las Oraciones que comienzan sin un Sintagma Nominal, la Anáfora y los Negativos impidieron significativamente la Precisión, el Recall y las puntuaciones F1/F2.
• Impactos positivos: Contrario a las directrices tradicionales de ingeniería de requisitos, ciertos "defectos" mejoraron el rendimiento de la TLR:
  • Nivel de Abstracción Inconsistente: Los casos de uso que contienen detalles de implementación (información del espacio de solución) mejoraron ligeramente el recall y los F2-scores, probablemente al cerrar la brecha semántica entre los requisitos y el código.
  • Requisitos Entrelazados: Los casos de uso que describen múltiples funcionalidades (alto número de enlaces de trazabilidad salientes) generalmente mejoraron la Precisión y los F1/F2.
  • Contiene Alternativas: Los escenarios mixtos beneficiaron los F2-scores y el recall.
  • Complejidad de la Oración: Una mayor complejidad mejoró la Precisión.

Respuesta específica de los enfoques (RQ2)

Diferentes enfoques de TLR respondieron de manera distinta a los factores de calidad, lo que indica que el "mejor" enfoque depende del perfil de calidad del conjunto de datos:

• Nivel de Abstracción Inconsistente: Todos los enfoques se beneficiaron, pero VSM mostró la mejora más pronunciada, probablemente debido a su dependencia de la coincidencia de palabras clave, que se beneficia de la terminología específica de la implementación.
• Requisitos Entrelazados: LiSSA_IR-only se benefició significativamente de los altos enlaces salientes (mejorando la precisión), mientras que VSM y LSI sufrieron. FTLR y LiSSA se mantuvieron estables, ya que sus arquitecturas (construcción de archivos de código y capas de clasificación, respectivamente) mitigan el efecto.
• Casos de Uso Grandes (Conteo de Pasos): El rendimiento de VSM mejoró con más pasos (beneficiándose del aumento de la frecuencia de términos), mientras que LSI y LiSSA_IR-only se degradaron. LiSSA (basado en LLM) se mantuvo estable, demostrando una interpretación semántica superior a través de múltiples pasos.

Significancia e implicaciones

El artículo afirma que sus hallazgos proporcionan la evidencia empírica necesaria para mover la evaluación de la calidad de los requisitos de la intuición hacia compensaciones basadas en evidencia.

• Para profesionales de la TLR: Las organizaciones ahora pueden evaluar sus requisitos frente a los factores identificados para predecir la aptitud de sus artefactos para la TLR automatizada. También pueden seleccionar el algoritmo de TLR más apropiado basado en las características de calidad de sus requisitos (por ejemplo, elegir VSM para requisitos con detalles de implementación, o LiSSA para casos de uso complejos de múltiples pasos).
• Para la Ingeniería de Requisitos: El estudio desafía la etiqueta universal de ciertos factores como "defectos". Por ejemplo, aunque un "Nivel de Abstracción Inconsistente" puede ser perjudicial para el diseño posterior, puede ser beneficioso para la TLR. Esto permite a las organizaciones tomar decisiones informadas: decidir si eliminar un factor basándose en su impacto neto a través de múltiples actividades (por ejemplo, diseño vs. TLR).
• Para el Diseño de Algoritmos: Los resultados sugieren que los futuros algoritmos de TLR deberían considerar explícitamente los factores de calidad de los requisitos. Por ejemplo, los algoritmos podrían diseñarse para aprovechar los detalles de implementación o manejar los requisitos "entrelazados" de manera más efectiva, en lugar de tratarlos como ruido.

Los autores mantienen una postura modesta, señalando que el estudio está limitado a dos conjuntos de datos y cinco enfoques, y que la operacionalización de algunos factores depende de heurísticas. Posicionan este trabajo como un punto de partida para investigaciones contextuales en lugar de un reglamento definitivo para todos los proyectos de software.