Resumo Técnico: Como a Qualidade dos Requisitos Determina (ou Compromete) a Recuperação de Links de Rastreabilidade

Declaração do Problema

Links de rastreabilidade (TLs) que conectam requisitos ao código-fonte são críticos para a manutenção de software, mas estabelecê-los manualmente é propenso a erros e trabalhoso. Abordagens automatizadas de Recuperação de Links de Rastreabilidade (TLR) foram desenvolvidas para enfrentar esse problema, mas assume-se frequentemente que seu desempenho é influenciado pela qualidade dos artefatos de requisitos. Embora pesquisas recentes sugiram que defeitos de qualidade específicos (por exemplo, sentenças carentes de frases nominais ou níveis de abstração inconsistentes) possam impactar a TLR, há uma falta de evidência empírica confirmando esses efeitos ou quantificando sua força. Consequentemente, decisões sobre se deve ou não remediar defeitos de qualidade específicos permanecem baseadas em suposições, e as organizações carecem de orientação sobre quais algoritmos de TLR são mais adequados para seus perfis de qualidade de requisitos específicos.

Metodologia

Este estudo emprega uma abordagem observacional para investigar empiricamente o impacto de fatores de qualidade de requisitos no desempenho da TLR automatizada.

Coleta e Anotação de Dados:

• Datasets: Os autores utilizaram dois conjuntos de dados estabelecidos, eTour (domínio de Turismo) e iTrust (domínio de Saúde), contendo 189 descrições de casos de uso vinculadas a código-fonte Java com links de rastreabilidade padrão-ouro estabelecidos manualmente.
• Fatores de Qualidade: A partir de uma ontologia de fatores de qualidade de requisitos, os autores selecionaram 66 potenciais fatores. Por meio de expertise de domínio e discussão, eles reduziram para 36 fatores relevantes e, finalmente, operacionalizaram 28 fatores mensuráveis (13 rotulados manualmente, 15 rotulados automaticamente via PLN).
• Processo de Anotação: Dois autores rotularam manualmente 599 sentenças e 189 casos de uso. A confiabilidade inter-avaliador foi alta (o kappa de Cohen atingiu 100% nas iterações posteriores). A rotulagem automática utilizou técnicas de PLN e heurísticas (por exemplo, correspondência de palavras-chave para "Negativos", contagem de links de rastreabilidade para "Requisitos Emaranhados").
• Consolidação de Fatores: Os fatores ao nível de sentença foram agregados ao nível de caso de uso (usando razões para variáveis booleanas e máximos para variáveis numéricas). Fatores com distribuição insuficiente (por exemplo, nenhuma instância de "Duplicação Funcional") foram excluídos, restando 16 fatores para análise.

Execução Experimental:

• Abordagens de TLR: Cinco abordagens distintas de TLR não supervisionadas foram executadas nos datasets para recuperar os links:
  1. VSM (Modelo de Espaço Vetorial)
  2. LSI (Indexação Semântica Latente)
  3. FTLR (TLR de grão fino usando embeddings de palavras)
  4. LiSSA_IR-only (Recuperação baseada em embedding apenas)
  5. LiSSA (Geração aumentada por recuperação utilizando LLMs)
• Métricas: O desempenho foi medido usando Precisão, Recall, F1-score e F2-score ao nível de caso de uso.

Análise Estatística:

• Os autores aplicaram um framework de Análise de Dados Bayesiana (BDA) dentro de um paradigma de inferência causal estatística.
• Modelagem: Um Grafo Acíclico Dirigido (DAG) foi construído para modelar as relações causais, tratando o dataset e a abordagem de TLR como variáveis de confusão.
• Estimativa: Modelos de regressão usando distribuições Beta zero-um-infladas foram treinados para estimar a força e a direção do efeito de cada fator de qualidade na performance da TLR.
• Significância: Os efeitos foram avaliados com base em intervalos de credibilidade (CI), considerando fatores com CI de 95% que não sobrepõem o zero como estatisticamente significativos e 50% de CI que não sobrepõe o zero como mostrando um impacto fraco. Efeitos condicionais foram analisados para determinar se diferentes abordagens de TLR responderam de forma distinta aos mesmos fatores de qualidade.

Principais Contribuições

