Geração Automática da Matriz de Rastreabilidade de Requisitos com suporte de Visualização

Geração Automática da Matriz de Rastreabilidade de Requisitos com suporte de Visualização André Di Thommazo, Gabriel Malimpensa Thiago Ribeiro de Oliveira Guilherme Olivatto Instituto Federal de São Paulo IFSP São Paulo, Brazil andredt@ifsp.edu.br, {ggmalimpensa, guilhermeribeiro.olivatto, thiagoribeiro.d.o} @gmail.com Abstract Background: Requirements management is considered one of the activities responsible for system failures. The difficulty regarding to requirements traceability makes the system changes hard to be managed. Objective: This paper presents two approaches that allow the automated generation of the Requirements Traceability Matrix (RTM): the RTM-E approach, which is based on the requirement input data, and the RTM-NLP approach, which is based on Natural Language Processing-NLP. Method: The RTM-E comprises the requirements dependency related to the data manipulated by them, while the RTM-NLP comprises the requirements dependency related to the similarities of their functionality descriptions. The results are shown through visualization of information in order to facilitate the understanding of such dependencies. Results: We conducted an experimental study in which both approaches were applied to 18 requirements documents. The RTMs created automatically were compared with the reference RTM created manually based on the stakeholders knowledge. Comparing the generated matrices, it was seen that the RTM-E on average matches 82% to the reference RTM, while the RTM-NLP approach on average matches 53%. Conclusions: The results show that generating the RTM based on these approaches, the effectiveness on determining the requirements dependences is satisfactory and motivates to keep studying in order to make improvements for both approaches. Resumo Contexto: O gerenciamento de requisitos é apontado como uma das atividades responsáveis pelo insucesso dos sistemas. A dificuldade associada à rastreabilidade dos requisitos é um fator que pesa negativamente para que as mudanças sejam gerenciadas. Objetivo: Apresentar duas abordagens para automatizar a geração da matriz de rastreabilidade de requisitos (RTM) com suporte de visualização: RTM-E, baseada nos dados de entrada dos requisitos e RTM-NLP, baseada no processamento de linguagem natural (PLN) dos requisitos. Método: A RTM-E explora o fato de que a dependência dos requisitos está associada aos dados manipulados por eles enquanto que o RTM-NLP explora o fato de que a dependência dos requisitos está associada às semelhanças da descrição de suas funcionalidades. Para facilitar a compreensão das dependências, os resultados são mostrados com recursos de visualização. Resultados: Foi conduzido um estudo experimental no qual as duas abordagens foram aplicadas em Sandra C. P. F. Fabbri Universidade Federal de São Carlos UFSCar São Carlos, Brazil sfabbri@dc.ufscar.br 18 documentos de requisitos e as RTMs criadas foram comparadas com a RTM de referência construída com base no conhecimento dos stakeholders. Comparando as matrizes geradas observou-se que a RTM-E coincide em média com 82% da RTM de referência, enquanto que a abordagem RTM- NLP coincide em média com 53%. Conclusões: Os resultados mostram que gerando a RTM com base nessas abordagens a efetividade da determinação da dependência dos requisitos é satisfatória e motiva a continuidade do estudo buscando melhorias nas duas abordagens. Keywords-component: requirements traceability; requirements management; requirements traceability matrix. I. INTRODUÇÃO Apesar do software fazer parte do cotidiano das pessoas há algum tempo, ainda hoje a indústria de software enfrenta desafios de gerar produtos que atinjam as expectativas dos clientes, obedecendo prazos, custos e critérios de qualidade. Pesquisas do instituto Standish Group [1] mostram que no ano de 2009, a quantidade de projetos que foi finalizada com sucesso, respeitando prazos, orçamento e, sobretudo, atendendo às expectativas dos clientes, é de apenas 32%. Uma pesquisa realizada anteriormente pelo mesmo instituto [2] determinou que os três primeiros fatores mais importantes (somando 37% dos projetos investigados) para definir o sucesso ou insucesso de um projeto de software são: falta de especificação do usuário, requisitos incompletos e mudança nos requisitos. Esses fatores estão diretamente relacionados com o gerenciamento de requisitos. De acordo com Salem [3], em 2006 a situação relatada pelo Standish Group [2] continuava e, segundo o autor, a maioria dos erros dos software era fruto de erros na fase de levantamento de requisitos e do acompanhamento de sua evolução ao longo do processo de desenvolvimento. Um dos pontos fundamentais para o gerenciamento de requisitos é a matriz de rastreabilidade de requisitos (RTM), que registra o relacionamento existente entre os requisitos de um sistema. Pela sua importância, ela é foco de várias pesquisas. Sundaram, Hayes, Dekhtyar and Holbrook [4], por exemplo, comentam que os métodos automáticos de

