Análise Comparativa da Validação de Requisitos de Software Especificados por Meio de Duas Técnicas de Especificação de Requisitos

Transcrição

1 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de 1 3 Análise Comparativa da Validação de Requisitos de Software Especificados por Meio de Duas Técnicas de Especificação de Requisitos Ulisses Fernandes 1, Marcelo Werneck 1, Glívia Barbosa 1 1 Instituto de Informática Pontifícia Universidade Católica de Minas Gerais (PUC Minas) Belo Horizonte MG Brasil {mwerneck}@pucminas.br,{ufernandes, gliviaangelica}@gmail.com Abstract. In this work, the validation of two software requirements specification techniques is analyzed. Through the execution of controlled experiments, a comparative analysis was carried out between requirements validation through text documents as well as prototypes. The validation technique used is performed through Checklists; users access the content of each specification guided through Checklists. Through such analysis, it is possible to identify which technique allows a better validation of requirements specifications by users, considering the type of such specifications is different (textual and visual). It is our goal to identify the specification technique which is more comfortable, better understood by users and that better describes their needs. Resumo. Neste trabalho, é analisada a validação de requisitos especificados por duas técnicas de especificação de requisitos. Através da execução de experimentos controlados, foi realizada uma análise comparativa da validação de requisitos de um sistema especificados por meio de documentos de texto e protótipos navegáveis de software. A técnica utilizada para validar os requisitos foi a Validação por Lista de verificação; usuários avaliaram o conteúdo de cada especificação guiado pela Lista de verificação. Através dessa análise, pretende-se verificar qual técnica de especificação de requisitos permite uma melhor validação pelo usuário, considerando que a natureza das especificações é diferente (textual e visual). Procura-se identificar uma técnica de especificação de requisitos que seja mais confortável, melhor compreendida pelos usuários e que especifique melhor as necessidades destes. 1. Introdução Desenvolver software é tarefa complexa; envolve pessoas e depende da competência da equipe e dos processos utilizados. Processos de desenvolvimento são normalmente divididos em fases, uma dessas é a identificação de requisitos. Os requisitos são identificados e validados com clientes/usuários. [Pfleeger ]. A validação de uma especificação de requisitos tem o objetivo de encontrar defeitos. O custo da correção de defeitos aumenta na medida em que o desenvolvimento progride. Desta forma, deve-se encontrar e corrigir defeitos tão logo sejam introduzidos. [Kalinowski, Spínola e Travassos ].

2 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de 1 Os usuários e/ou clientes do sistema não possuem a mesma visão ou os mesmos conhecimentos técnicos dos analistas, contudo é de extrema importância e relevância que os mesmos participem da validação da especificação de requisitos para que o produto final atenda às expectativas dos mesmos. Geralmente, os requisitos são especificados por meio de documentos textuais ou protótipos. Visualizando as interfaces dos protótipos, o cliente compreende melhor como funcionará o software no mundo real. Além disso, a ambiguidade é reduzida se comparada aos documentos de texto [Nielsen 1993]. Diante desta afirmação, partiu-se da hipótese de que a detecção de defeitos seria mais eficiente por meio de protótipos, uma vez que esses são de mais fácil compreensão para os usuários. Através da verificação por Checklist, procurou-se identificar as diferenças na compreensão e representações dos requisitos por meio de especificações em documentos textuais e na percepção visual de interfaces pelo usuário. Nesse contexto, o objetivo deste trabalho é apresentar uma análise comparativa da validação dos requisitos especificados por duas técnicas de especificação identificando, através de experimentos controlados, 1 os potenciais de detecção de defeitos pelos usuários e qual técnica especifica melhor as necessidades dos mesmos. Além disto, espera-se contribuir para que os alunos da computação identifiquem qual técnica de especificação permite o melhor entendimento do usuário no momento da validação dos requisitos, tornando-os assim, mais criteriosos na escolha da técnica de especificação.. Trabalhos Relacionados [Kirner e Abib 1998] descreve um estudo empírico que compara as técnicas Ad Hoc, Leitura baseada em checklist (LBCh) e Leitura baseada em Cenário (LBCe) e analisa a eficiência em termos de detecção de defeitos em Documentos de Requisitos. Foi constatado que a porcentagem de defeitos detectados pela técnica Ad Hoc (%) foi menor que a relativa à técnica LBCh (5%), que, por sua vez, foi menor que a relativa à técnica LBCe (%). Assim, a técnica LBCe mostrou-se a mais eficiente das avaliadas. [Ciolkowski 1999] relata um estudo empírico comparando a eficiência da LBCh com Leitura Baseada em Perspectiva (LBPe). Os resultados obtidos indicaram uma diferença entre a eficiência de equipes que aplicaram LBCh e de equipes que aplicaram LBPe, sendo que a LBPe mostrou-se mais eficiente. [Bertini et al. ] apresenta um estudo sobre inspeção de documentos de requisitos usando as técnicas LBCh, LBCe e LBPe. O propósito da pesquisa foi avaliar comparativamente as três técnicas, visando identificar o nível de eficiência de cada uma delas no que diz respeito à detecção de defeitos nos documentos considerados. A LBPe apresentou os resultados mais adequados. 1 Experimento controlado é uma investigação de uma hipótese testável na qual uma ou mais variáveis independentes são manipuladas para medir seu efeito em uma ou mais variáveis dependentes. Esse tipo de experimento nos permite constatar uma relação de causa-efeito entre essas variáveis [Shull, F; Singer, J e Sjoberg, D. I. K 8].

