Este documento resume um minicurso sobre técnicas de revisão de requisitos, abordando tópicos como a diferença entre regras de negócio e requisitos, técnicas para refinar requisitos, o uso de ferramentas como Enterprise Architect e checklists, e apresenta um exemplo de elicitação de requisitos usando a técnica de etnologia.

1. Minicurso: Técnicas de Revisão de Requisitos
Tutor: Gustavo Lopes, CTFL
Participação: Rafael Machado, CTFL
Setembro / 2012

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. Nome: Gustavo Faria Lopes, CTFL
Diretoria: DDS
Gerência: GTS – Gerência de Teste de Software
Função: Analista de Testes

5.  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.

7.  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.

8.  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.

9.  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.

10.  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.

12.  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.

13.  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.

14.  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);

16.  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.

17.  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.

18.  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;

20.  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;

21.  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.

24.  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

27. 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.

28.  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.

29.  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

30.  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

31.  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/

32. Muito obrigado!
Gustavo Lopes, CTFL
Analista de Testes
gustavo.lopes@prodemge.gov.br