geração de rastreabilidade podem reduzir significativamente os esforços e custos para criar e manter a rastreabilidade de requisitos e a RTM. Segundo os autores, a determinação da rastreabilidade é essencial em muitas atividades da engenharia de software. No entanto, essa determinação é uma tarefa sujeita a erros, que consome muito tempo e que, portanto pode ser facilitada se contar com suporte computacional. Os autores ainda destacam que esse suporte é pequeno nas ferramentas existentes. De acordo com Wang, Lai and Liu [5], existem pesquisas investigando formas automáticas de rastreabilidade, especialmente com vetor de modelo espacial, uso de semântica ou modelos de redes de probabilidade. Sobre o modelo com vetor espacial pode-se destacar o trabalho de Hayes, Dekhtyar e Sundaram [6]. Com relação a semântica, Hayes, Dekhtyar e Sundaram [7] utilizaram a proposta de Deerwester, Dumais, Furnas, Landauer e Harshman da Latentic Semantic Indexing (LSI) [8] para também identificar de forma automática a rastreabilidade. Quando se faz uso da LSI, não se considera somente a frequência das palavras, mas busca-se também significado e contexto em suas construções. Sobre o modelo de Redes de Probabilidade, as propostas de Baeza-Yates, Berthier e Ribeiro-Neto [9] utilizam o ProbIR (Probabilistic Information Retrieval) para criar uma matriz onde a dependência entre cada termo é mapeada em relação aos demais termos dos documentos. Todas essas propostas citadas também são detalhadas no trabalho de Cleland- Huang, Gotel, Zisman [10] como abordagens para de detecção de rastreabilidade. As técnicas para geração da rastreabilidade de requisitos, em geral mostram a rastreabilidade dos RFs com uso de uma matriz. Entretanto, esse tipo de visualização não permite que seja feita uma rápida análise da dependência entre os requisitos do sistema. Heim, Lohmann, Lauenroth e Ziegler [11] destacam que a maioria das ferramentas de gerenciamento de requisitos não fornece visualização baseada em grafos, indicando ainda a importância dessa visualização para que possam ser tratados aspectos multidimensionais do relacionamento dos requisitos. Dado esse contexto, este grupo de pesquisa tem explorado alternativas para minimizar os problemas decorrentes dessa fase de engenharia de requisitos, tais como: i) a técnica TUCCA (Technique for Use Case Construction and Construction-Based Requirements Analysis) que tem por objetivo sistematizar a construção do Modelo de Casos de Uso sendo que, simultaneamente, é feita uma inspeção do documento de requisitos [12]; ii) a definição de um template para a descrição de requisitos baseado em trabalhos propostos na literatura [13] e; iii) a ferramenta COCAR que dá suporte a várias atividades do ciclo de desenvolvimento de software, baseadas nos requisitos e no modelo de casos de uso [14]. Algumas das atividades presentes na COCAR são o gerenciamento de requisitos, geração dos pontos por casos de uso e a geração de casos de teste com base em casos de uso. Assim, dando continuidade a esses trabalhos anteriores, com o intuito de contribuir com a melhoria da qualidade do gerenciamento de requisitos, o objetivo deste artigo é apresentar duas abordagens para elaboração da RMT, além de apresentar um estudo experimental para quantificar a eficácia de cada uma das propostas. Para possibilitar a realização desse estudo experimental, as abordagens foram implementadas na ferramenta COCAR. Uma dessas abordagens está baseada na intersecção dos dados de entrada dos requisitos funcionais (RF) e a outra em processamento de linguagem natural (PLN). O estudo experimental que foi realizado para avaliar as abordagens propostas, envolveu dezoito documentos de requisitos (DR) de diferentes sistemas. O artigo está organizado da seguinte forma: na Seção II abordam-se as formas de gerenciamento de requisitos, rastreabilidade e RMT. A visualização de dependência entre requisitos é discutida na Seção III. Na Seção IV apresentamse as duas abordagens para a criação automática da RMT, exemplificando-se a geração das RMTs na ferramenta COCAR. A Seção V apresenta o estudo experimental para avaliação da eficácia das abordagens. As conclusões e os trabalhos futuros são comentados na Seção VI. II. FORMAS DE GERENCIAMENTO DE REQUISITOS O gerenciamento de requisitos é uma atividade que deve ocorrer ao longo de todo desenvolvimento e que tem como principais objetivos organizar e armazenar os requisitos, bem como gerenciar suas mudanças [15] [16]. Como os requisitos estão em constante mudança, o gerenciamento de requisitos se torna uma fase dispendiosa e trabalhosa, fazendo com que o suporte de ferramentas seja relevante para conduzi-la [5]. De acordo com o Standish Group [17], apenas 5% dos software são desenvolvidos com uso de ferramentas de gerenciamento de requisitos, o que pode explicar, em parte, os grandes problemas das empresas de software em implantar uma gerência efetiva de requisitos e manter a sua rastreabilidade. Vários autores ressaltam a importância de ferramentas para esse propósito [15][16][18][19]. Zisman e Spanoudakis [16], por exemplo, consideram que o apoio de ferramentas seja o único caminho para o sucesso do gerenciamento de requisitos. Dois conceitos importantes para o gerenciamento de requisitos são: rastreabilidade de requisitos e matriz de rastreabilidade. A. Rastreabilidade de Requisitos A rastreabilidade de requisitos refere-se à habilidade de descrever e acompanhar a vida de um requisito [20]. Esse controle do requisito deve abranger toda a sua existência, desde a fonte de origem quando o requisito foi elicitado, especificado e validado, passando pela fase de projeto, implementação e terminando na fase de teste do produto. Assim, a rastreabilidade é uma técnica que permite a identificação e visualização do relacionamento de dependência entre os requisitos elicitados e entre os requisitos e os demais artefatos gerados ao longo do desenvolvimento do software. O conceito de dependência não significa, necessariamente, relação de precedência entre

