VALIDAÇÃO DE REQUISITOS - UM CASO PRÁTICO

1.  Resumo

Nos modelos de processo de desenvolvimento convencional é muito comum realizar uma inspeção do documento de requisitos para idenficar os defeitos e assim melhorar a qualidade deste artefato. Neste contexto, geralmente os requisitos são especificados usando a notação de casos de uso. Porém, nos métodos ágeis os requisitos costumam ser representados como User Stories e dificilmente é aplicada alguma técnica de validação de requisitos neles, por causa do tempo de esforço associado à aplicação da técnica. Neste artigo será realizada uma análise das principais técnicas de validação de requisitos e será aplicada uma dessas técnicas em um conjunto de User Stories de um projeto de software real com o objetivo de avaliar se os resultados são afetados pelo nível conhecimento de domínio dos inspetores ou é independente do perfil do inspetor.

2. Introdução

Devido à constante evolução no desenvolvimento de software, milhares de clientes estão cada vez mais exigentes com relação à busca por sistemas que atendam de fato às suas reais necessidades, com um nível de qualidade satisfatório e com baixos custos de manutenção. Resultados de um survey (Ciolkowski et al., 2003) mostram que embora muitas empresas realizem revisões de software, elas o fazem de forma pouco sistemática e pouco conhecimento a respeito das técnicas de validação de requisitos de software é utilizado. Assim o verdadeiro potencial das técnicas de validação de requisitos é raramente atingido. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).

Compreende-se por requisitos como sendo uma condição ou funcionalidade que deve ser atingida ou influenciada por um componente de sistema para satisfazer um contrato, padrão, especificação, ou outro documento formalmente definido. (PRESSMAN, 2006). Para que tais condições e/ou funcionalidades sejam atingidas, é importante haver a prática da engenharia de requisitos, na qual, esta é responsável por abordar o gerenciamento de atividades contribuintes na elaboração de um produto final de qualidade, cujo objetivo é criar um documento de especificação de requisitos de software completo. A engenharia de requisitos é composta pelas fases de desenvolvimento (elicitação, análise, documentação e validação de requisitos.) e de gerenciamento de requisitos. (PRESSMAN, 2006)

Os documentos de requisitos geralmente apresentam problemas relacionados com incompletude, inconsistência, instabilidade, ambiguidade, mudanças repentinas de requisitos, requisitos criados sem o entendimento claro das reais necessidades por parte dos envolvidos no projeto, omissão de informações importantes para uma correta elaboração do sistema, entre vários outros problemas. (ANDERSSON, 2003), (SOMMERVILLE, 2007).

Um fato a ser considerado é que nas etapas inicias de desenvolvimento do software, mais precisamente na etapa de especificação dos requisitos, onde as principais tarefas designadas do mesmo devem ser definidas de maneira objetiva e clara para que futuras anomalias não venham a ocorrer, é onde o maior índice de defeitos tende a surgir. Entende-se defeito por qualquer condição ou situação que leve o sistema a se comportar de maneira inesperada e/ou indesejada, representando um risco para a consecução da missão do sistema. (BERTINI; KIRNER; MONTEBELO; LARA, 2006). 

O objetivo deste artigo consiste em analisar as principais técnicas de validação de requisitos, escolher uma técnica apropriada para usar na validação dos requisitos de um caso prático real, no intuito de avaliar se os resultados são afetados pelo nível conhecimento de domínio dos inspetores ou independem do perfil do inspetor. O caso prático a ser avaliado é composto por user stories. Define-se brevemente user stories como funcionalidades que estarão disponíveis em um sistema de software. (COHN, 2004). User stories são complementadas por descrição, regras de negócio, tarefas, prioridade e observações referentes à funcionalidade a ser desenvolvida. User stories são utilizadas geralmente na metodologia de desenvolvimento ágil, onde esta é focada no desenvolvimento de pequenas funcionalidades a um sistema em períodos de tempos curtos.

Este trabalho está organizado da seguinte forma: na seção 2 são apresentadas as fundamentações teóricas, onde são descritos os conceitos básicos de requisitos e as principais técnicas de validação de requisitos existentes. Na seção 3 são apresentados os trabalhos relacionados com a área de validação de requisitos Na seção 4 é escolhida uma técnica de validação de requisitos e é aplicada sobre um conjunto de requisitos de um projeto de software real, e por último, na seção 5 são descritas as conclusões do trabalho.

3. Fundamentações Teóricas

Nesta seção são apresentados os conceitos básicos necessários para o bom entendimento da análise de trabalhos relacionados e do caso prático.

Os requisitos podem ser classificados em requisitos de usuário e em requisitos de sistema na qual este último ainda pode ser subdividido em requisitos funcionais e requisitos não funcionais.

Entende-se por requisitos de usuários, como sendo declarações, escritas de forma clara e precisa, por meio de diagramas ou linguagem natural, que possibilitam explicitar quais funções e limitações externas o sistema possuirá, focando-se no que será feito e não como será feito. (SOMMERVILLE, 2007).