1. Dataset: Um novo conjunto de dados de 28 tipos de defeitos de qualidade de requisitos anotados em 189 descrições de casos de uso de dois projetos reais.
2. Estudo Empírico: O primeiro estudo observacional quantificando o impacto de fatores de qualidade de requisitos específicos no desempenho de múltiplas abordagens de TLR automatizadas.
3. Insights Baseados em Evidências: Evidência estatística demonstrando que a qualidade dos requisitos impacta significativamente a TLR, mas a direção (positiva ou negativa) e a magnitude do impacto variam conforme o tipo de defeito e a abordagem de TLR.

Resultados

Impacto dos Fatores de Qualidade (RQ1)

Dos 16 fatores investigados, 13 mostraram pelo menos um efeito fracamente significativo nas métricas de desempenho da TLR.

• Impactos Negativos: Fatores tradicionalmente considerados defeitos geralmente prejudicaram o desempenho. Especificamente, Requisitos Dispersos (Scattered Requirements), Requisitos Longos, Sentenças iniciando sem uma Frase Nominal, Anáfora e Negativos impediram significativamente a Precisão, o Recall e os escores F1/F2.
• Impactos Positivos: Contrariando as diretrizes tradicionais de engenharia de requisitos, certos "defeitos" melhoraram o desempenho da TLR:
  • Nível de Abstração Inconsistente: Casos de uso contendo detalhes de implementação (informações do espaço da solução) melhoraram ligeiramente o recall e os F2-scores, provavelmente ao reduzir o gap semântico entre requisitos e código.
  • Requisitos Emaranhados (Tangled Requirements): Casos de uso que descrevem múltiplas funcionalidades (alto número de links de saída) geralmente melhoraram a Precisão e os F1/F2 scores.
  • Contém Alternativas: Cenários mistos beneficiaram os F2-scores e o recall.
  • Complexidade de Sentença: Maior complexidade melhorou a Precisão.

Respostas Específicas por Abordagem (RQ2)

Diferentes abordagens de TLR responderam de formas distintas aos fatores de qualidade, indicando que a "melhor" abordagem depende do perfil de qualidade do dataset:

• Nível de Abstração Inconsistente: Todas as abordagens se beneficiaram, mas o VSM mostrou a melhoria mais acentuada, provavelmente devido à sua dependência de correspondência de palavras-chave, que se beneficia da terminologia específica de implementação.
• Requisitos Emaranhados: A abordagem LiSSA_IR-only beneficiou-se significativamente de altos links de saída (melhorando a precisão), enquanto o VSM e o LSI sofreram. FTLR e LiSSA permaneceram estáveis, pois suas arquiteturas (construção de arquivo de código e camadas de classificação, respectivamente) mitigam o efeito.
• Casos de Uso Grandes (Contagem de Passos): O desempenho do VSM melhorou com mais passos (beneficiando-se do aumento da frequência de termos), enquanto o LSI e o LiSSA_IR-only degradaram. O LiSSA (baseado em LLM) permaneceu estável, demonstrando interpretação semântica superior através de múltiplos passos.

Significância e Implicações

O artigo afirma que seus achados fornecem a evidência empírica necessária para mover a avaliação da qualidade de requisitos da intuição para trade-offs baseados em evidências.

• Para Praticantes de TLR: Organizações podem agora avaliar seus requisitos contra os fatores identificados como significativos para prever a aptidão de seus artefatos para a TLR automatizada. Elas também podem selecionar a abordagem de TLR mais apropriada com base nas características de qualidade de seus requisitos (por exemplo, escolher VSM para requisitos com detalhes de implementação, ou LiSSA para casos de uso complexos e de múltiplos passos).
• Para Engenharia de Requisitos: O estudo desafia a rotulação universal de certos fatores como "defeitos". Por exemplo, embora o "Nível de Abstração Inconsistente" seja prejudicial ao design subsequente, ele pode ser benéfico para a TLR. Isso permite que as organizações façam trade-offs informados: decidindo se devem remover um fator com base em seu impacto líquido em múltiplas atividades (ex: design vs. TLR).
• Para o Design de Algoritmos: Os resultados sugerem que futuros algoritmos de TLR devem considerar explicitamente os fatores de qualidade dos requisitos. Por exemplo, algoritmos poderiam ser projetados para alavancar detalhes de implementação ou lidar com requisitos "emaranhados" de forma mais eficaz, em vez de tratá-los como ruído.

Os autores mantêm uma postura modesta, observando que o estudo é limitado a dois datasets e cinco abordagens, e que a operacionalização de alguns fatores depende de heurísticas. Eles posicionam este trabalho como um ponto de partida para investigações contextuais, em vez de um manual definitivo para todos os projetos de software.