os requisitos, mas sim o quanto eles estão acoplados, quer seja em termos de dados, de funcionalidade ou outra perspectiva qualquer. Segundo Guo, Yang, Wang, Yang e Li [20], a rastreabilidade de requisitos é uma importante atividade no gerenciamento de requisitos, uma vez que ela pode fornecer base para a evolução das mudanças nos requisitos, além de atuar diretamente na garantia da qualidade do processo de software. De acordo com Zisman e Spanadousk [16] existem dois tipos de rastreabilidade: Horizontal: quando o relacionamento entre os requisitos acontece entre diferentes artefatos. Nesse caso, acompanhase como o requisito foi definido no DR, como ele passou para a modelagem, depois para o código fonte e chegou até a atividade de testes. Vertical: quando os requisitos são analisados em um mesmo artefato, como por exemplo o DR. Analisando-se os RFs desse artefato, é possível identificar o relacionamento entre eles e, a partir desta informação, gerar a RTM. Munson e Nguyen [21] afirmam que as práticas de rastreabilidade só serão melhores quando forem apoiadas por ferramentas que reduzam o esforço requerido para executálas. B. Matriz de Rastreabilidade de Requisitos - RTM De acordo com Goknil, Kurtev, Van den Berg e Veldhuis [22], apesar de existirem várias pesquisas que tratam da rastreabilidade entre os requisitos e outros artefatos, uma menor atenção é dada para o relacionamento dos requisitos entre si, isto é, a rastreabilidade vertical. Os autores também afirmam que esse relacionamento influencia várias atividades durante o desenvolvimento de software, tais como a verificação de consistência dos requisitos e gerenciamento de mudanças. De acordo com Sommerville [15], uma forma para mapear essa dependência entre os requisitos é a criação da RTM. Cuddeback, Dekhtyar e Hayes [23] relatam que a RTM dá suporte a muitas atividades de engenharia de software e atividades de validação e verificação, tais como análise de impacto de mudanças, engenharia reversa, reuso e testes de regressão. Além disso, eles também dizem que a geração de RTMs é trabalhosa e sujeita a erros, motivos para que, frequentemente, ela não seja gerada ou atualizada. Conforme mencionado anteriormente, a RTM indica o relacionamento existente entre os requisitos do software da seguinte forma: cada RF é representado em uma linha e uma coluna da matriz e a dependência entre os requisitos são registradas na célula correspondente à intersecção linha/coluna [15]. Diversos autores [15] [20] [21] [22] [27] comentam a importância e a necessidade da RTM para o processo de desenvolvimento de software, uma vez que essa matriz permite a previsão do impacto de uma mudança ou da inserção de um novo requisito no sistema. Sommerville [15] enfatiza a dificuldade de se obter e manter esse tipo de matriz e, além disso, propõe que a indicação da dependência entre os requisitos determine, além da existência ou não de relação entre eles, uma forma de registrar, subjetivamente, se esse relacionamento é forte ou fraco. III. VISUALIZAÇÃO DA DEPENDÊNCIA DE REQUISITOS Segundo Gershon, Eick e Card [24], a visualização é um processo de transformar os dados, informações e conhecimentos em forma visual, fazendo uso da capacidade visual natural dos seres humanos, fornecendo uma interface entre dois sistemas de tratamento da informação: a mente humana e o computador. Hernandes [25] relata que com interfaces visualmente eficazes, é possível interagir rapidamente com grandes volumes de dados e descobrir características, padrões e tendências camufladas. De acordo com Merten, Juppner e Delater [26] a representação visual dos links de rastreabilidade é vital para o entendimento geral dos requisitos e de suas relações com outros requisitos e outros artefatos de software. A IBM [27] destaca a visualização de requisitos como um dos passos que devem ser seguidos para um melhor gerenciamento de requisitos. Segundo Heim, Lohmann, Lauenroth e Ziegler [11] as ferramentas de gerenciamento de requisitos utilizam listas, tabelas, árvores e matrizes para a visualização de requisitos e seus relacionamentos. Além disso, os autores destacam que essas formas tem limitações para mostrar relações múltiplas entre os requisitos. Para Gotel, Marchese e Morris [28] a visualização de requisitos deve apresentar formas para representação da dependência entre os requisitos, dando suporte a diagnósticos e tomada de decisão no processo de desenvolvimento de software. IV. ABORDAGENS PARA GERAÇÃO DA RTM E VISUALIZAÇÃO DE DEPENDÊNCIAS ENTRE REQUISITOS Nesta seção serão apresentadas duas abordagens (RTM-E e RTM-NLP) para a geração da RTM que, no estágio atual da pesquisa, consideram apenas os RFs do software. As duas abordagens estabelecem o grau de relacionamento entre os RFs, dois a dois. Essas abordagens e a visualização de seus resultados estão implementadas na ferramenta COCAR. O uso de uma ferramenta para dar suporte às técnicas propostas é importante pois, segundo Kannenberg e Saiedian [18], a deficiência das ferramentas de suporte é talvez o maior desafio para implementação da rastreabilidade no processo de desenvolvimento de software. Como mencionado anteriormente, a ferramenta COCAR dá suporte à execução de algumas tarefas relacionadas ao gerenciamento de requisitos. Dentre elas, para que as abordagens aqui propostas pudessem ser implementadas, utilizou-se a funcionalidade do cadastramento dos requisitos, a qual já havia sido implementada anteriormente. Assim, com relação ao cadastramento dos requisitos, a COCAR utiliza o template definido por Kawai [13], o qual está baseado em padrões de documentos de requisitos existentes na literatura. O principal objetivo desse template é padronizar o registro dos RFs e evitar inconsistências, omissões e ambiguidades. Kannenberg e Saiedian, [18] consideram altamente desejável o uso de uma ferramenta para automatizar a tarefa de registro dos requistos. Dos campos definidos nesse template, dois merecem destaque para a implementação das abordagens propostas:

- Entrada: é um atributo do template que registra os dados de entrada que são manipulados em cada RF. Esse atributo é importante, pois permite que sejam registrados, de forma organizada e estruturada, os dados utilizados em cada requisito funcional, o que torna viável a implementação da abordagem RTM-E. - Processamento: é um atributo do template que contém, o fluxo de atividades ou ações que o sistema deve realizar em cada RF. Esse atributo é, em geral, o campo com maior conteúdo de texto. Nesse campo são aplicadas as técnicas de PLN para a criação da RMT de acordo com a abordagem RTM-NLP. A matriz gerada pela abordagem RTM-E será chamada RTMe e a matriz gerada pela RTM-NLP será chamada RTMnlp. As abordagens são detalhadas na sequência. A. Abordagem RMT-E: geração da RTM baseada nos dados de entrada Na abordagem RMT-E a relação de dependência entre os RFs é determinada pelo percentual de dados de entrada coincidentes entre cada par de RFs. Nessa abordagem a dependência é mapeada com uso do Índice de Jaccard [29]. Esse índice é utilizado para comparação de similaridade e diversidade entre conjuntos de dados. A apresentação desse índice está na Equação 1. J A,B O numerador é dado pela quantidade de dados da intersecção entre os dois conjuntos (A e B) enquanto o denominador é constituído pela quantidade de dados da união entre esses dois conjuntos. A abordagem RTM-E define a dependência entre dois RFs da seguinte forma: considerando RFa o conjunto de dados de entrada de um requisito funcional A e RFb o conjunto de dados de entrada do requisito funcional B, a dependência entre eles é dado pela Equação 2: J RFa,RFb Assim, de acordo com a abordagem RTM-E, cada posição (i,j) da matriz de rastreabilidade RTM(i,j) corresponde ao valor da Equação 3: As posições da diagonal principal da RTM não são calculadas, uma vez que indicam a dependência entre os RFs com eles mesmos. Além disso, a matriz gerada é simétrica, ou seja, RTM(i,j) é igual a RTM(j,i). A implementação dessa abordagem na COCAR foi possível porque a forma de armazenamento dos requisitos, utilizando o template mencionado, separa atomicamente os dados de entrada de cada requisito. Sendo assim, cada vez que um dado de entrada é inserido em um RF na ferramenta ele fica disponível para ser vinculado em outros RFs, evitando possível ambiguidade dos dados, uma vez que se (1) (2) RTM i,j J RF-i, RF-j (3) evita que um novo dado de entrada com o mesmo propósito seja inserido, algo que poderia gerar inconsistência nos RFs. Vale destacar que não foram encontradas na literatura iniciativas que fizessem uso de dados de entrada de RFs para determinação automática da RTM. Iniciativas semelhantes existem para a determinação de links de rastreabilidade entre outros artefatos, especialmente modelo (diagramas da UML) e código fonte, como nos trabalhos de Cysneiros e Zisman [32]. Para apresentar e exemplificar a geração da matriz segundo a abordagem RMT-E será utilizada uma aplicação real relativa a um sistema desenvolvido para uma empresa de aviação privada. Esse sistema informatiza toda a parte de estoque da empresa. Como a empresa tem bases em várias cidades, o sistema gerencia vários estoques e os produtos que serão inseridos, retirados ou realocados em seus diversos estoques. O sistema possui um total 14 RFs, que são representados na Figura 1 pelas primeira linha e primeira coluna da RTM. Todos os RFs foram inseridos na ferramenta COCAR. Na Figura 1, a célula da matriz destacada pelo retângulo sinaliza a dependência entre o RF3 e o RF5. No caso, o RF3 está relacionado com a entrada ou saída de produtos de um determinado estoque (armazém) da empresa, e o RF5 referese à transferência de um item de um estoque para outro. Como esses dois RFs tratam de itens de estoque é natural que exista relacionamento entre eles. O RF3 possuía os seguintes dados de entrada: Contato, Data da Transação, Armazém, Quantidade, Preço unitário e Usuário. O RF5 por sua vez tinha como dados de entrada: Contato, Data da Transação, Armazém, Quantidade, Preço unitário, Usuário, Armazém de origem, Armazém destino e Status. Como a quantidade de elementos do conjunto interseção de RF3 e RF5 (n(rf3 RF5)) era 6 e a quantidade de elementos do conjunto união dos mesmos requisitos funcionais (n(rf3 RF5)) era 9, aplicando-se o indicador proposto para a RTM-E para estabelecer a dependência entre RF3 e RF5 tem-se na Equação 4: J RF3,RF5 3 5 3 5 6 9 66.67% (4) Essa dependência de 66.67% está destacada na Figura 1, que corresponde à RTMe construída com a abordagem. Vale destacar que as cores indicam o nível de dependência mapeada da seguinte forma: verde para dependência fraca e vermelho para dependência forte. Quando não existe relacionamento a célula não é colorida. A Figura 2 ilustra os conjuntos intersecção e união dos dados de entrada quando a abordagem RTM-E é aplicada nos requisitos RF3 e RF5 utilizados anteriormente. Vale ressaltar que para minimizar o erro de cadastro de requisitos a ferramenta COCAR apresenta uma lista das entradas já cadastradas para que os mesmos dados de entrada não sejam cadastrados com nomes diferentes.

B. Abordagem RMT-NLP: geração da RTM baseada em processamento de linguagem natural Muito embora existam iniciativas que fazem uso de PLN para determinação da rastreabilidade no processo de desenvolvimento de software, poucos trabalhos tratam da rastreabilidade dentro de um mesmo artefato[22]. No caso no caso do uso de PNL para criação de RTM, a proposta existente na literatura não utiliza um template de descrição de requisitos como é feito neste trabalho. Além disso, nesta proposta também são determinados níveis de dependência. De acordo com Deeptimahanti e Sanyal [30], o uso de PLN na engenharia de requisitos não tem o objetivo de compreensão do texto em si, mas sim a função de extrair conceitos contidos no DR. Sendo assim, a segunda abordagem proposta para estabelecer a RTM utiliza os conceitos extraídos dos RFs por meio de PLN, para determinar a rastreabilidade entre os RFs. PLN é aplicado no campo que descreve o processamento (ações) do RF. Para determinar o nível de dependência entre os conteúdos dos campos de processamento de dois RFs utiliza-se o método do Vetor de Frequência e a Similaridade do Cosseno [31]. Esse método retorna o percentual de similaridade entre dois trechos de texto. Nível de Dependência entre RF3 e RF5 gerado com a abordagem RTM-E Figura 1 RTM gerada com uso da abordagem RTM-E Dados de Entrada do RF3 1. Contato 2. Data da Transação 3. Armazém 4. Quantidade 5. Preço unitário 6. Usuário intersecção dos dados de entrada união dos dados de entrada Dados de Entrada do RF5 1. Contato 2. Data da Transação 3. Armazém 4. Quantidade 5. Preço unitário 6. Usuário 7. Armazém de origem 8. Armazém destino 9. Status Figura 2 Exemplo de união e intersecção entre dados de entrada de dois RFs Antes da aplicação do Vetor de Frequência e Similaridade do Cosseno, é feito um pré-processamento do texto, com o intuito de aumentar a eficiência do método. Sendo assim, inicialmente é retirado do texto o conjunto de palavras que podem ser consideradas irrelevantes, como por exemplo artigos, preposições e conjunções, o qual é denominado stopwords (Figura 3-A). Depois, é aplicado o processo conhecido por steaming (Figura 3-B), que reduz as palavras a seus radicais, fazendo com que elas tenham o mesmo peso para determinação de similaridade entre os textos. Após essas duas etapas, o método determina a similaridade entre os textos de dois RFs (Figura 3-C) relativos ao campo processamento do template, identificando aqueles que, segundo a técnica, são similares. O primeiro passo para a aplicação do Vetor de Frequência e Similaridade do Cosseno é a representação de cada sentença em um vetor. Nesse vetor, cada posição é preenchida por uma palavra da sentença. A medida do cosseno entre eles irá representar a similaridade. Considerando dois RFs RF1 e RF2 descritos respectivamente pelas sentenças S1 e S2. O cálculo da similaridade é feito da seguinte forma: 1- Representação de S1 no vetor x e S2 no vetor y. Cada palavra irá ocupar uma posição em cada vetor. Se S1 tiver p palavras, o vetor x também possuirá p posições inicialmente. Da mesma forma, se S2 possuir q palavras, o vetor y também possuirá q posições.