3 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de 1 5 Os trabalhos relacionados, descritos acima, analisaram somente técnicas de leitura. Este trabalho se diferencia dos demais, pois visa verificar qual técnica usada na especificação de requisitos, texto ou protótipo, proporciona ao usuário maior entendimento dos requisitos especificados durante a validação dos mesmos, para que a captura de erros, durante a validação, seja mais eficiente e eficaz. 3. Experimentos Um sistema com uma especificação de requisitos textual e protótipo já existentes foi escolhido para o estudo. O sistema foi proposto como trabalho interdisciplinar do curso de Sistemas de Informação da PUC de Minas Gerais. O trabalho contempla conteúdo das disciplinas de Análise de Sistemas de Informação, Bancos de Dados, Projetos de Sistemas de Informação e Interface Homem-Máquina. Os experimentos descritos foram conduzidos em duas turmas de semestres consecutivos da disciplina de Engenharia de Software do 7º período em 8 e 9. O estudo desenvolvido foi aplicado por meio de testes realizados com a participação de alunos do curso com os protótipos e documentos de texto do sistema escolhido. A participação de estudantes, como inspetores em estudos empíricos, tem sido bastante empregada e aceita [Bertini et al. ]. Os alunos selecionados já cursaram as disciplinas envolvidas no trabalho interdisciplinar, ou a maioria delas, garantindo nível similar de conhecimento teórico sobre o assunto. Em cada turma, houve uma divisão em dois subgrupos de tamanho próximo de acordo com a capacidade dos laboratórios das aulas da universidade. Os subgrupos do primeiro semestre tinham cerca de quinze alunos, enquanto os do segundo tinham dez alunos. A divisão dos subgrupos foi realizada com base nos horários de aula dos alunos. Um subgrupo foi responsável pela inspeção da especificação em formato textual enquanto o outro validou os protótipos de telas do mesmo sistema. A inspeção dos artefatos ocorreu por meio de listas de verificação. Os itens dessas listas de verificação serviram para avaliar a forma e conteúdo dos requisitos do software e foram a base para medir o grau de entendimento e a satisfação dos usuários. As listas de verificação de inspeção foram adaptadas da lista de verificação de inspeção do processo Praxis [Filho 8] e priorizaram os itens voltados para o objetivo do trabalho proposto. Houve a preocupação em garantir que as informações fossem transmitidas pelos protótipos da mesma forma que pelos documentos de texto. Uma lista de verificação de rastreabilidade foi elaborada e preenchida. Esta procurou garantir a rastreabilidade entre o conteúdo dos documentos de texto e os protótipos para que ambos pudessem identificar os mesmos tipos de defeitos e se o que estava especificado nos documentos de texto estava nos protótipos e vice-versa. Essa lista foi aplicada em cada caso de uso e interface, garantindo que esses artefatos apresentassem os mesmos tipos de informação. 3.1 Material para Experimentos Para realização dos experimentos, foi necessário elaborar alguns documentos que garantissem a compreensão dos alunos sobre as atividades a serem desenvolvidas. Os roteiros das aulas foram desenvolvidos para os dois subgrupos com a finalidade de explicar a ordem exata das tarefas, assim como os documentos que deveriam ser lidos,