Com relação aos requisitos de sistema, estes descrevem através de uma linguagem técnica o comportamento de entrada e saída de dados, além das restrições e funções ao qual o software estará submetido, englobando detalhes a respeito dos serviços e funções. (SOMMERVILLE, 2007).

Os requisitos de sistema podem ser classificados em requisitos funcionais e não funcionais sendo que os funcionais são os serviços que o sistema deve oferecer, e os não-funcionais referem-se às condições nas quais deve operar sistema, tais como confiabilidade, usabilidade, disponibilidade, entre outras características. (SOMMERVILLE, 2007).

O processo de engenharia de requisitos está subdividido em duas fases: o desenvolvimento de requisitos e o gerenciamento de requisitos. Na Figura 1 são apresentadas as atividades da fase de desenvolvimento de requisitos, as quais são: elicitação, análise, documentação e validação dos requisitos.

Figura 1 – Fluxo do processo de desenvolvimento de requisitos. Fonte: (Kotonya, Gerald, and Ian Sommerville, 1998).

A seguir são descritas cada uma destas atividades do desenvolvimento de requisitos a começar pela elicitação de requisitos, porque é a partir dela que os requisitos serão levantados e as reais necessidades do cliente serão abordadas. Durante o processo de elicitação, é necessário manter um contato com os usuários e clientes do sistema para entender suas reais necessidades obtendo assim os requisitos do software. Posteriormente à elicitação dos requisitos feito junto ao cliente, o próximo passo é a de analisar os requisitos, onde o principal objetivo é observar a qualidade dos requisitos levantados e verificar se será necessário negociar com o cliente alguma situação identificada depois da análise, como por exemplo, exclusão de um determinado requisito por falta de viabilidade de implementação. Uma vez levantados e analisados os requisitos é necessário documentá-los para que haja uma base sólida a respeito do que será desenvolvido, acordados entre analistas e cliente. O documento de requisitos é escrito em níveis de detalhes compreensíveis a todos os clientes envolvidos.

Por fim, há a etapa de validação dos requisitos, onde neste processo existem revisões com base em todos os requisitos levantados no intuito de eliminar inconsistências, desconformidades, ambiguidades, entre outras discrepâncias que possam ocorrer e que não seriam desejáveis para as próximas etapas do ciclo de vida do desenvolvimento de software.

3.1. Técnicas de validação de requisitos

Considerando que o foco do trabalho é sobre validação de requisitos, nesta seção são detalhadas as técnicas de validação de requisitos mais utilizadas.

• Walkthrough

Walkthrough é uma técnica realizada em equipe, onde esta equipe é composta de alguns peritos sobre o artefato a ser analisado, análises de sistema e realização de testes. Regras devem ser estipuladas em como serem feitas as análises dos artefatos e os participantes envolvidos devem ser treinados nestes procedimentos de análise. O autor do artefato ou o líder da equipe são responsáveis por repassar ou fazer uma checagem do produto, por meio de uma simulação manual do sistema usando dados fictícios para teste. Os dados utilizados para a realização dos testes devem ser simples, levando em consideração os constrangimentos causados por simulações humanas. Para auxiliar o uso da técnica, a equipe responsável deve fazer perguntas e levantar questões que auxiliem na detecção de defetos do produto. (FERREIRA, 2008)

Esta técnica é um processo de uso intensivo de integrantes com custo variando a depender da quantidade de participantes envolvidos na equipe e do tamanho do projeto a ser analisado. Walkthrough possui como característica uma base para que o desenvolvedor identifique os problemas do sistema e a lógica utilizada pelo programador durante a construção do artefato. Uma das desvantagens da utilização desta técnica é que ela é desestruturada, tornando a sua eficiência dependente da experiência e habilidade da equipe envolvida. (FERREIRA, 2008)

• Revisão por Pares (Peer Review)

A Revisão por Pares é um método estático, ou seja, que não depende de codificação e podem ser adotadas desde o início da elaboração do projeto. Ela é realizada em pares de programadores, que geralmente possuem o mesmo nível de conhecimento, com o objetivo de extrair pontos de vista diferentes das possuídas pelo desenvolvedor e efetuar a revisão do material, em busca de problemas de qualidade. (MELO, 2009).

Os resultados obtidos da análise são documentados em relatórios e caso sejam considerados pertinentes, estes seguirão no relatório final de documentação do projeto, para que haja ciência tanto por parte dos clientes, quanto por parte dos desenvolvedores com relação ao que está prestes a ser desenvolvido. (MELO, 2009).

• Inspeções