2- No vetor não deve ocorrer repetição de palavras. Sendo assim, as ocorrências de cada palavra devem ser contadas para determinar a sua frequência no vetor. Feito isso as repetições são retiradas, deixando-se no vetor apenas uma ocorrência por palavra. Além da palavra também é colocada em cada posição do vetor a frequência com que ela apareceu em cada sentença. 3- Reordenação dos vetores em ordem alfabética. 4- Cruzamento de cada termo dos vetores, buscando correspondentes no outro vetor. Quando não houver a palavra no outro vetor, deve ser inserida uma posição equivalente no vetor que não tem a palavra, com frequência igual a zero. Sendo assim, cada palavra que exista em S2 e que não exista em S1 dará origem a uma posição vazia no vetor x, com frequência zero. Dessa forma, após a aplicação desse passo, surgirão novas posições em ambos os vetores, representando os valores que não tem correspondente com o outro vetor. Ao final dessa etapa, ambos os vetores possuirão o mesmo número de posições. Entrada Pré-processamento 5- Com os vetores ajustados, deve ser aplicada a Equação 5 de similaridade entre os vetores x e y sim (x,y) - considerando n o número de posições dos vetores. Considerando o mesmo exemplo usado para ilustrar a abordagem RTM-E (sistema de estoque de empresa de aviação privada) foi gerada a RTMnlp (Figura 4) avaliando a similaridade entre as funcionalidades dos RFs, as quais foram inseridas na COCAR no atributo processamento do template mencionado anteriormente. Sendo assim, após o pré-processamento (retirada dos stopwords e steaming) e aplicação dos passos descritos acima do Vetor de Frequência e Similaridade do Cosseno, a similaridade textual entre o RF3 e o RF5 que tratam respectivamente da inserção de produtos no estoque e da transferência de produtos entre estoques, foi determinada como 70,46% (Figura 3-D). Faz sentido o valor alto (70,46%) nesse relacionamento, uma vez que o texto que descreve as duas funcionalidades é similar. (5) Texto do RF3 Texto do RF5 Remover Stopwords (artigos, preposições, conjunções) Steaming redução das palavras em seus radicais Vetor de Frequência e a Similaridade do Cosseno [31] Dependência entre RF3 e RF5 (70.46%) A B C D Figura 3. Passos para aplicar a abordagem RTM-NLP Nível de dependência entre RF3 e RF5 gerado pela abordagem RTM-NLP Figura 4. RTM gerada com uso da abordagem RTM-NLP C. Visualização da Dependência entre osrfs Com base na importância da visualização de requisitos, conforme mencionado na Seção III, a primeira solução proposta na ferramenta para facilitar a compreensão e o nível de dependência entre os RFs da RTM foi a utilização de cores na própria matriz. Dessa forma, é possível visualizar mais facilmente o nível de dependência entre os RFs, uma vez que as dependências fortes são marcadas na matriz com a cor vermelha, as dependências fracas em verde e quando não existe dependência a célula não é sombreada com nenhuma cor. Essa visualização com cores nas matrizes pode ser observada nas Figuras 1 e 4. Os critérios utilizados para definir a dependência como forte ou fraca foram baseados na análise das matrizes geradas. Para a RTM-E, valores iguais e maiores que 50% indicam alta dependência. Valores abaixo de 50% e maiores que zero, indicam dependência fraca. No caso da RTM-NLP, o mesmo critério não poderia ser aplicado, uma vez que em poucos casos a similaridade entre os textos é igual a zero,

pois é muito usual haver termos do texto do processamento dos RFs que são coincidentes. Dessa forma, considerou-se que a dependência até 15% na RTM-NLP será considerada como inexistente. Para determinar esse valor de 15% foram feitos testes com 3 sistemas piloto. Constatou-se que usar o ponto de corte como 15% era suficiente para minimizar a ocorrência de falsos positivos. Valores inferiores a 15% criavam muitos links de rastreabilidade que na realidade não existiam. Valores muito superiores a 15% faziam com que alguns links não fossem indicados pela abordagem. Ressaltase que esses valores podem ser ajustados na própria ferramenta COCAR e são valores que devem ser estudados em trabalhos futuros para que se verifique se os intervalos são ou não dependentes da aplicação em questão. Apesar de melhorar a visualização da RTM com cores, a dependência multi-dimensional dos RFs é difícil de ser compreendida se representada por uma matriz. Sendo assim, foi criada na ferramenta COCAR a visualização da RTM com auxílio de grafos. Nesse caso, cada RF se torna um nó do grafo. A ligação entre cada um dos RFs é feita por arestas coloridas com as mesmas cores utilizadas na matriz, indicando se a relação é fraca (verde) ou forte (vermelha). A Figura 5a exemplifica como é representada a matriz gerada pela abordagem RTM-E com recurso de visualização em grafo. Observa-se que cada dependência que foi registrada na matriz com a cor verde, deu origem a uma aresta de mesma cor. As dependências que foram marcadas em vermelho, ou seja, dependências fortes, foram indicadas no grafo com aresta de cor vermelha. É possível ainda notar que existem RFs que não possuem dependência com nenhum outro RF e, portanto, não estão ligados por arestas com outros RFs (ver os RFs que estão na parte inferior da Figura 5a). Com o objetivo de permitir uma análise mais detalhada, a ferramenta COCAR possibilita a visualização das dependências a partir de um RF específico. Para exemplificar essa visualização, foi usado como referência o RF3 anteriormente. Essa visualização está ilustrada na Figura 5b. (a) (b) Figura 5. (a) Visualização do relacionamento entre todos os RFs. (b) Visualização do relacionamento do RF3 com os demais. V. ESTUDO EXPERIMENTAL Para medir a eficácia das abordagens propostas foi realizado um estudo experimental com as seguintes características: - Contexto: O estudo experimental foi realizado com alunos da disciplina de Linguagem de Programação II do curso de graduação em Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação, Ciência e Tecnologia de São Paulo (IFSP) no campus São Carlos. Como atividade da disciplina, cada aluno deveria desenvolver uma aplicação que envolvesse um stakeholder real. Além disso, o DR deveria ser criado na ferramenta COCAR. - Objetivo: avaliar a eficácia das abordagens RTM-E e RTM-NLP em comparação com a RTM de referência (chamada RTM-Ref) construída a partir da análise criteriosa do DR. A criação da RTM-Ref será detalhada em seguida. - Participantes: 18 alunos de graduação do curso Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto Federal de São Paulo, campus São Carlos. - Artefatos utilizados: DR, com as seguintes características: o elaborado pelos próprios alunos: o referente a uma aplicação de utilidade prática real; o relativos a aplicações de sistemas de informação com as funcionalidades básicas de cadastro, recuperação, atualização e exclusão de dados. o deveria possuir um stakeholder real, com amplo conhecimento do sistema que seria desenvolvido. o deveriam ser registrados na ferramenta COCAR.

