Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Prodemge WTQS - Minicurso técnicas de verificação de requisitos

636 views

Published on

Minicurso ministrado durante o Workshop de Testes e Qualidade de Software na Prodemge.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Prodemge WTQS - Minicurso técnicas de verificação de requisitos

  1. 1. Minicurso: Técnicas de Revisão de Requisitos Tutor: Gustavo Lopes, CTFL Participação: Rafael Machado, CTFL Setembro / 2012
  2. 2.  Apresentação Introdução RNG X Requisitos Refinando requisitos EA + Requisitos Técnicas de verificação Dúvidas Dinâmica Checklist ERSw Boas práticas Referências
  3. 3. Nome: Gustavo Faria Lopes, CTFLDiretoria: DDSGerência: GTS – Gerência de Teste de SoftwareFunção: Analista de Testes
  4. 4.  Validação e Verificação:  Utilizado para verificar se o que foi feito atende os usuários;  Validação: “Estamos construindo o produto certo?” – faz o que o usuário precisa;  Verificação: “Estamos construindo certo o produto?” – conformidade com a especificação.
  5. 5.  Regras de negócio (RNG):  Não necessariamente afirma que deve ser satisfeita por um software;  Restrição imposta pelo negócio;  Comportamento de um procedimento operacional do negócio.
  6. 6.  Regras de negócio (RNG):  Exemplos: o A matrícula dos alunos somente será confirmada após o pagamento da taxa de cadastro; o O horário de funcionamento da empresa é das 07:00 às 19:00, seus colaboradores não poderão ultrapassar este período; o Não admite-se cadetes com estatura abaixo de 1,60m.
  7. 7.  Requisitos:  “[...] condição ou capacidade que deve ser atendida pelo sistema [...]” LEFFINGWELL ;  “Uma condição ou capacidade que deve ser satisfeita por um sistema para satisfazer um contrato, padrão, especificação ou documento imposto.” IEEE;  Necessário para solucionar um problema ou atender a um objetivo do usuário.
  8. 8.  Requisitos:  Exemplos: o Deve ser possível realizar o cadastro dos colaboradores da empresa; o Deve permitir a inclusão de registro em banco de dados Oracle e SQL Server; o Possibilitar a emissão de relatórios administrativos.
  9. 9.  Técnica S.M.A.R.T.:  S – Sepecify  Específico;  M – Measurable  Mensurável;  A – Attainable  Alcançável;  R – Realisable  Realizável;  T – Traceable  Rastreável.
  10. 10.  Técnica S.M.A.R.T.:  Exemplos: os funcionários da NEC01 - Deve ser possível manter usuários da aplicação. empresa como usuários da aplicação. NEC02 - O sistema deve emitir relatórios. funcionários relatório de que utilizam a aplicação. possuir controle de versão dos NEC03 - O sistema deve ser 100% de integridade e 100% documentos enviados e estar disponível 24 horas por 7 disponibilidade. dias da semana, com o prazo máximo 6 horas de interrupção semanal.
  11. 11.  Técnica S.M.A.R.T.:  Exemplos: NEC04 - Irá realizar o registro das ações de inserção, alteração e remoção remoção nos módulos dos inserção, alteração e nos módulos de cálculo e sistema. faturamento. NEC05 - Deve permitir o bloqueio de usuários da aplicação. (REQ001);
  12. 12.  EA – Enterprise Architect:  Ferramenta CASE – Computer-Aided Software Engineering;  Possibilita engenharia reversa e integração com repositórios (bancos de dados ou Subversion e etc.);  Existe uma versão Lite de distribuição gratuita (sem necessidade de licenças) apenas para visualização.
  13. 13.  EA + Requisitos:  Existe um elemento específico para requisitos no EA: custom Stakeholders Interests REQ001 - Relation between orders and email inquires.  Possibilidade de criação de matrizes de rastreabilidade entre requisitos e outros elementos.
  14. 14.  EA + Requisitos na Prodemge:  São apresentada na parte de visão do template padrão (MADSw), para cada caso de uso há pelo menos uma necessidade associada;  Utiliza a sigla NEC de necessidade para os requisitos funcionais;
  15. 15.  Inspeção com checklists:  Leitura em busca de defeitos ou inconsistências;  Segue critérios pré-estabelecidos - checklist;  Não exige execução do sistema. Revisão - walkthrought:  Entre 3 a 5 pessoas;  Papeis: Apresentador/Autor, Coordenador/Líder de revisão, Escrivão/Secretário e Revisores;
  16. 16.  Apresentador descreve o caminho do produto;  Erros identificados devem ser anotados – lista de problemas. Outras técnicas:  PBR – Perspective-Based-Reading;  Ad-hoc;  DBR – Defect-Based-Reading.
  17. 17.  Estudo de caso: Encenação de uma situação cotidiana para relato de casos durante testes funcionais em um sistema, para que seja possível identificar os requisitos necessários para a criação de uma ferramenta de bug tracking para a área.  Técnica de elicitação a ser utilizada:  Etnologia  Encenado por:  Alex Silva – GTS  Daniela Monteiro – GTS
  18. 18. 1. Manter consistência com termos utilizados.2. Fazer uso de glossário (Stakeholders expressam os requisitos em sua terminologia) e mantê-lo atualizado.3. O agrupamento de requisitos ou classificação auxilia nos trabalhos de verificação e validação (cliente).4. Alguns requisitos são mais urgentes do que outros.5. Determinar prioridade de requisitos junto aos clientes.6. O Cliente deve ser consultado para resolver ambiguidades.7. Procurar utilizar imagens para facilitar o entendimento quando uma estrutura for descrita.8. Utilizar pelo menos dois exemplos quando houver um cálculo.9. Os documentos e ou especificações devem estar acessíveis a todos os membros do projeto.
  19. 19.  Engenharia de Software. Verificação e Validação aula 12. UNESP – Universidade Estadual Paulista. 2005. SAYÃO, Miriam. Verificação e Validação em Requisitos: Processamento da Linguagem Natural e Agentes. Disponível em: http://www-di.inf.puc-rio.br/~julio/tese- miriam.pdf MONTEIRO, Alexandre. Análise e validação de requisitos. Universidade Federal de Pernambuco – UFPE.
  20. 20.  KOTONYA, Gerald e SOMMERVILLE, Ian. Requirements Engineering: Processes and techniques. 1998. PINTO, Evandro Moreira. Regra de Negócio Não é Requisito de Software. Disponível em: http://evandrowm2.blogspot.com.br/2010/11/regra-de-negocio- nao-e-requisito-de_15.html
  21. 21.  LIEBERMAN, Benjamin A.. Requisitos para mecanismos de regras: Captura e comunicação de regras de negócios complexas. IBM. 2009. Disponível em: http://www.ibm.com/developerworks/br/opensource/library/os- rulesengines/ TURINE, Marcelo Augusto. Princípios Fundamentais da Análise de Requisitos. Disponível em: http://www.slideshare.net/adorepump/analise-de-requisitos- presentation
  22. 22.  MENDES, Marco Aurélio. Blog Arkhi: O Funil do Arquiteto de Software – Os requisitos arquiteturais. Disponível em: http://blog.arkhi.com.br/2009/02/09/o-funil-do-arquiteto-de- software-os-requisitos-arquiteturais/
  23. 23. Muito obrigado! Gustavo Lopes, CTFL Analista de Testesgustavo.lopes@prodemge.gov.br

×