Ao longo dos anos muitas teorias e técnicas relacionadas com inspeções de software têm sido propostas. Algumas das quais foram avaliadas experimentalmente e são consideradas parte do corpo de conhecimento da área de inspeções de software. Este conhecimento envolve reorganizações do processo (SAUER et al., 2000), heurísticas para escolha de inspetores de acordo com suas características (CARVER, 2003), técnicas de estimativas do número de defeitos em documentos (BIFFL et, al., 2003) e da eficiência das inspeções como um todo (ADAMS, 1999), técnicas de leitura, como por exemplo, as baseadas em checklists (TRAVASSOS et, at., 1999) (SHULL et al., 2001) (MAFRA e TRAVASSOS, 2006) (BARCELOS e TRAVASSOS, 2006), dentre outros. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).

A técnica de inspeção foi desenvolvida por Fagan em 1972, visando inicialmente focar na localização de defeitos na estrutura e código de programas. Posteriormente a mesma foi ampliada para aplicação em outros artefatos de software (como especificações, arquitetura, requisitos etc.) (FAGAN, 1986). Esta técnica atualmente é bastante utilizada por desenvolvedores de software e segundo a literatura o processo de inspeção pode detectar até 90% dos defeitos gerados num processo de desenvolvimento de software. (LANUBILE, 1998; SHULL, 2000; PORTER, 1995; LAINTENBERG, 2001; BLACKBURN, 2001).

A inspeção de software envolve tarefas aonde indivíduos tecnicamente qualificados determinam se um artefato criado possui qualidade satisfatória. Desta forma, a atividade de inspeção contribui não só com a melhoria da qualidade de software, como também com ganhos em custos e tempo. (SAYÃO; STAA; LEITE, 2003).

O processo de inspeção de requisitos caracteriza-se pelo uso de técnicas de leitura aplicáveis a um artefato, buscando a localização de defeitos de maneira rigorosa, eficiente e de baixo custo, segundo um critério pré-estabelecido que possa ser adotado logo nas fases inicias de elicitação de requisitos. Das técnicas de leitura existentes, algumas se encontram em estágio de validação e outras já estão integradas à prática industrial. (LAITENBERGER, 2002). Dentre as técnicas de leitura utilizadas no meio industrial, destacam-se leitura por perspectiva (PBR), ad-hoc e checklist. (SAYÃO; STAA; LEITE, 2003).

Leitura ad-hoc consiste em uma técnica baseada no conhecimento dos inspetores que irão analisar o documento de requisitos através do levantamento das falhas mais comuns que costumam ocorrer no momento da elicitação de requisitos. Ela não é repetível nem passiva de melhorias, já que não existem regras de aplicação da mesma, baseando-se somente nas experiências dos inspetores envolvidos. Por outro lado, ela pode garantir clareza, completude, consistência, corretude, funcionalidade, testabilidade e bom detalhamento a cerca do sistema a ser elaborado. (SAYÃO, STAA e LEITE, 2003) e (MELO, 2009).

Já na técnica de leitura PBR, ou técnica de perspectiva, consideram-se diferentes visões dos atores envolvidos no projeto, cada um focando-se em diferentes módulos do sistema a serem estudados. Cada ator possui diferentes formas e procedimentos de levantar questões críticas sobre o sistema em busca falhas. Esta técnica permite detectar ausências de informação, ambuiguidades de requisitos,   inconsistências, informações desnecessárias, dentre outros problemas. (SAYÃO, STAA e LEITE, 2003).

Na técnica de leitura por checklist, o que existe são listas previamente criadas que permitem analisar o sistema relacionando o que deve ser verificado e o que deve ser considerado como erro oriundo da má elicitação de requisitos. O uso desta técnica leva os inspetores a analisarem minunciosamente os principais pontos originadores das falhas, por outro lado, características mais discretas não abordadas nos checklists, dificultarão a detecção de erros nas fases subsequentes do projeto. Quando bem aplicada, esta técnica pode garantir correções a respeito de sintaxe, inconsistências de informações, requisitos não funcionais não explicados de maneira objetiva, ambuiguidade de requisitos, informações redundantes ou inexistentes e exceções de funcionalidades não consideradas até então. (SAYÃO, STAA e LEITE, 2003).

Para a aplicação correta dos tipos de técnicas citadas, as Inspeções necessitam ter um processo de realização bem definido (figura 2). A seguir são detalhadas as etapas do processo de inspeção de requisitos definido por (SAUER, 2000).