RTM-Ref o criado a partir do DR registrado na ferramenta COCAR. o elaborado com base na leitura e análise detalhada de cada par de RF e determinando a dependência entre esses RFs como nula, fraca ou forte. o registrado em uma planilha para que a matriz RTM-Ref criada pudesse ser comparada com a RTMe e RTMnlp de cada sistema. o construída pelos autores deste trabalho com consulta ao aluno autor do DR, sempre que houvesse alguma dúvida. Em alguns casos foi necessário que o aluno fizesse contato com o stakeholder para avaliar a dependência entre os RFs, melhorando a especificação do DR e indicando o relacionamento de forma correta. - Métrica: a métrica utilizada foi a eficácia das abordagens RTM-E e RTM-NLP no que diz respeito à coincidência das dependências encontradas por cada abordagem em relação à RTM-Ref. A eficácia é dada pela relação entre a quantidade de relações encontradas corretamente em cada abordagem pela quantidade total de possíveis relacionamentos existentes entre os RFs. Considerando um sistema com n RFs, a quantidade total de possíveis relacionamentos (T) é dado pela Equação 6: 1 (6) 2 Sendo assim, a eficácia é dada pela Equação 7: E icácia (7) - Resultados: Os resultados da comparação entre os dados da RTM-Ref com a RTM-E e RTM-NLP estão apresentados na Tabela 1. A primeira coluna tem o nome do sistema que foi especificado. Na segunda coluna está a quantidade de RFs. A terceira coluna é composta pelo total de possíveis dependências (forte, fraca e nula) que podem existir entre os RFs, ou seja, é composta pelo total de células que ficam abaixo da diagonal principal da matriz e dada pela Equação 6. A quarta coluna tem o total de relacionamentos coincidentes entre as matrizes RTM-E e RTM-Ref. Por exemplo: se na RTM-Ref foi determinada uma dependência forte em uma célula e a abordagem RTM-E também registrou a dependência como forte na mesma posição, então contabiliza-se um relacionamento correto. A eficácia da abordagem RTM-E é dada pela relação da quantidade de dependências encontradas corretamente por essa abordagem (quarta coluna) pelo total de dependências que poderiam ser encontradas (terceira coluna). Os valores da eficácia da abordagem RTM-E estão disponíveis na quinta coluna. A sexta coluna mostra o total de relacionamentos coincidentes entre as matrizes RTM-NLP e RTM-Ref. A sétima coluna mostra a eficácia da abordagem RTM-NLP, calculada pela divisão entre a quantidade de dependências encontradas corretamente pela abordagem RTM-NLP (sexta coluna) pelo total de dependências que poderiam ser encontradas (terceira coluna). TABELA 1 RESULTADOS DO ESTUDO EXPERIMENTAL Sistema Quantidade Possibilidade de RTM-E RTM-E RTM-NLP RTM-NLP de Requisitos dependências (T) Corretos Eficácia (%) Corretos Eficácia(%) Sistema Natação 30 435 376 86 235 54 Controle de Estoque 17 136 135 99 78 57 Sistema de Compras 15 105 075 71 58 55 Venda Livros 19 171 112 65 61 36 Sistema para Hotel 16 120 097 81 72 60 Vendas Cosméticos 15 105 093 89 67 64 Vendas Eletrônicos 15 105 095 90 45 43 Gestão de Moradia 19 171 139 81 87 51 Consultório Médico 16 120 089 74 67 56 Manutenção/Hardware 14 091 072 79 56 62 Loja de Roupas 20 190 156 82 72 38 Grupo de Jovens 19 171 156 91 98 57 Gestão CDs e DVDs 18 153 125 82 72 47 Gamer 18 154 123 80 69 45 Sist. Personal Trainner 15 105 093 89 63 60 Gestão de Projetos 16 120 092 77 64 53 Gestão de Tarefas 09 036 028 78 19 53 Marmoraria 16 120 101 84 71 59 - Análise dos resultados: A partir dos dados da eficácia das abordagens propostas é possível observar que a RTM-E mostrou-se mais eficaz que a RTM-NLP. Foi aplicado o teste Shapiro-Wilk para confirmar a distribuição normal dos dados. Comprovada a normalidade dos dados (para RTM-E, p-value = 0.1147; e para RTM-NLP, p-value = 0.1679), foi realizado o teste T para avaliar a confiabilidade. Para a RTM-E tem-se a média de 82,2% com desvio padrão de 7,4% e intervalo de confiança (95%) de 78,2% até 86,1%. Isso indica que os resultados esperados para uma nova aplicação da abordagem deve gerar eficácia dentro dessa faixa de valores. Para a RTM-NLP, tem-se média de 52,8% com desvio padrão de 8,1%. Nesse caso o intervalo de confiança é de 48,3% até 56,5%.