4 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de 1 preenchidos e entregues. Em resumo, cada aluno do grupo de revisão de protótipos e do grupo de especificação textual recebeu os documentos como na Tabela 1. Tabela 1. Documentos recebidos por cada integrante. Grupo de Protótipos Roteiro explicando cada passo e ordem de leitura ou preenchimento dos documentos; Declaração de escopo do trabalho; Especificação final do sistema; Lista de verificação de inspeção de protótipos de telas; Documento com passo-a-passo para execução dos protótipos em C#.NET; Planilha RRSw (Relatório de Revisão de Software) adaptada do Praxis. Cada defeito encontrado é registrado e classificado de acordo com a natureza e gravidade. O documento permite ainda registrar o tempo gasto na tarefa. Grupo de Especificação Textual Roteiro explicando cada passo e ordem das atividades de leitura ou preenchimento dos documentos; A mesma declaração de escopo fornecida aos alunos do grupo de Protótipos; Especificação final do sistema; Lista de verificação de inspeção de documentos textuais; Planilha RRSw (Relatório de Revisão de Software) adaptada do Praxis. Cada defeito encontrado é registrado e classificado de acordo com a natureza e gravidade. O documento permite ainda registrar o tempo gasto na tarefa. Os alunos tiveram 7 dias para realizar a revisão e durante esse tempo puderam analisar os artefatos em quantas sessões julgassem necessárias. Todas as sessões foram registradas na planilha segundo orientações. Ao final, as planilhas foram recolhidas.. Resultados Os alunos classificaram os defeitos encontrados quanto ao tipo e gravidade de acordo com as definições de [Filho 8], conforme Tabela. Tabela. Classificação de defeitos (tipo e gravidade) Tipo de Defeito Descrição Gravidade Descrição Omissão Violação Imprecisão Estilo Outros O artefato não contém uma sessão, algum item importante ou até mesmo não descreve alguma funcionalidade. Incoerência de um item com outro qualquer listado anteriormente em outros documentos do projeto ou algum item incorreto. Ambiguidade em algum requisito ou funcionalidade. Erros de português, formatação ou falta de padrão. Outro tipo de erro listado pelo usuário que não pertence às classificações anteriores. Crítico Maior Menor Defeito que não pode ser contornado e geralmente impede utilização do produto. Deve ser corrigido imediatamente. Pode ser contornado. Prejudica, mas não impede a utilização do produto. Deve ser corrigido o mais rápido possível. São erros que não atrapalham a utilização. Normalmente são melhorias e essas correções podem ser deixadas para as próximas versões. Após recolhidas todas as planilhas, foi realizada uma análise dos dados entregues pelos alunos. Esta etapa consistiu em corrigir erros de preenchimento das planilhas, classificação incorreta dos erros e verificar se os defeitos levantados pelos alunos condiziam com o objetivo do trabalho. Erros referentes à formatação dos