• Planejamento – Um usuário desempenhando o papel de moderador da inspeção define o contexto da inspeção (descrição da inspeção, técnica a ser utilizada na detecção de defeitos, documento a ser inspecionado, autor do documento, entre outros.), seleciona os inspetores e distribui o material a ser inspecionado. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).
• Detecção de Defeitos – Cada um dos inspetores selecionados pelo moderador realiza a detecção de defeitos. A principal tarefa desta atividade consiste em buscar defeitos no documento a ser inspecionado, produzindo uma lista de discrepâncias. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).
• Coleção de Defeitos – O moderador agrupa as listas de discrepâncias dos inspetores e elimina discrepâncias repetidas (encontradas por mais de um inspetor), mantendo só um registro para cada discrepância. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).
• Discriminação de Defeitos – O moderador, o autor do documento e os inspetores discutem as discrepâncias. Durante esta discussão, as discrepâncias serão classificadas como falso positivo ou defeito. Os falsos positivos serão descartados e os defeitos serão registrados em uma lista de defeitos. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).
• Retrabalho – O autor do documento corrige os defeitos da lista de defeitos e produz um relatório de correção dos defeitos. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).
• Continuação – O moderador decide se uma nova inspeção deve ou não ocorrer. (KALINOWSKI, SPÍNOLA, NETO, BOTT e TRAVASSOS, 2007).

Figura 2 – Visão do processo de Inspeção de Software. Fonte: (Porto, 2009).

Cada grupo de participantes envolvidos no processo de realização da inspeção possui um papel específico. Os principais papéis usados na prática são: Moderador, Autor do artefato a ser inspecionado e Inspetores.

4. Trabalhos Correlatos

Nesta seção são descritos alguns trabalhos de pesquisa coletados com o objetivo de demonstrar a importância da aplicação da técnica de inspeção de requisitos.

Silvia, Chapetta e Travassos (2004) em seus trabalhos, foram motivados a desenvolverem uma ferramenta capaz de apoiar a aplicação da técnica de inspeção de requisitos através da técnica de leitura por perspectiva. Nesta ferramenta os objetivos eram de fornecer um guia para a execução das tarefas especificadas pela técnica de inspeção, facilitar ainda mais o relato das discrepâncias identificadas no momento da validação dos requisitos, fornecer ajuda direcionada aos inspetores envolvidos nas análises e verificar a conformidade da aplicação da técnica, ou seja, assegurar que os inspetores iriam fazer a utilização correta da técnica sobre um determinado produto.

A aplicação ao qual se propunha a ferramenta desenvolvida, contou com a colaboração de alguns estudantes de pós-graduação, dos quais a maioria possuía experiência na aplicação da técnica de leitura por perspectiva. Os estudantes analisaram um documento de requisitos referente a um sistema de vídeo locadoras, com o intuito de analisar a viabilidade da ferramenta proposta com relação à localização de falhas importantes nas fases iniciais do desenvolvimento do sistema.

De acordo com os conclusões extraídas pelos autores deste trabalho, os resultados da detecção de falhas mostrou-se semelhante, com ou sem o uso da ferramenta desenvolvida, embora um fato positivo foi uma redução, segundo os desenvolvedores, no tempo de inspeção dos requisitos.

Plagliuso, Tambascia, Boas, Freitas e Levantezi (2003) realizaram um trabalho com o intuito de elaborar um método de validação de documento de requisitos resultante de um estudo de caso sobre o módulo de Operação do  CPqD  Gerência  da  Planta.

Um único documento de requisitos foi estudado por meio de ambas as técnicas de inspeção de requisitos, perspectiva e ad-hoc. Na aplicação da técnica ad-hoc, foram utilizados três inspetores e um total de cinco etapas para análises. A primeira etapa estava relacionada com coleta de informações, as etapas intermediárias voltadas para revisões realizadas e a última etapa relacionada com a conclusão do documento após as correções. Já para o experimento com base na técnica de perspectiva, apenas dois inspetores foram envolvidos, testador e o usuário, utilizando-se mecanismos de suposição de erros. Nesta técnica apenas três etapas foram realizadas, onde a primeira consiste a coleta de informações, a segunda relacionada a revisões dos requisitos e a terceira voltada para conclusão e correções de falhas encontradas.

As conclusões extraídas foram as de que utilizando a técnica ad-hoc e inspetores com conhecimento do domínio, constatou-se que 45% das desconformidades encontradas estavam relacionadas a informações incorretas e 30% a informações inconsistentes. Utilizando a técnica de perspectiva e inspetores com e sem conhecimento do domínio constatou-se que 65% das desconformidades encontradas estavam relacionadas à omissão de informações.

Kalinowski, Spínola, Neto, Bott e Travassos (2007), em seu trabalho, focaram em relatar a experiência da aplicação da técnica de inspeção de requisitos no desenvolvimento de módulos de um novo sistema de informação para gerenciamento de atividades da Fundação COPPETEC. Atores, inspetores e moderadores foram os participantes envolvidos na aplicação da técnica de inspeção, e cada um deles recebeu treinamentos distintos referentes a uma visão geral do processo e como realizar as atividades ligadas às suas funções.

Inicialmente houve atividades de planejamento onde o moderador envolveu os inspetores com diferentes perspectivas diante do sistema na busca por falhas. Durante a busca por falhas, cada inspetor analisava o documento de requisitos, relatando discrepâncias de acordo com a severidade (média, baixa e alta, esta última em sua maioria relatada por especialistas do domínio.), descrição das falhas, localização das falhas no documento de requisitos e classificação dos tipos de falha (omissão, ambiguidade, etc.). Após o levantamento dos defeitos encontrados, o moderador listava os mais recorrentes, para serem discutidas pela equipe de inspeção e serem encaminhadas para o autor do documento, para serem feitas as devidas correções.