Como a eficácia da abordagem RTM-NLP foi consideravelmente menor que a da RTM-E, fez-se um estudo para investigar os motivos que levaram a esse resultado. Notou-se que em muitos dos casos houve a identificação de falsos positivos, ou seja, dependências foram encontradas quando não havia relação entre os RFs. De acordo com Sundaram, Hayes, Dekhtyar and Holbrook [4] a ocorrência de falsos positivos é uma característica do uso de PLN, embora esse tipo de processamento recupere com facilidade os relacionamentos entre os RFs. No caso da abordagem RTM-NLP os falsos positivos ocorrem, pois muitas vezes o texto do atributo processamento associado com dois RFs diferentes possui palavras em comum que indicam similaridade de ação, embora não exista dependência. Exemplos de palavras que geram esses falsos positivos são cadastrar, recuperar e listar. Soluções para esse tipo de problema estão sendo estudadas para aprimorar essa abordagem. Uma das propostas é o uso de um Tagger, que classifique cada termo da linguagem natural em sua classe gramatical (artigo, preposição, conjunção, verbo, substantivo ou adjetivo). Dessa forma, os verbos também poderiam ter um peso diferente dos substantivos no cálculo de similaridade. Quando essa proposta for implementada deve também ser avaliada por meio de um estudo experimental para avaliar sua eficácia. Sendo assim, direciona-se o processamento para encontrar os substantivos com peso maior. Um ensaio preliminar, realizado manualmente, mostrou que essa alternativa aumenta a eficácia da detecção dos relacionamentos que realmente existem. Na análise dos dados da RTM-E, não ocorreram falsos positivos. As dependências encontradas, mesmo que fracas, realmente existiam. Esperava-se também encontrar erros onde deveriam ser indicados relacionamentos forte e no entanto foram indicados como fraco pela abordagem. Isso ocorria pois muitas vezes a dependência entre os dados de entrada de um RF estava relacionada com os dados de saída de outro RF, e não com os seus dados de entrada. Assim, essa melhoria na abordagem RTM-E está sendo avaliada mais profundamente, para também ser incorporada na abordagem RTM-E. O estudo possui alguns riscos à validade, podendo-se citar, principalmente, a inexperiências dos alunos para fazer o levantamento de requisitos com os stakeholders. No entanto, por se tratarem de sistemas de informação de domínios conhecidos, considera-se que esse fato minimize a questão da inexperiência. Outro risco é o fato da RTM-Ref ter sido construída por pessoas que não tiveram contato direto com o stakeholder e, portanto, essa matriz pode retratar os eventuais problemas que tenham ocorrido na elaboração dos próprios DRs. Para minimizar esse risco, sempre que houve dúvidas na determinação de um relacionamento, a ajuda do aluno foi solicitada. Em alguns casos foi necessária uma compreensão melhor dos requisitos junto ao stakeholder, o que certamente minizou a ocorrência de erros na criação da RTM-Ref. VI. CONCLUSÕES E TRABALHOS FUTUROS Este artigo apresentou duas abordagens que possibilitam a geração da matriz de rastreabilidade de requisitos RTM de forma automática. A primeira delas, RTM-E, é baseada no percentual de dados de entrada comuns entre os RFs, dois a dois. A segunda abordagem, RTM-NLP, faz uso de PLN para determinação do nível de dependência entre os requisitos. Além das abordagens para gerar a matriz de rastreabilidade de forma automática, também foi implementada na ferramenta COCAR uma funcionalidade que permite a visualização das dependências entre os RFs por meio de uma representação em grafos. Essa representação facilita a compreensão dos relacionamentos existentes, uma vez que ela possibilita uma visão do todo. Dessa forma, os envolvidos com o projeto podem ter maior clareza para compreender as dependências entre os RFs, do que simplesmente observar as dependências por meio de uma matriz. Das duas abordagens apresentadas, vale destacar que quanto ao uso de PLN para a determinação de links de rastreabilidade, já existem algumas iniciativas na literatura, principalmente envolvendo diferentes artefatos (requisitos e modelos, modelos e código-fonte ou requisitos e casos de testes). Com relação à abordagem RTM-E, não foi encontrada na literatura iniciativa similar. As duas abordagens foram implementadas no ambiente COCAR para que fosse possível a realização do estudo experimental para avaliar a eficácia das abordagens. Nesse estudo a abordagem RTM-E se mostrou mais eficaz que a RTM-NLP. Após o estudo foram identificadas algumas possibilidades para melhorar a eficácia dessas abordagens. As principais contribuições deste trabalho estão incorporadas no ambiente COCAR, e correspondem à geração automática do relacionamento entre os RFs e a visualização desses relacionamentos. Isso favorece a determinação do impacto que a mudança em um requisito pode gerar nos demais. Novos estudos estão sendo conduzidos para melhorar a eficácia das abordagens. Como trabalhos futuros pretende-se aprimorar as técnicas de PLN utilizadas, considerando-se o uso do tagger e a incorporação de um glossário de termos para tratar de sinônimos. Pretende-se também combinar as duas abordagens fazendo com que os dados de entrada possam indicar diferentes pesos no cálculo da similaridade determinado pela abordagem RTM-NLP. Outra investigação que será feita é sobre o auxílio da RTM gerada para o processo de manutenção de software, mais especificamente para o suporte à geração de testes de regressão, uma vez que ambas as abordagens determinam quais as dependências existentes entre os RFs de uma aplicação. REFERENCES