5 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de 1 7 documentos e leiaute das telas de interface, como cores dos botões ou formatação do texto, por exemplo, foram considerados separadamente. Os dados dos experimentos apresentados a seguir referem-se separadamente aos dados obtidos antes e após a análise. Estes últimos são chamados de relevantes. Inicialmente (antes da análise), os alunos encontraram mais erros nos protótipos do que nos documentos de texto. Os gráficos da Figura 1 ilustram essa situação. Número total de erros Média de erros gerais por aluno e desvio padrão ,78 1, 8, 8,1 7,9,9,51 3,87 Média de erros Desvio Padrão Figura 1. (a) Número total e média de erros (b) Média e desvio padrão de erros Após o processo de análise, os erros considerados mais relevantes ao propósito do estudo se concentraram conforme a Figura (a). A Figura (b) apresenta a média de erros relevantes encontrados por aluno e o desvio padrão. É possível notar o alto valor do desvio padrão devido às diferenças na quantidade de erros encontradas pelos alunos. Número total de erros válidos Média de erros relevantes por aluno e desvio padrão ,33 5,8 5, 3,81,8 1,93,1 1,17 Média de erros Desvio Padrão Figura. (a) Número total de erros relevantes (b) Média e desvio padrão de erros relevantes O tempo gasto na realização da revisão foi dividido em preparação e execução. Constatou-se que foi necessário menos tempo para testar e validar os protótipos do que para validar documentos textuais. No entanto, devido à escolha da ferramenta de prototipação, os alunos da primeira turma levaram mais tempo se preparando no caso dos protótipos. Isso incluiu pesquisas sobre a linguagem C#.NET e configurações das interfaces nas máquinas. No caso de documentos textuais, o aluno somente precisou abrir um documento no Office já instalado nas máquinas dos laboratórios de informática. Os gráficos da Figura 3 mostram respectivamente o tempo de preparação média dos alunos e o tempo de execução média da tarefa.

6 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de 1 8 Tempo médio de preparação (horas) Tempo médio de execução (horas) 1: 1 : 57 : 3 : 8 : 1 :58 :53 1:1 1:3 : 5: 8 : : 1: 55: 1 1: : : 57: 3 : 8: 8 :1:7 1:37:8 :: :5:3 : :: Figura 3. (a) Tempo médio de preparação (b) Tempo médio de execução Com relação à classificação dos erros por natureza, pode-se observar na Figura (a) que, no caso de protótipos, os alunos conseguiram capturar muitos erros de estilo, tais como problemas de ortografia, cores dos componentes, inconsistências, enquanto nos documentos de texto outros tipos de defeitos foram observados. Considerando a gravidade dos erros, nos documentos de texto, assim como nos protótipos, os erros encontrados foram considerados, em sua maioria, como menores, conforme Figura (b). No entanto, é possível verificar uma maior ocorrência de erros do tipo crítico e maior se compararmos na Figura (b) Protótipos I e Texto I. Comparativo do total de erros gerais por natureza Comparativo do total de erros gerais por gravidade Omissão Violação Imprecisão Estilo Outros Protótipos - I Texto - I Protótipos II Texto II Protótipos - I Texto - I Protótipos II Texto II Críticos Maior Menor Figura. (a) Erros por natureza (b) Erros por gravidade Considerando apenas erros relevantes, a maioria em protótipos foi de omissão seguida por erros de estilo. Em documentos de texto, a maioria dos erros foi de imprecisão seguidos por omissão, conforme Figura 5(a). Quanto à gravidade, em ambos os casos, a maior quantidade de erros foi de gravidade menor (Figura 5(b)). Comparativo do total de erros relevantes por natureza Comparativo do total de erros relevantes por gravidade Omissão Violação Imprecisão Estilo Outros Protótipos - I Texto - I Protótipos II Texto II Protótipos - I Texto - I Protótipos II Texto II Críticos Maior Menor Figura 5. (a) Erros relevantes por natureza (b) Erros relevantes por gravidade