Foi constatado que as maiorias das falhas encontradas nas fases iniciais de desenvolvimento estavam relacionadas com a omissão de informações relevantes. Uma observação a ser feita é que para este trabalho não foram utilizadas técnicas de leitura específicas, embora o uso delas ajude a aumentar a eficiência dos inspetores na busca por falhas.

Travassos e Santos (2009) elaboraram uma pesquisa com base no desenvolvimento de um sistema de informação Web para gerenciamento de atividades de uma Fundação de Apoio a projetos de Ciência e Tecnologia. Este sistema foi dividido em módulos e desenvolvido seguindo um ciclo de vida incremental baseados em casos de uso. No momento do estudo, a equipe do projeto estava dividida em três projetistas e dois desenvolvedores na sede principal e mais seis desenvolvedores em uma sede secundária.

Com o uso das inspeções baseadas na técnica de leitura ad-hoc, pôde-se verificar que a aplicação desta técnica permitiu localizar diversos defeitos. No entanto, mesmo com o bom histórico da aplicação da técnica ad-hoc sobre os módulos estudados, as equipes de projetistas e desenvolvedores enfrentaram dificuldades no entendimento em alguns modelos de casos de uso aplicados nos módulos. Por isto, buscou-se viabilizar e avaliar a aplicação da técnica de leitura checklist sobre os módulos a serem desenvolvidos.

De acordo com os resultados obtidos pelos estudantes deste trabalho, a principal expectativa do grupo foi atingida no que diz respeito ao tempo gasto para a aplicação tanto da técnica ad-hoc, quando da técnica de checklist. Outro fator positivo foi que com o uso de checklist, a quantidade e os tipos de defeitos encontrados foram superiores se comparado ao uso da técnica ad-hoc.

Bertini, Kirner, Montbelo e Lara (2007) realizaram um estudo com objetivo de comparar a eficiência entre as técnicas de inspeção de requisitos (checklist, perspectiva e cenário) no que diz respeito ao número de defeitos encontrados. O estudo foi realizado com base em um sistema de controle médico utilizado para avaliar se exposições a determinados riscos estavam gerando algum tipo de lesão a funcionários de empresas.

Este trabalho foi feito por quinze engenheiros de software com experiência profissional como analistas de sistemas, distribuídos em três equipes de inspeção, onde pelo menos um de cada equipe era moderador e o outro relator de defeitos. Foram necessárias quatro horas, distribuídas em duas sessões. A primeira sessão durou uma hora e consistiu na explanação sobre o documento de requisitos, o uso das inspeções e as três técnicas de inspeções a serem abordadas.  As outras três horas foram utilizadas para a aplicação das técnicas sobre o sistema estudado.

Os resultados obtidos através dos testes destacou-se que em relação ao quesito eficiência, a técnica de perspectiva e de cenário mostraram-se superiores com base na detecção de defeitos de desempenho omitidos. A técnica de checklist mostrou-se superior com relação à detecção de defeitos do tipo interface omitida. Com relação á experiência dos inspetores, os que possuíam mais experiência não executaram melhor a inspeção do que aqueles com menos experiência.     

5. Estudo de Caso

O Projeto Bahia Database Modeler tem como objetivo desenvolver uma ferramenta de modelagem de banco de dados e teve seu início realizado por alunos de graduação da Universidade Salvador. Este projeto contém um conjunto de User Stories para cada nível de modelagem de banco de dados (conceitual, lógico e físico), para este estudo de caso será validado o conjunto de User Stories do nível conceitual. A técnica de validação a ser usada é a técnica de leitura baseada em checklists.

A equipe de inspeção foi composta por sete profissionais, sendo 1 moderador, 1 desenvolvedor, 1 usuário final, 1 planejador de testes, 2 especialistas de domínio e 1 gerente. A classificação quanto aos tipos de defeitos analisados foram omissão, ambiguidade, inconsistência, fato incorreto, informação estranha e outros (TRAVASSOS; SANTOS, 2010), descritos brevemente abaixo:

• Omissão: A não inclusão de algum requisito importante que esteja relacionado às funcionalidades ou restrições do projeto;
• Ambiguidade: Várias definições para um único requisito, por conta de diferentes conceitos aplicados às mesmas funcionalidades e/ou restrições;
• Inconsistência: Conflitos gerados entre dois ou mais requisitos;
• Fato Incorreto: De acordo com as condições que devem ser ofertadas no sistema, um requisito pode descrever um fato ou situação não verdadeira;
• Informação Estranha: Requisitos que estejam incompletos e que forneçam informações insuficientes;
• Outros: Defeitos relacionados com a inserção de requisitos em seções incorretas;

