Métodos de Inspeção de Requisitos de Software
Juliana Mokwa1, Marcello Thiry1, Cristiano Caetano31Universidade do Vale do Itajaí (Univali)
CEP 88032-005 – Florianópolis – SC – Brazil {julimokwa, marcello.thiry}@gmail.com,
cristiano.caetano@qualister.com.br
Abstract. This paper has as objectives describing software requirements
techniques, analyzing Softplan’s requirements specification processes, detecting some problems in those and suggesting improvements to the requirement specification models of Softplan.
Resumo. Este artigo tem como objetivo descrever técnicas de inspeção de
requisitos de software, fazer uma analise do processo de especificação de requisitos da Softplan, detectar alguns problemas e com base nisso, sugerir melhorias para o modelo de especificação de requisitos da Softplan.
1. Introdução
Qualidade de software é definida pelo IEEE (The Institute of Electrical and Electronics
Engineers) como "o grau com que um sistema, componente ou processo atende (1) aos
requisitos especificados e (2) às expectativas ou necessidades de clientes ou usuários". Já a ISO (The International Standards Organization) define qualidade como "a totalidade de características de um produto ou serviço que comprovam sua capacidade de satisfazer necessidades especificadas ou implícitas" [Rosenberg 2002]. Estas duas definições, oriundas de organizações respeitadas pela comunidade acadêmica, mostram que a qualidade de um produto está estritamente ligada ao atendimento de seus requisitos.
A engenharia de software tem como foco principal a qualidade final do produto gerado, e uma maneira de atingi-la é através do aperfeiçoamento do processo de desenvolvimento. Por isso, a qualidade de um software não pode ser imposta depois que o produto estiver finalizado, constituindo um aspecto que deve ser tratado simultaneamente ao processo de desenvolvimento. (Young 2004).
Os defeitos que podem ser introduzidos nos artefatos produzidos ao longo do desenvolvimento do produto são inevitáveis e a quantidade pode ser alta. O que torna extremamente arriscado contar com atividades de teste e validação apenas no final do desenvolvimento. Sendo assim, fica clara a necessidade de se identificar os defeitos tão logo eles sejam inseridos nos diferentes artefatos, não dispensando os testes e as validações finais no produto.
No processo de desenvolvimento de software a especificação de requisitos é a base para todas as atividades de engenharia de software subsequentes. Com um documento de especificação de requisitos bem definido é possível detectar e corrigir precocemente inconformidades no desenvolvimento do produto, evitando desta forma, a propagação
de erros por diversas etapas do processo, minimizando os custos e o tempo gasto ao longo do desenvolvimento.
Neste contexto, inspeções de software têm como propósito reduzir o número de defeitos transmitidos de uma fase para outra do desenvolvimento. (Young 2004).
Durante o processo de inspeção dos artefatos, diversas técnicas podem ser utilizadas, como as de leitura baseada em perspectiva PBR (em inglês “Perspective-Based
Reading”), que foram criadas para apoiar a identificação de defeitos em documentos de
requisitos de software escritos em linguagem natural. (Laitenberger et al., 2000).
A inspeção é um método que contribui para garantir a qualidade do produto de software. Todas as etapas do processo de desenvolvimento de software são suscetíveis à incorporação de defeitos, que podem ser detectados pela inspeção e posteriormente removidos. É importante destacar que quanto mais cedo esses defeitos forem removidos, menor será o custo de desenvolvimento e manutenção do produto. Experiências têm comprovado que a inspeção, quando realizada no início do desenvolvimento do software, leva à detecção de 60% a 90% dos defeitos potenciais em um projeto de software. (Boehm 2001).
Este artigo apresenta a seção 2 onde são estudadas algumas técnicas de inspeção dos requisitos. A seção 3 apresenta o modelo de análise e inspeção de requisitos da Softplan e alguns dos problemas encontrados nesse modelo. A seção 4 sugere uma melhoria do modelo apresentado na seção 3, com base nas técnicas revisadas na seção 2. E a seção 5 que tece algumas conclusões sobre o assunto.
2. Técnicas de inspeção
Avaliar a qualidade de um Documento de Requisitos envolve aspectos relativos ao controle da qualidade dos artefatos de software produzidos no processo de requisitos. Diferentes abordagens podem ser aplicadas: validação por prototipação, uso de requisitos executáveis, geração e execução de baterias de testes. A qualidade de um artefato de requisitos pode ser avaliada através da utilização de métricas, indicadores ou testes; a análise crítica desses artefatos pode ser realizada através de inspeções. (Blackburn, 2001).
Métricas fornecem subsídios importantes para o gerenciamento do projeto, e podem ser aplicadas em diferentes etapas do processo de desenvolvimento. É possível desenvolver casos de teste ainda no processo de requisitos; dificuldades na geração indicam problemas na definição dos requisitos. As inspeções ajudam a encontrar defeitos em artefatos, antes que se passe à fase seguinte do processo; no cerne do processo de inspeção estão a identificação das informações a serem inspecionadas e a técnica a ser utilizada para identificar defeitos nessas informações. (Abib, 1998).
Inspeções localizam e apontam defeitos/problemas no artefato em questão, sendo possíveis ações corretivas que melhoram a qualidade do artefato antes que se passe à fase seguinte no processo de desenvolvimento ou evolução. Métricas são utilizadas como indicadores da evolução do processo e podem apoiar o gerenciamento do projeto; também são aplicáveis a artefatos visando compará-los à média na empresa. Em caso de
identificação de desvios em relação ao esperado, devem ser tomadas medidas corretivas para sanar o problema detectado; quanto mais cedo se faz essa correção, menor será o custo a ela associado. (Abib, 1998).
2.1. Walkthrough
Nesta técnica a revisão é feita através de uma execução passo a passo de um procedimento ou programa (no papel), com o objetivo de encontrar erros. Dura em média uma a duas horas. Envolve equipes pequenas de três a cinco pessoas, onde é feita uma simulação da execução por cada revisor, controlada por um testador que durante a reunião disponibiliza um conjunto de casos de teste e monitora os resultados obtidos de cada revisor. A técnica walkthrought é bastante utilizada para testes estáticos, ou seja, revisão de protótipos, casos de uso, código fonte, entre outros artefatos elaborados durante o desenvolvimento do sistema que não executam o programa. (Bertini, 2009). 2.2 Peer-Review
É uma técnica formal de inspeção que pode ser utilizada por diversos papéis, realizada em pares com mesmo nível de conhecimento, o objetivo desta técnica é obter pontos de vista diferentes e revisar o material, a fim de encontrar problemas de qualidade. Os resultados obtidos vão para um relatório para a revisão e se forem pertinentes passam para o artefato do produto. O problema desta técnica são as disputas pessoais. Por esse motivo deve ser analisado o produto não a pessoa. (Bertini, 2009).
2.3 Técnica Ad-Hoc
A técnica ad-hoc não utiliza nenhum método formal para a inspeção do documento, cada colaborador lê o documento do seu modo. Por esse motivo ele é uma técnica que depende bastante da experiência do usuário, que com base na sua experiência poderá apontar defeitos e melhorias. Devido a falta de um método formal, com o passar do tempo a técnica ad-hoc não sofre melhorias, pois não existe um procedimento a ser seguido. (Alves et al., 2013).
2.4. Técnica Check-list
A técnica de leitura check-list é bastante similar a técnica Ad-Hoc pois leva muito em consideração a experiência do usuário, no entanto o revisor recebe junto com o documento de especificação de requisitos um check-list composto de uma lista de perguntas, que podem enumerar os pontos mais afetados do sistema, defeitos característicos. Ao contrário da técnica Ad-Hoc o documento de check-list pode evoluir ao longo do tempo, proporcionando uma melhora na inspeção. (Alves et al., 2013). 2.5. Técnica de leitura baseada em cenário
A técnica de leitura baseada em cenários (em inglês “Scenario-Based Reading”), apoia a inspeção através de um documento, denominado cenário, que contem instruções e diretrizes que orientam o inspetor a encontrar defeitos.
Vários estudos foram feitos com a utilização de cenário em documentos formais de requisitos, projetos orientados a objetos e códigos que comprovaram os benefícios da técnica aplicada em várias fases de desenvolvimento do software. (Shull et al., 2003).
A experiência adquirida com sua utilização tornou possível o surgimento de outras técnicas mais específicas baseadas na SBR. Por isso, atualmente existe um conjunto de técnicas de leitura baseadas em cenários.
2.6. Técnica de leitura baseada em perspectiva
A técnica de leitura PBR, possui enfoque na inspeção de documentos através de cenários projetados para reproduzir pontos de vista (perspectivas) de stakeholders envolvidos diretamente com os artefatos inspecionados. (Basili et al., 1996).
O principal objetivo em reproduzir as diferentes perspectivas presentes no contexto do desenvolvimento do sistema é garantir uma inspeção com ampla cobertura, sem que para isso tenham que ser realizadas apenas leituras superficiais. Cada cenário aprofunda a inspeção nos aspectos relevantes para uma perspectiva, o que aumenta as chances de encontrar defeitos que não seriam percebidos em uma leitura mais geral. (Alves et al., 2013).
2.6.1. Caracterização de cenário PBR Um cenário utilizado na PBR consiste em:
Introdução sobre os interesses do stakeholder no artefato inspecionado;
Conjunto de instruções que indicam como obter as informações relevantes para a inspeção;
Conjunto de perguntas que devem ser respondidas durante a execução das instruções.
Após a identificação do artefato a ser inspecionado, a construção do cenário é necessária para a realização da PBR. O processo para a construção de um cenário possui as seguintes atividades. (Laitenberger et al., 2000).
Identificação dos documentos de revisão: Os documentos que possuam informações importantes sobre o sistema devem ser identificados, sejam estes textuais, diagramas ou modelos;
Identificação dos stakeholders: Os stakeholders envolvidos no processo de desenvolvimento do software devem ser identificados. Os de maior importância devem ser selecionados para que seus pontos de vista sirvam de perspectivas para os cenários;
Identificação das informações importantes: As informações de maior relevância para cada perspectiva devem ser identificadas. Esta tarefa pode ser auxiliada por entrevistas realizadas com os stakeholders envolvidos;
Criação da introdução e das instruções do cenário: Após as três primeiras atividades, é possível começar a escrever o cenário. A introdução deve indicar os interesses do stakeholder no documento inspecionado. As instruções devem ser escritas de forma a orientar o inspetor em como identificar e extrair informações importantes do artefato para um modelo, utilizando como base o que foi realizado no passo anterior;
Criação das perguntas: O último passo é construir uma lista de perguntas. As perguntas devem ser escritas levando em consideração os tipos de defeitos que se deseja eliminar e os problemas normalmente encontrados no tipo de artefato inspecionado.
Um cenário poderá ser utilizado em qualquer outro artefato do mesmo tipo. Com sua utilização contínua em inspeções, podem ser identificados pontos de melhoria, que devem ser incorporados para aumentar a cobertura das inspeções futuras.
O nível de detalhamento dos cenários deve variar de acordo com a proficiência do inspetor. Para inspetores experientes não são necessários cenários com muitos detalhes. Inspetores com pouca experiência devem utilizar cenários com nível de detalhes maior, visando execução correta da leitura.
Na utilização do cenário, primeiramente o inspetor deve ler a introdução para entender o contexto e os interesses do stakeholder no artefato. Em seguida, a partir das instruções, deve abstrair as principais informações para um modelo. Por último, responder as perguntas sobre o modelo construído.
2.6.2. Perspectivas PBR
As perspectivas são importantes, pois os stakeholders do artefato inspecionado possuem interesses diferentes no que tange a qualidade do documento [Ciolkowski, 1997]. Para o contexto deste trabalho, as perspectivas identificadas por [Laitenberger et al., 2000] são mais relevantes por se tratarem da visão dos stakeholders envolvidos com os documentos de projeto do sistema. Foram identificadas duas perspectivas principais:
Projetista: O cenário que representar o ponto de vista do projetista deve validar se não há desvios entre as informações correlatas dos modelos de projeto e dos documentos da análise, garantindo que estão completos e corretos entre si; Testador: Um cenário baseado na perspectiva do testador deve indicar como
identificar as diversas funcionalidades do sistema nos modelos de projeto e como criar casos de teste para cada uma delas, para que assim o inspetor possa garantir que o comportamento esperado está sendo realizado;
Perspectivas diferentes podem ser encontradas em outros estudos e até mesmo as mesmas perspectivas, porém com cenários utilizados para validações diferentes. Além disso, dependendo do contexto do software e dos requisitos de qualidade impostos outras perspectivas podem ser criadas.
3. Cenário atual da Softplan no desenvolvimento dos requisitos
O processo de desenvolvimento da Softplan inicia na solicitação do cliente quando verificado a necessidade de uma evolução/alteração no sistema. Esse processo é dividido em diversas etapas até que inicie-se o desenvolvimento.
Inicialmente é realizada uma triagem interna na solicitação do cliente para que seja validado se a alteração solicitada realmente é necessária e se já não existe alguma
funcionalidade no sistema que atenda o cliente e se esta funcionalidade já não está desenvolvida, mas não foi liberada para o cliente.
Confirmada a necessidade da alteração, é feita uma avaliação da incidência de custos e inicia-se a especificação de negócio, onde será elaborado uma estimativa preliminar da demanda (EPD), para que com base nela, seja iniciada a elaboração dos requisitos. No momento da elaboração da EPD, analistas de negócio verificam em quais pontos a alteração vai afetar.
O foco de estudo é referente a unidade que trabalha com sistemas do poder judiciário. A organização do Poder Judiciário foi determinada pela Constituição Federal (do artigo 92 ao 126). Os vários órgãos que compõem o sistema estão divididos por área de atuação: Justiça Comum (tanto estadual e quanto federal), Justiça do Trabalho, Justiça Eleitoral e Justiça Militar. A estrutura das áreas citadas acima é composta por dois graus de jurisdição, que vêm a ser a primeira e a segunda instância. A primeira instância ou primeiro grau são as varas ou seções judiciárias onde atuam o juiz de Direito. Essa é a principal porta de entrada do Judiciário. Grande parte dos cidadãos que entra com uma ação na Justiça tem o caso julgado por um juiz na primeira instância, que é um juiz chamado de singular (único), que profere (dá) a sentença (decisão monocrática, de apenas 1 magistrado). No segundo grau, os juízes, também chamados de desembargadores, trabalham nos tribunais (exceto os tribunais superiores). Os tribunais de Justiça (TJs) são responsáveis por revisar os casos já analisados pelos juízes singulares de primeira instância. (CNJ, 2012).
Contudo, internamente os sistemas são divididos em três módulos PG5 (primeira instância), SG5 (segunda instância) e Web (composta por alguns serviços da primeira e segunda instância disponibilizados na internet).
Devido essa divisão (PG5, SG5 e Web), quando solicitado uma alteração em algum dos módulos, é necessário a analise de um colaborador experiente, que geralmente é o analista de negocio, para verificar em quais pontos do sistema serão afetados. Lembrando que uma alteração no PG5, pode ter impacto na Web ou no SG5, por exemplo.
Feita a EPD, esta é enviada para o cliente, para que o mesmo tenha ciência dos locais do sistema que serão afetados e após aprovada a alteração pelo cliente, inicia-se a especificação de requisitos.
O analista de sistemas é responsável por elaborar a especificação de requisitos baseando-se na EPD desenvolvida pelo analista de negocio. Após finalizada a especificação, esta é retornada para validação do analista de negócio, que irá validar a necessidade de alteração. Caso não seja necessário a especificação é enviada para aprovação do cliente.
A Figura 1, apresenta o processo de evolução do produto descrito acima. Existem outras etapas que não foram citadas por não fazerem parte dos estudos.
Figura 1. Processo de evolução do software no modelo Softplan
Após aprovada pelo cliente a especificação é enviada para a equipe de testes e para elaboração da solução técnica (desenvolvimento). Finalizado o desenvolvimento, o produto é testado e após aprovado pelos testes o produto retorna para que o analista de sistemas efetue uma validação final e verifique se todos os critérios especificados foram atendidos (Figura 2).
Figura 2. Processo de evolução do software no modelo Softplan, após aprovados os requisitos
3.1. Problemas encontrados
O modelo de desenvolvimento da Softplan vem sendo melhorado ao longo dos anos. No entanto, ao longo do processo de evolução do sistema ou da criação de novos produtos, muitos problemas vêm sendo identificados, não só pela empresa, mas também por parte dos clientes.
Conforme visto na Seção 4, inicialmente a EPD é feita por um analista de negócio experiente. Contudo, devido a grande complexidade do produto como um todo, assim como os sistemas são divididos em módulos, os colaboradores também são divididos por área de negócio. Ou seja, especialistas do PG5, especialistas do SG5 e especialistas da Web. O que ao longo da evolução do produto tem gerado bastante problema, pois não existem analistas de negócio que tenham um domínio completo do sistema. Portanto, quando um analista de negócio elabora uma EPD, este tende a fazer uma análise maior da sua área de atuação. Com isso, alterações efetuadas no SG5, por exemplo, que afetam a Web, não são previstas na Web. Fazendo com que na maioria dos casos, esses problemas acabam sendo vistos somente na homologação ou na produção, quando o produto já está com o cliente, ocasionando uma reprovação por parte do cliente.
Outro problema encontrado é o repasse da especificação para a equipe de testes, que acontece junto com o desenvolvimento. Quando são encontradas falhas na especificação pela equipe de testes, o custo para correção é muito alto, pois a alteração já está em desenvolvimento ou já foi desenvolvida.
E por último vem o modelo de especificação dos requisitos. O modelo de especificação de requisitos da Softplan, tem por objetivo, atender o cliente, a equipe de testes e o desenvolvimento. O mesmo documento é enviado para os três papéis, o que muitas vezes acaba dificultando sua leitura. Pois o documento abrange questões técnicas que devem ser escritas de uma forma que o cliente e a equipe de testes possam entender, mas que podem dificultar o entendimento dos requisitos. Além disso, a leitura muitas vezes pode acabar dando margem para várias interpretações, caso o documento não esteja bem escrito.
4. Analise das técnicas levantadas se aplicadas ao modelo Softplan
Com base nos problemas levantados na Seção 4.1 e nas técnicas levantadas na Seção 2, será feito uma analise da aplicação das técnicas no modelo da Softplan.
A técnica walkthrough poderia ser usada dentro do cenário Softplan, baseando-se no modelo de apresentação, o fato dela envolver equipes pequenas composta por pessoas com diferentes papéis, pode auxiliar na detecção de falhas, pois em uma única apresentação serão discutidos vários pontos de perspectivas de papéis diferentes, onde poderiam ser envolvidos analistas do PG5, SG5, Web, analista de teste e projetista. A elaboração de casos de testes para serem distribuídos entre os membros participantes pode vir a atrapalhar o raciocínio dos participantes, pois ao invés de serem verificados os possíveis problemas, os participantes podem acabar focando demais no caso de teste.
Como a técnica peer-review visa a inspeção em pares com pessoas que possuem o mesmo nível de conhecimento, ela pode ser bem utilizada tanto na elaboração da EPD, como na elaboração da especificação de requisitos, pois a técnica pode ser aplicada por analistas de negocio com a mesma experiência, mas que atuam em áreas diferentes, identificando possíveis impactos. No entanto, a utilização da técnica entre os próprios analistas de sistemas do mesmo modulo, também é válida, pois duas pessoas podem ter uma visão diferente do problema.
A técnica ad-hoc também pode ser utilizada pelos analistas de negocio que trabalham em módulos diferentes, lembrando que nesse caso, o objetivo de cada inspetor é analisar os possíveis impactos nos seus módulos de domínio, não na especificação como um todo.
O fato da técnica check-list ser similar a técnica ad-hoc, talvez ela possa não ser a melhor opção para o modelo da Softplan, conforme visto, o modelo existente já é bastante burocrático, introduzir mais um checklist pode ser valido, mas a probabilidade dos colaboradores se recusarem a seguir o mesmo, pode ser muito alta, podendo afetar a qualidade da revisão.
A técnica baseada em cenário pode é válida, principalmente para a equipe de testes, que ao receber o documento de especificação poderá analisar se os requisitos estão bem definidos, se são testáveis, se não ocorreram omissões de negócio no fluxo, se situações inesperadas estão previstas, entre outras situações definidas previamente no cenário, que poderá evoluir com o passar do tempo.
A técnica baseada em leitura, de certa forma já é aplicada hoje na Softplan, talvez no momento errado, pois conforme visto na Seção 3, os projetistas e analistas de teste tem acesso a especificação de requisitos, somente após aprovação do cliente. Problemas encontrados na etapa de testes ou projeto, podem ocasionar modificações na especificação de requisitos, que dependendo do caso, terá que voltar para uma reavaliação do cliente, causando transtornos com o cliente, atraso na entrega e retrabalho.
4. Modelo sugerido para a analise de requisitos da Softplan
Com base na análise das técnicas levantadas o modelo de processo sugerido a Softplan é Figura 3.
Figura 3. Sugestão de processo de evolução do software para Softplan
Após confirmada a necessidade de alteração no sistema, o analista de negócio responsável pela demanda elabora a EPD e conforme sugerido na técnica walkthrough apresenta as alterações para outros dois analistas de negócio que trabalham em módulos diferentes do seu. Exemplo, caso a modificação seja no PG5, a apresentação acontecer para um analista de negócios do SG5 e da Web. Analisada e aprovada a EPD com base nas perspectivas dos três analistas, essa é enviada ao cliente.
Depois de aprovada a EPD, inicia-se a especificação de requisitos pelo analista de sistemas, que após finalizar, pode executar uma revisão no formato peer-review, junto com outro analista de sistemas do mesmo módulo, exemplo, ambos da Web. Discutida a especificação, essa é encaminhada para revisão para o analista de negócio.
Aprovada pelo analista de negocio responsável, a especificação é encaminhada para os outros analistas de negocio que auxiliaram na elaboração da EPD, onde através da técnica ad-hoc, cada um fará uma inspeção informal, visando problemas que afetaram ou podem afetar os seus módulos de domínio.
Concluída a etapa de revisão por parte dos analistas de negócio, a especificação é enviada para as equipes de teste, projeto e também para o cliente. Neste momento, também pode-se utilizar a técnica walkthrough, para repasse da especificação, reduzindo assim, problemas de entendimento. Estes devem ter o mesmo prazo para analisar a especificação, cada um com base em sua perspectiva conforme sugerido na técnica PBR. Após revisada e aprovada por todos, a especificação então entra para o processo de desenvolvimento, onde provavelmente será desenvolvida com um índice de erros reduzido.
6. Conclusão
A inspeção dos requisitos tem como principal objetivo assegurar que cada nível da implementação satisfaça os requisitos do cliente, visando analisar os pontos do sistema que estão sendo impactados com aquela alteração, a qualidade dos requisitos e das regras de negocio, omissão de cenários na especificação, entre outros, que podem ser executados por diversos papéis e de variadas maneiras.
Para o modelo da Softplan, viu-se a necessidade de efetuar uma junção das técnicas estudadas, visando a melhoria do modelo, pois não existe a técnica ideal e sim a que melhor se aplica ao seu processo de desenvolvimento.
Baseando-se nisso a conclusão do estudo foi que:
Todos os aspectos relacionados a qualidade devem ser tratados durante todo o ciclo de vida do software, pois os custos associados ao teste, isolamento, correção e re-teste são maiores que os custos para identificar os defeitos tão logo eles sejam inseridos nos artefatos produzidos durante o ciclo de desenvolvimento. Além disso, a inspeção dos artefatos através de diversas perspectivas tende a reduzir o número de defeitos propagados de uma fase de desenvolvimento para a outra.
No entanto, após executado o modelo em uma solicitação de alteração no sistema Web da Softplan, contatou-se que o tempo de desenvolvimento dos requisitos foi muito alto, o que de certa forma inviabiliza a aplicação do novo modelo, mesmo que este apresente uma melhoria na qualidade. Porem, algumas das técnicas estão sendo agregadas ao modelo, o que possivelmente irá gerar um aumento na qualidade do produto, como a utilização da técnica walkthrough, para o repasse da especificação para os analistas de teste e projetistas e a revisão da especificação entre os analistas de sistema no formato
peer-review. Após finalizada a especificação, essa será enviada para os analistas de
negócio para que estes façam uma revisão através da técnica ad-hoc.
7. Referencias
Abib, J.C. (1998) “Abordagem Goal Question Metric (GQM) para Avaliação da Qualidade de Software.” Dissertação de Mestrado. DC/UFSCar, São Carlos, SP. Alves, A.; Gouvêa, A. (2013) “Técnica de inspeção de softwares baseada em técnicas de
leitura e verificação de modelos UML de alto nível.”, http://bsi.uniriotec.br/tcc/201308AlvesGouvea.pdf
Bertini, A.; Kirner, T.; Montebelo, M.; Lara, I. (2009) “Técnicas de Inspeção de Documentos de Requisitos de Software: um Estudo Comparativo”,
http://wer.inf.puc-rio.br/WERpapers/pdf_counter.lua?wer=WER06&file_name=bertini.pdf
Easterbrook, S.; Nuseibeh. B. (2000) “Requirements engineering: a roadmap, Limerick, Ireland: Future of Software Engineering.”, http://mtc-
m19.sid.inpe.br/col/sid.inpe.br/mtc-m19/2012/03.26.23.04/doc/publicacao.pdf?ibiurl.language=pt-BR
Blackburn, M. R.; Busser, R.; Nauman, (2001) “A. Removing Requirement Defects and Automating Test. Software Productivity Consortium NFP” http://www.cmcrossroads.com/sites/default/files/article/file/2013/3988360.pdf
Boehm, B. and Basili, V. (2001) “Software Defect Reduction Top 10 List”, IEEE Software, vol. 34, nº1, January 2001, páginas 135-137.
Ciolkowski, M.; Differding, C.; Laitenberger, O.; Munch, J. (1997) “Empirical Investigation of Perspective-based Reading: A Replicated Experiment. Technical Report” ISERN-97-13, University of Kaiserslautern, Alemanha.
Justiça, C. N. (2012) “Primeira instância, segunda instância... Quem é quem na Justiça brasileira? ”, http://www.cnj.jus.br/noticias/cnj/21439-primeira-instancia-segunda-instancia-quem-e-quem-na-justica-brasileira.
Laitenberger, O., Atkinson, C., Schlich, M., El Emam, K., (2000), “An Experimental Comparison of Reading Techniques for Defect Detection in UML Design Documents”, The Journal of Systems and Software, v53, Issue 2, p.183-204.
Rosenberg, L. (2002) “What is Software Quality Assurance? ” CrossTalk, may 2002, p. 22-25. http://www.crosstalkonline.org/storage/issue-archives/2002/200205/200205-Rosenberg.pdf.
Shull, F.; Carver, J.; Travassos, G. H.; Maldonado, J. C.; Conradi, R.; Basili, V. (2003) “Replicated Studies: Building a Body of Knowledge about Software Reading Techniques”.
Young, R. R. (2004) “The requirements engineering handbook. ” Norwood, MA, EUA: Artech House”, http://mtc-m19.sid.inpe.br/col/sid.inpe.br/mtc-m19/2012/03.26.23.04/doc/publicacao.pdf?ibiurl.language=pt-BR