7 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de 1 9 A Tabela 3 mostra todos os erros encontrados após a filtragem e o percentual desses erros para cada tipo conforme natureza. A Tabela ilustra a quantidade dos erros e a distribuição dos mesmos classificados de acordo com a gravidade. Tabela 3. Natureza dos erros Número e porcentagem de erros relevantes - Natureza Turma I Turma II Classificação / Artefato Protótipo Texto Protótipo Texto Protótipo Texto Protótipo Texto Omissão ,% 33,% 1 9 3,8% 1,1% Violação 1,% 13,3% 13 1,5% 3,% Imprecisão 9 9,7% 3,% ,3% 33,9% Estilo 15 3,7% 13,3% ,% 5,% Outros 3,% 1,% 1 1 1,8% 1,8% Total de erros 1 3 1% 1% % 1% Tabela. Gravidade dos erros Total de erros relevantes nos artefatos - Gravidade do erro Turma I Turma II Classificação / Artefato Protótipo Texto Protótipo Texto Protótipo Texto Protótipo Texto Críticos 9 1,98% 13,91% 1,9% 7,% Maiores 31,3% 38,% 18 1,7%,8% Menores ,99% 7,83% ,% 9,% Total de erros ,% 1,% ,% 1,% Foi possível ainda com esse experimento, analisar a produtividade das duas turmas no levantamento dos erros. Os protótipos mais uma vez se mostraram mais eficientes do que os documentos textuais, conforme ilustram os gráficos da Figura. Produtividade (Número de erros totais por hora) Produtividade (Número de erros relevantes por hora) ,33,33 3,11, ,, 1,7 1, Figura. Produtividade das revisões. (a) Erros totais (b) Erros relevantes No material distribuído aos alunos, foram inseridos alguns erros propositais em ambos os artefatos para medir a eficiência dos revisores e dos tipos de revisão. Nesse caso, os protótipos foram mais eficientes, possibilitando localizar mais facilmente os erros.

8 Instituto de MatemÅtica, UFRJ, 13 a 15 de Abril de Conclusões Neste trabalho, foram analisadas duas especificações de requisitos de software, uma na forma de protótipos navegáveis e a outra em forma de documentos textuais. O objetivo foi analisar qual das técnicas empregadas na especificação permitia ao usuário entender e validar os requisitos de forma mais eficiente, através de listas de verificação. Ambas mostraram eficiência na detecção de erros na análise realizada com os alunos. Os protótipos, por serem navegáveis, apresentaram alto índice de identificação dos erros. No entanto, esses nem sempre foram erros graves que prejudicariam o funcionamento do sistema. Na fase de filtragem de dados, na qual foram tratadas duplicidade de informações e preferências de leiaute, foram capturados erros que não faziam parte do objetivo proposto (validar funcionalmente o sistema). Esses erros muitas vezes se referiam a cores de botões, tamanho e cor da fonte, leiaute das telas, dentre outros que se caracterizam como erros menores. Esses não podem ser ignorados, pois contribuem para a satisfação do usuário final, mas no entanto, fogem do propósito de garantir um sistema que funcione como o usuário requisitou. Os protótipos são mais rápidos de se validar, devido à execução das telas simulando o mundo real. No entanto, eles podem demandar mais tempo de preparo para que o usuário possa validá-lo. Apesar de os resultados apresentados já mostrarem diferenças entre a validação de requisitos especificados com protótipo ou por documentos textuais, mais experimentos são necessários. Pretende-se ainda aplicar os mesmos estudos em novas turmas com outros tipos de usuários e em outros sistemas. Referências Bertini, L. A; Kirner, T. G.; Montebelo, M. I.; Lara, I. A. R. () Técnicas de Inspeção de Documentos de Requisitos de Software: um Estudo Comparativo. In Workshop de Engenharia de Requisitos (WER). Ciolkowski, M. (1999) Evaluating the Effectiveness of Different Inspection Techniques on Informal Requirements Documents. Master Thesis, University of Kaiserslautern, Germany, Filho, W. P. P. (8) Home Page Listas de Conferência. Acesso em: 11/8/8. Disponível em < Kalinowski, M.; Spínola, R. O.; Travassos, G. H. () Infra-Estrutura Computacional para Apoio ao Processo de Inspeção de Software. In: Simpósio Brasileiro de Qualidade de Software,, Brasilia. Kirner, T.G.; Abib, J.C. (1998) Inspection of Software Requirements Documents: A Pilot Study. In: XV International Conference on System Documentation, Nielsen, J. (1993). Usability Engineering. AP Professional, Pfleeger, S. L. (). Engenharia de Software Teoria e Prática. Pearson Prentice Hall, ª edição. São Paulo. Shull, F; Singer, J; Sjoberg, D. I. K (8). Guide to Advanced Empirical Software Engineering. Springer.