O checklist utilizado na aplicação da técnica foi organizado em 26 itens de avaliação, sendo que os mesmos foram agrupados por critérios de qualidade, como pode ser observado na Figura 3, onde pode se visualizar um fragemento do checklist. Os critérios de qualidade considerados na validação realizada foram: completude, ambiguidade, corretude, relevância, realizabilidade e a testabilidade.

Cada item de avaliação era disposto de um ID, apenas para uma melhor identificação do que estava sendo avaliado no momento. No Campo Item de Avaliação estavam dispostas questões que auxiliariam na análise de acordo com o critério de qualidade a ser verificado da user story em questão. Com relação à coluna Conformidade, o inspetor preenchia (Sim ou Não), caso entendesse que o item avaliado no momento apresentasse algum tipo de defeito, descrevendo-o em seguida no campo Observações o motivo de ter preenchido este campo, ou seja, o porquê de não haver conformidade no item analisado. É importante entender que como cada inspetor poderia tecer observações sobre o que foi por ele considerado defeito, caberia ao moderador definir se o mesmo item avaliado por diferentes inspetores seriam considerados um, dois ou mais defeitos. O campo Severidade era preenchido pelo moderador, onde este ditava o grau de impacto (Alto, Médio e Baixo) no desenvolvimento do sistema que o defeito encontrado poderia ter na user story analisada. No campo User Story/Seção, o inspetor apenas descrevia qual era o item (RN, Tarefa, Descrição) da user story que estava sendo analisada no momento. Por fim a coluna Tipo de Defeito que auxiliava o inspetor a identificar o provável tipo de defeito que o mesmo estava encontrando no momento da aplicação da técnica de checklist.

Figura 3 – Fragmento da checklist utilizado na experiência.

Foram necessárias 10 horas para o planejamento da inspeção de requisitos, que incluiu as seguintes atividades: decidir o processo de inspeção a ser usado; a categoria de defeitos; a categoria de severidade; a elaboração do checklist e a definição dos procedimentos para aplicar a técnica. O esforço médio dos inspetores foi de aproximadamente uma hora e dez minutos tendo em consideração que apenas dois participantes tinham experiência acadêmica e/ou profissional na aplicação da técnica de leitura checklist e conhecimento total do domínio. Durante a aplicação do checklist, existiram algumas interrupções por parte dos inspetores para esclarecer dúvidas com o moderador ou para realização de tarefas divergentes da aplicação da técnica. Porém estas pausas foram contabilizadas e descontadas do tempo de esforço de aplicação da técnica por parte do inspetor.

Para cada item de avaliação analisado por cada inspetor, o moderador definiu o nível de severidade correspondente, para ter um critério uniforme em relação à definição de serveridade do defeito. Além disso, o moderador separou todos os itens considerados como descartados. Um item de avaliação foi considerado descartado se o inspetor preencheu de uma forma que evidenciasse erro de procedimento de uso do checklist ou caso o inspetor tenha identificado como defeito quando na realidade não é um defeito, chamado de falso positivo nesta situação.

Ao final da aplicação da técnica de checklist foram encontrados no total 39 (trinta e nove) defeitos. Nas figuras 4 e 5 é exibida a porcentagem de defeitos encontrados classificando-os por níveis de severidade e os tipos de defeito, respectivamente.

Figura 4 – Porcentagem de defeitos classificados por níveis de severidade.

Figura 5 - Porcentagem de defeitos classificados por tipos de defeitos.

A maioria dos defeitos encontrados foi de severidade alta o e o tipo de defeito mais encontrado foi relacionado à omissão de informações importantes declaradas nas user stories. Alguns itens foram descartados do resultado da experiência, por serem considerados falsos positivos ou erros de procedimento. Na figura 6 é exibida a quantidade de itens descartados por participante.

Figura 6 – Quantidade de itens descartados de acordo com cada participante.

De acordo com a figura 6, pode-se observar que nenhum falso positivo foi encontrado por inspetores que possuíam um nível alto de conhecimento de conceitos de modelagem de banco de dados, o que não aconteceu com inspetores que possuíam nível médio e baixo de conhecimento.

Nas tabelas 1 e 2, respectivamente, são descritas informações referentes ao nível de conhecimento em conceitos de modelagem de banco de dados e a respeito do tempo de experiência em especificação de requisitos, especificação de requisitos com user stories, modelagem de banco de dados, uso da ferramenta de modelagem de banco de dados a ser analisada e sobre inspeção de artefatos de cada participante.

Tabela 1 – Nível de conhecimento em conceitos de modelagem de banco de dados dos participantes

Tabela 2 – Tempo de experiência, em meses, dos participantes.

Na figura 7, apresenta-se a quantidade de defeitos encontrados por cada inspetor. É importante ressaltar mais uma vez que a maioria dos defeitos foi considerada de severidade alta e estes foram encontrados principalmente por especialistas de domínio.

