Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 623 views

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

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

Statistics

Views

Total Views
623
Views on SlideShare
623
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • Minicurso: Técnicas de Revisão de Requisitos Tutor: Gustavo Lopes, CTFL Participação: Rafael Machado, CTFL Setembro / 2012
  •  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
  • Nome: Gustavo Faria Lopes, CTFLDiretoria: DDSGerência: GTS – Gerência de Teste de SoftwareFunção: Analista de Testes
  •  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.
  •  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.
  •  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.
  •  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.
  •  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.
  •  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.
  •  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.
  •  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);
  •  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.
  •  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.
  •  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;
  •  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;
  •  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.
  •  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
  • 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.
  •  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.
  •  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
  •  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
  •  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/
  • Muito obrigado! Gustavo Lopes, CTFL Analista de Testesgustavo.lopes@prodemge.gov.br