Tutor: Gustavo Lopes, CTFL

Setembro / 2012

Minicurso: Técnicas de Revisão de Requisitos

Participação: Rafael Machado, CTFL

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: DDS

Gerência: GTS – Gerência de Teste de Software

Funçã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:

NEC01 - Deve ser possível manter usuários da aplicação.

NEC02 - O sistema deve emitir relatórios.

NEC03 - O sistema deve ser 100% de integridade e 100% disponibilidade.

NEC01 - Deve ser possível manter os funcionários da empresa como usuários da aplicação.

NEC02 - O sistema deve emitir relatório de funcionários que utilizam a aplicação.

NEC03 - O sistema deve possuir controle de versão dos documentos enviados e estar disponível 24 horas por 7 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 nos módulos dos sistema.

NEC05 - Deve permitir o bloqueio de usuários da aplicação.

NEC04 - Irá realizar o registro das ações de inserção, alteração e remoção nos módulos de cálculo e 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:

Possibilidade de criação de matrizes de

rastreabilidade entre requisitos e outros elementos.

custom Stakeholders Interests

REQ001 - Relation between

orders and email inquires.

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, CTFLAnalista de Testes

gustavo.lopes@prodemge.gov.br