Figura 7 – Gráfico da quantidade de defeitos encontrados por inspetor.

6. Conclusões

Este trabalho teve como objetivo analisar as principais técnicas de validação de requisitos, escolher uma técnica apropriada para usar na validação dos requisitos de um caso prático real, com o intuito de avaliar se os resultados são afetados pelo nível conhecimento de domínio dos inspetores ou é independente do perfil do inspetor.

O custo e a dedicação dos inspetores para a realização desta experiência pode ser considerada como baixa, levando-se em consideração o tempo gasto para a aplicação do checklist, que foi de aproximadamente uma hora. Vale salientar que não foi feita a utilização de apoio ferramental para a coleta de informações.

Ao final da contagem de defeitos contabilizados pelo moderador, 39 (trinta e nove) defeitos foram encontrados, dos quais a maioria eram classificados como do tipo omissão de informações, sendo este tipo de defeito o mais encontrado também nos trabalhos relacionados. Além disto, a maioria dos defeitos encontrados foi considerada de severidade alta, e foram identificados principalmente pelos inspetores que possuíam maior nível de conhecimento do domínio.

A quantidade de falsos positivos e erros de procedimentos relatados pelos inspetores menos experientes mostraram-se superiores quando comparados com os resultados dos inspetores mais experientes. Um fato interessante é que os inspetores menos experientes que possuíam nível de conhecimento baixo e/ou médio de conceitos de modelagem de banco de dados, também tiveram condições de detectar defeitos com o auxílio da estrutura do checklist.

7. Referências

ADAMS, T. (1999) - A Formula for the re-inspection decision.

ANDERSSON, C. - Exploring the Software Verification and Validation Process with Focus on Efficient Fault Detection, Licentiate Thesis, Lund Institute of Technology (LTH), Universidade Lund, Suécia, 2003. Disponível em: . Último acesso em: 01/06/2012

BIFFL, S.; Halling, M.; Koeszegi, S. (2003) - Investigating the Accuracy of Defect Estimation Models for Individuals and Teams Based on Inspection Data, Proceedings of the 2nd International Symposium os Empirical Software Engineering, Rome, Italy.

BARCELOS, R.F.; TRAVASSOS, G.H. (2006) - ArqCheck: Uma abordagem para inspeção de documentos arquiteturais baseada em checklisN- In: V Simpósio Brasileiro de Qualidade de Software, Vila Velha – ES.

BERTINI, L.A; KIRNER, T.G; MONTEBELO, M.I.; LARA, I. A.R. - Técnicas de Inspeção de Documento de Requisitos de Software: Um Estudo Comparativo – Workshop em Engenharia de Requisitos, Rio de Janeiro, RJ, Brasil, Julho 13-14, 2006, pp 67-74. Disponível em: Último Acesso: 05/06/2012

BLACKBURN, M. R.; BUSSER, R.; NAUMAN, A.  Removing Requirement Defects and Automating Test.  Software Productivity Consortium NFP, 2001

Disponível em: Último Acesso: 05/06/2012

CARVER, J. (2003) - The Impact of Background and Experience on Software Inspections - PhD Thesis, University of Maryland, USA.

CARSON, J. S. II - Model Verification and Validation. 2002 - Brooks-PRI Automation 1355 Terrell Mill Road Building 1482, Suite 200 Marietta, GA 30067,  EUA. Disponível em:. Último acesso em: 01/06/2012

COHN, Mike. – User Stories Applied For Agile Software Development 1° Ed. Addison-Wesley Professional, 2004.

FAGAN, M. - Advances in Software Inspection, IEEE Transactions on Software Engineering, Vol. SE-12, NO. 7. – 1986 Disponível em: Último acesso em: 03/05/2012

FERREIRA, B. - Uma técnica para validação de processos de desenvolvimento de software - Dissertação (mestrado) – Centro Federal de Educação Tecnológica de Minas Gerais, 2008. Disponível em: Ultimo acesso: 07/06/2012

KALINOWSKI, M.; SPÍNOLA, R.O.; NETO, A. C. D.; BOTT, A.; TRAVASSOS, G. H. - Inspeções de Requisitos de Software em Desenvolvimento Incremental: Uma experiência prática – Simpósio Brasileiro de Qualidade de Software, 2007, Porto de Galinhas. Anais do Simpósio Brasileiro de Qualidade de Software, 2007. Disponível em: Acessado em: 03/05/2012.

KONTOYA, GERALD, and SOMMERVILLE. Requirements Engineering Processes and Techniques. John Wiley & Sons (UK). © 1998.

LAITENBERGER, O. - A Survey of Software Inspection Technologies . Handbook on Software Engineering and Knowledge Engineering, vol. II, World Scientific Pub. Co, 2002. Disponível em:  Último acesso em 29/05/2012.