[1] CHAOS Reports 2009 - Standish Group. Available at http://www1.standishgroup.com/newsroom/chaos_2009.php Last access on March, 2012. [2] CHAOS Reports - Standish Group 1994 - Available at http://www.standishgroup.com/sample_research/chaos_1994_2.php Last access on February 2007. [3] A.M. Salem, "Improving Software Quality through Requirements Traceability Models", The 4th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA 2006), Dubai, Sharjah, UAE, 2006. [4] S.K.A. Sundaram, J.H.B. Hayes, A.C. Dekhtyar, E.A.D. Holbrook, "Assessing traceability of software engineering artifacts", 18th International IEEE Requirements Engineering Conference, Sydney,Australia, 2010 [5] X.Wang, G. Lai, C. Liu, "Recovering Relationships between Documentation and Source Code based on the Characteristics of Software Engineering" Electronic Notes in Theoretical Computer Science, 2009 [6] J. H. Hayes, A. Dekhtyar, S. Sundaram,."Advancing Candidate Link Generation for Requirements Tracing: The Study of Methods IEEE Transactions on Software Engineering, Volume 32, No. 1, 2006. [7] J.H. Hayes, A. Dekhtyar, S. Sundaram, Advancing Candidate Link Generation for Requirements Tracing: The Study of Methods IEEE Transactions on Software Engineering, Volume 32, No. 1, (January 2006), 4-19. [8] S. Deerwester, S.T. Dumais, G.W. Furnas, T.K. Landauer, and R. Harshman, Indexing by Latent Semantic Analysis, J. Am. Soc. Information Science, vol. 41, no. 6, pp. 391-407, 1990. [9] R. Baeza-Yates, A.,Berthier, A. Ribeiro-Neto: Modern Information Retrieval. ACM Press / Addison-Wesley, 1999. [10] J. Cleland-Huang, O. Gotel, A. Zisman, Software and Systems Traceability, Springer, 491 p., 2012. [11] P.A. Heim, S.A. Lohmann, K.B. Lauenroth, J.A. Ziegler, "Graphbased visualizations; Requirements analysis; Requirements management tools, Requirements engineering, Visualization", Proceedings of the 2008 Requirements Engineering Visualization, Washington, DC, USA, 2008 [12] A. Belgamo, S.S.P.C. Fabbri e J.C. Maldonado, "Assessing the Quality of GUCCRA technique with Inspection"(in portuguese), WER Workshop em Engenharia de Requisitos, 2005, Porto, Portugal, 2005. [13] K.K. Kawai, "Guidelines for preparation of requirements document with emphasis on the Functional Requirements" (in portuguese). 2005. 170 f. (Master in Computer Cience)- Universidade Federal de São Carlos, São Carlos, 2005. [14] A. Di Thommazo, M. D. C. Martins, and S. C. P. F. Fabbri, Requirements Management in COCAR enviroment (in portuguese) WER 07 - Workshop de Engenharia de Requisitos, 2007, Toronto, Canada. [15] I. Sommerville, Software Engineering. 9th edition New York- Addison Wesley, 2010 [16] A. Zisman e G. Spanoudakis, "Software Traceability: Past, Present, and Future", The Newsletter of the Requirements Engineering Specialist Group of the British Computer Society,September 2004 [17] CHAOS Reports - Standish Group 2005 - Available at URL: http://www.standishgroup.com/sample_research/pdfpages/q3- spotlight.pdf Last access on February 2007. [18] A. Kannenberg, H.Saiedian, Why Software Requirements Traceability Remains a Challenge. CrossTalk: The Journal of Defense Software Engineering. July/August 2009. [19] A. Goknil, I. Kurtev, K. Van den Berg, J.W. Veldhuis, "Semantics of trace relations in requirements models for consistency checking and inferencing", Software and Systems Modeling, Volume 10 Issue 1, February 2011 [20] Y. Guo, M. Yang, J. Wang, P. Yang, F. Li, "An Ontology based Improved Software Requirement Traceability Matrix", 2nd International Symposium on Knowledge Acquisition and Modeling, KAM, Wuhan, China, 2009 [21] E. V. Munson, e T. N. Nguyen, Concordance, conformance, versions, and traceability ; Proceedings of the 3rd international workshop on Traceability in emerging forms of software engineering, Long Beach, California, 2005. [22] A. Goknil, I. Kurtev, K. Van den Berg, J.W. Veldhuis, "Semantics of trace relations in requirements models for consistency checking and inferencing", Software and Systems Modeling, Volume 10 Issue 1, February 2011 [23] D. Cuddeback, A. Dekhtyar, J.H. Hayes, "Automated requirements traceability: The study of human analysts", Proceedings of the 2010 18th IEEE International Requirements Engineering Conference, RE2010, Sydney, Australia, 2010 [24] N. Gershon, S.G. Eick, S. Card, Information visualization interactions. ACM Interactions, Nova Iorque, v. 5, n. 2, p. 9-15, Mar./Apr. 1998. [25] E. C. M. Hernandes, E. C. M., "Automated Data Processing And Conceptualization With Support From Ontologies Visualization" (in portuguese) - Universidade Federal de São Carlos, São Carlos, 2009 [26] T. Merten, D. Juppner e A. Delater, "Improved representation of traceability links in requirements engineering knowledge using Sunburst and Netmap visualizations", 4th International Workshop on Managing Requirements Knowledge, MaRK'11, Trento, Italy, 2011 [27] IBM Report - Available at http://public.dhe.ibm.com/common/ssi/ecm/en/raw14059usen/raw1 4059USEN.PDF Last access on March, 2012. [28] O.C.Z. Gotel, F.T. Marchese, S.J.Morris, "On requirements visualization", 2nd International Workshop on Requirements Engineering Visualization, New Delhi, India, 2007 [29] The Probabilistic Basis of Jaccard's Index of Similarity Avalilable at: http://sysbio.oxfordjournals.org/content/45/3/380.full.pdf Last access on June, 2012 [30] D.K. Deeptimahanti, R. Sanyal, "Semi-automatic generation of UML models from natural language requirements", Proceedings of the 4th India Software Engineering Conference 2011, ISEC'11, Kerala, India, 2011 [31] G. Salton, J. Allan, "Text Retrieval Using the Vector Processing Model",: 3rd Symposium on Document Analysis and Information Retrieval. University of Nevada, Las Vegas, 1994 [32] G. Cysneiros, A. Zisman, "Traceability and Completeness Checking for Agent Oriented Systems". Proceedings of the 2008 ACM symposium on Applied computing, New York, USA, 2008.