LANUBILE, F.; SHULL, F.; BA SILI, V.R. Experimenting with error abstraction in Requirements Document s. In: INTERNATIONAL SYMPOSIUM ON SOFTWARE METRICS, 5., 1998, Bethesda, Maryland. Proceedings. Los Alamitos: IEEE Computer Society Press, 1998, p. 114-121.

LAITENBERGER, Oliver. - A Survey of Software Inspection Technologies.  Handbook on Software Engineering and Knowledge Engineering, vol. II, World Scientific Pub. Co, 2001. Disponível em: < ftp://cs.pitt.edu/chang/handbook/61b.pdf. >Último acesso: 05/06/2012

MELO, J. A. B - Uma metodologia para engenharia de requisitos para pequenas equipes de desenvolvimento de software – Revistas de Ciências Empresariais da UNIPAR, Vol. 6, N° 1 - 2005. Disponível em: Acessado em: 01/04/2012.

MELO, S. M. - Inspeção de Software. USP: São Carlos, SP, 2009. Disponível em: Último acesso: 01/05/2012.

MAFRA, S.N.; TRAVASSOS, G.H. (2006) - Leitura Baseada em Perspectiva: A visão do Projetista Orientada a Objetos - In: V Simpósio Brasileiro de Qualidade de Software, Vila Velha – ES.

PLAGLIUSO, P.; Tambascia, C. A.; BOAS, A. V.; FREITAS, M. E.; LEVANTEZI, M.F. - Guia de Validação de Requisitos baseadas nas técnicas PBR e ad-hoc. 2003. Disponível em: Último Acesso em : 01/06/2012

PORTO, D. P. (2009) - CRISTA: um apoio computacional para atividades de inspeção e compreensão  de  código - Dissertação  (Mestrado  em  Computação) – Universidade Federal de São Carlos, São Carlos. Disponível em: Último Acesso: 05/06/2012

PORTER, A. A. ; VOTTA JR,  L. G.; BASILI, V. Comparing Detection Methods for Software Requirements Inspections: a replicated experiment.  IEEE Transactions on Software Engineering, vol. 21, nº 6, p. 563-575, june 1995.

PRESSMAN Roger. Engenharia de Software – 6° ed. São Paulo: McGraw-Hill, 2006.

SAYÃO, M.; STAA, A.V.; LEITE, J.C.S.P – Qualidade em Requisitos.  PUC-Rio: Rio de Janeiro, RJ, 2003. Disponível em: Último acesso em: 29/05/2012.

SILVA, L.F.S.; CHAPETTA, W.A.; TRAVASSOS, G.H. – Inspeções de Requisitos de Software Utilizando PBR e Apoio Ferramental.  COPPE: Rio de Janeiro, RJ, 2004. Disponível em: . Ùltimo acesso em: 01/06/2012

SAUER, C.; JEFFERY, D.R.; LAND, L. YETTON, P.; - The Effectiveness of Software Development Technical Review: A Behaviorally Motivated Program of Research - IEEE Transaction on Software Engineering, 26 (1): 1 - 14, January, 2000.

SOMMERVILLE, Ian. Engenharia de Software - 8 ° ed. São Paulo: Pearson, 2007.

SCHULMEYER, G.G., MACKENZIE, G.R. - Verification & Validation of Modern Software-Intensive Systems, Nova Jersey, Prentice-Hall Inc, 1999.

TRAVASSOS, G. H.; SANTOS, P. M. M. - Inspeção de Qualidade em Descrições de Casos de Uso: uma Avaliação Experimental em um Projeto Real - Simpósio Brasileiro de Qualidade de Software, 2010, Rio de Janeiro. Disponível em: Último acesso em: 03/05/2012

TIAN, J. - Software Quality Engineering - Testing, Quality Assurance, and Quantifiable Improvement, John Willey & Sons, Hoboken, Estados Unidos, 2005.

SAMPAIO, A. L. S.; PRIMO, F. F.; MARTINHO, W. R. - Método para Definição de Requisitos de Software de um Sistema a Partir das Necessidades dos seus Stakeholders. SIMPROS: São Paulo – SP, 2005. Disponível em: Último acesso em: 01/05/2012

TRAVASSOS, G. H; SHULL, F.; FREDERICK, M.; BASILI, V. R. (1999) - Detecting in Object Oriented Designs: Using Reading Techniques to increase Software Quality - ACM Sigplan Notices. EUA, v.34, n.10, p.47-56.

SHULL, F.; RUS,  I.; BASILI, V. How Perspective-Based Reading can Improve Requirements Inspections.  IEEE Computer, vol. 33, nº 7, p. 73-79, july 2000.

 WIEGERS, Karl. Software Requirements - 2° ed. Microsoft Press, 2004.

_________________________                                             _________________________

     João Carlos N. Pacheco                                                              Dra. Judith Pavón

                 Aluno                                                                                   Orientadora 

João Carlos Nascimento Pacheco

UNIFACS - Universidade Salvador – Salvador, BA.