Verifica

1
Verificação e Validação de Requisitos
2
Verificação e Validação dos Requisitos
Requisitos p/ Inspeção
Plano e Casos de Teste
Casos de Uso e Esp. Suplementar

• Verificar conflitos de requisitos
• Verificar consistência de requisitos
• Verificar completude de requisitos
• Verificar existência de requisitos ambíguos

Inspetor

• Garantir a rastreabilidade dos requisitos
• Validar requisitos com o cliente

Analista de Requisitos
Especificação de Requisitos Atualizada
Resultado dos Casos de Teste
3
Diretrizes para uma boa especificação

• Separe funcionalidade de implementação
• É necessária uma linguagem de especificação de
  sistemas orientada ao processo
• A especificação deve abranger o sistema do qual o
  software é um componente
• Uma especificação deve abranger o ambiente no
  qual o sistema opera
• Uma especificação de sistema deve ser um modelo
  cognitivo
• Uma especificação deve ser operacional
• A especificação do sistema deve ser tolerante com
  a não completude e ser expansível
• Uma especificação deve ser localizada e
  fracamente acoplada
• (Balzer, Goldman, Wile, 1978)

4
Revisão da Especificação(nível macroscópico)

• Os revisores tentam garantir que a especificação
  seja completa, consistente e precisa
• Questões
• Metas e objetivos do software permanecem
  consistentes com metas e objetivos do sistema?
• O fluxo e a estrutura de informação são
  adequadamente definidas para o domínio da
  informação?
• O modelo de casos de uso estão claros?
• Foram descritas as interfaces importantes para
  todos os elementos do sistema?

5
Revisão da Especificação(nível macroscópico)

• As funções importantes permanecem dentro do
  escopo e cada uma foi adequadamente descrita?
• O comportamento do software é consistente com a
  informação que ele deve processar e as funções
  que deve executar?
• As restrições de projeto são realísticas? Qual é
  o risco tecnológico de desenvolvimento?
  Requisitos de software alternativos foram
  considerados?
• Critérios de Validação foram declarados
  detalhadamente? Eles são adequados para descrever
  um sistema bem sucedido?
• Existem inconsistências, omissões ou
  redundâncias?
• Como as estimativas do Plano de Projeto de
  Software foram afetadas?

6
Revisão da Especificação(nível detalhado)

• A preocupação é com o enunciado da especificação.
  Tenta-se descobrir problemas que possam estar
  ocultos no conteúdo da especificação
• Diretrizes
• Esteja alerta para perceber conectivos
  persuasivos (certamente, claramente, obviamente)
  e perguntar por que eles estão presentes
• Procure termos vagos e peça esclarecimento
  (algum, às vezes, usualmente, freqüentemente)
• Quando forem fornecidas listas que não sejam
  completas, certifique-se de que todos os itens
  sejam entendidos (evite colocar etc, tal como,
  assim por diante)

7
Revisão da Especificação(nível detalhado)

• Esteja certo de que os limites declarados não
  contenham pressuposições não declaradas
• os códigos válidos variam de 0 a 100 - números
  inteiros ou reais?
• Cuidado com verbos vagos. Há muitas maneiras de
  interpretá-los
• manuseado, rejeitado, pulado
• Cuidado com pronomes "pendentes
• o módulo I/O comunica-se com o módulo de
  validação de dados e seu sinal de controle está
  ligado. Sinal de controle de qual dos dois
  módulos?
• Procure declarações que impliquem certeza
  (sempre, cada, todos, nunca) e depois peça prova

8
Revisão da Especificação(nível detalhado)

• Quando um termo for explicitamente definido num
  lugar, evite utilizar outras definições para o
  mesmo termo (normalização dos termos documento -
  arquivo)
• Quando uma estrutura for descrita em palavras,
  verifique se há um gráfico ou uma figura para
  auxiliar a compreensão
• Quando um cálculo for especificado, desenvolva
  pelo menos dois exemplos

9
Desenvolvimento orientado a reuso
10
O que vem depois?

• A especificação de Requisitos e os modelos
  elaborados na Análise são a base para o design do
  sistema
• A fase de design vai evoluir os modelos
  incorporando características de implementação
• Neste momento
• é importante uma abordagem gerencial para
  incrementar a produtividade
• é importante garantir que os modelos do software
  atendam aos requisitos

11
Desenvolvimento orientado a reuso

• Baseado em reutilização de componentes de
  software
• Podem ser acessados com alguma infra-estrutura de
  integração para estes componentes
• Design com reuso
• reuso de sistemas de aplicações COTS
• reuso de componentes
• reuso de funções
• Vantagens
• reduzir a quantidade de software a ser
  desenvolvido
• reduzir o prazo de desenvolvimento
• reduzir os custos

12
Sistemas COTS

• COTS (Commercial off-the-shelf)
• Produtos de Prateleira componente oferecido por
  um terceiro
• Um sistema de aplicações pode ser reutilizado
  pela sua incorporação, sem mudança, em outros
  sistemas
• Exemplo
• Sistemas de Comércio Eletrônico
• Base de Dados
• Compra e Venda de Produtos (carrinho de compra)
• Processo de Pagamento

13
Sistemas COTS

• Desvantagens
• O produto final pode não ser aquele que o cliente
  pediu
• Adequação dos requisitos é inevitável
• Problemas com interoperabilidade de sistemas COTS
• Controle fraco sobre a evolução do sistema
• Suporte técnico dos fabricantes de COTS

14
Validação dos Requisitos
15
Validação dos Requisitos

• Será que realmente entendí o que o cliente
  deseja?
• Devo me certificar de que não houve falha em
  nossa interação (comunicação)
• Há diversas técnicas de validação

16
Validação de Requisitos

• Demonstrar que os requisitos definem o sistema
  que o cliente realmente deseja
• Custos com erros de requisitos são altos
• Consertar um erro de requisitos após entrega do
  sistema pode custar mais de 100 vezes o custo de
  um erro de implementação

17
Validação de Requisitos

• Validade O sistema possui as funções para suprir
  as necessidades dos usuários?
• Completude Foram incluídas todas as funções
  requisitadas pelo cliente?
• Consistência Existe algum requisito conflitante?
• Não ambíguos Todos estão descritos de forma
  clara e objetiva?
• Verificação Os requisitos podem ser verificados?
  
• Rastreáveis os requisitos tem definidos
• A origem?
• As interdependências entre os requisitos?
• Os relacionamentos com os diagramas de projeto e
  componentes de implementação?

18
Técnicas de Validação de Requisitos

• Revisões de Requisitos
• Análise manual sistemática dos requisitos
• Prototipação
• Uso de modelo executável (interfaces) do
  sistema para avaliar requisitos
• Geração de Casos de Teste
• Desenvolver testes específicos para avaliar os
  requisitos
• Análise de Consistência Automática
• Avaliar uma especificação dos requisitos

19
Processo de Projeto de Sistemas- Prototipação
20
Processo de Projeto de Sistemas - Prototipação

• Uma forma de avaliação de interface é a
  prototipação
• Provê a avaliação das interfaces junto aos
  clientes, com o auxílio de técnicas apropriadas
  (usabilidade)
• A partir desta avaliação um novo ciclo de
  especificação, prototipação e avaliação deve ser
  realizada

21
Processo de Projeto de Interfaces
22
Prototipação

• O protótipo permite ao projetista avaliar seu
  projeto ao longo do processo de criação
• A prototipação é parte essencial do processo de
  projeto de interface

23
Prototipação

• O esforço envolvido na especificação, no projeto
  e na implementação de uma interface com o usuário
  representa parte significativa dos custos de
  desenvolvimento de aplicações
• Como este é um artefato não-acabado e com
  finalidade de testes, a sua construção deve ser
  rápida e de baixo custo

24
Ferramenta para especificar e gerenciar requisitos
25
Ferramentas de Especificação Automatizadas

• 1a categoria
• técnicas automatizadas que nada mais são do que
  um método manual que foi complementado com uma
  ferramenta CASE
• possibilitam que o analista atualize informações
  e rastreie as conexões entre representações novas
  e existentes do sistema
• Ex RequisitePro (IBM)

26
Ferramentas de Especificação Automatizadas

• 2a categoria
• técnicas automatizadas que fazem uso de uma
  notação especial (na maioria dos casos, essa é
  uma linguagem de especificação de requisitos) que
  foi explicitamente projetada para processamento
  usando-se uma ferramenta automatizada
• Ex PSL/PSA (linguagem de especificação PSL)

27
Rastreabilidade e Gestão de Mudanças
28
Rastreabilidade e Gestão de Mudanças

• Avaliar o impacto nos requisitos
• Validar com o cliente
• Notificar os envolvidos
• Atualizar as especificações de requisitos
• Garantir a rastreabilidade nos requisitos

Necessidade
Analista de Negócios
Solic. Mudança
Analista de Requisitos
Documento de Visão Atualizado
Especificação de Requisitos Atualizada
29
Gerência de Mudanças

• Requisitos são inevitavelmente incompletos e
  inconsistentes
• Requisitos novos surgem durante o processo
• mudanças nas necessidades do negócio
• melhor entendimento do sistema que está sendo
  desenvolvido
• Diferentes pontos de vista têm diferentes
  requisitos e esses geralmente são contraditórios
• É função do analista durante a elicitação de
  requisitos identificar
• Requisitos contraditórios
• Tendências de mudanças

30
Processo de Gerência de Mudanças
31
O que é Baseline ?

• Baseline linha base
• Uma baseline é uma 'imagem' de uma versão de cada
  artefato no repositório do projeto
• Funciona como um padrão oficial básico para os
  trabalhos subseqüentes
• Somente mudanças autorizadas podem ser efetuadas
  na baseline
• Uma baseline de requisitos é uma versão da
  especificação de requisitos
• Todo o conjunto

32
Gerência de Mudanças

• O Gerenciamento de Mudanças envolve
• a identificação da baseline de requisitos
• a restrição de mudanças
• a auditoria das mudanças
• Que mudanças já foram efetuadas?
• Por que?
• Quais os problemas?
• Uma mudança nos requisitos pode implicar em
  alterações em um ou mais modelos subsequentes do
  software

33
Gerência de Mudanças

• Mudança
• Terá que ser efetuado um planejamento para
  acomodação da mudança
• Custo
• Prazo
• Revisar requisitos para evitar a introdução de
  conflitos
• Questionar stakeholders que especificaram um
  requisito sendo alterado para obter concordância
  com a alteração

34
Rastreabilidade
35
Rastreabilidade

• Responsável por dependências entre requisitos,
  suas origens e projeto do sistema
• Rastreamento de Origem
• Associação entre requisitos e stakeholders que
  propuseram tais requisitos

36
Rastreabilidade

• Rastreamento de Requisitos
• Associação entre requisitos dependentes
• Rastreamento de Projeto
• Associação dos requisitos com o projeto
• Usar hipertexto ou referência cruzada
• Ou matriz de rastreamento

37
Rastreabilidade
Requisitos
Req A
1
Requisitos Detalhados(Casos de Uso)
Req B
3
4
2
Projeto
Teste
Doc. Usuário
Modelos
Suítes Teste
Plano
38
Rastreabilidade Análise de Impacto

• Links dos requisitos devem ser marcados como
  suspeitos
• Links suspeitos devem ser analisados

39
Exemplos de padrões de Rastreabilidade
Doc. Visão ltRequisito Negóciogt
Glossário ltTermogt
Doc. Regras de Negócio ltRegra Negóciogt
Esp. Suplementar ltEsp. Suplemgt
Esp. Caso de Uso ltCaso de Usogt
40
Rastreabilidade
Necessidades
Regra de Negócio
Glossário
Requisito de Negócio
Requisito de Produto
41
Gerência de Escopo
42
Gerência de escopo

• O escopo de um projeto é definido pelo conjunto
  de requisitos alocados para ele
• Para o projeto se adequar aos recursos
  disponíveis (tempo, pessoas e dinheiro) é
  primordial o gerenciamento de escopo com êxito

43
Gerência de escopo

• Inclui certificar-se que o projeto não crescerá
  além dos
• Requisitos necessários
• Orçamento planejado
• Prazo estabelecido

44
Gerência de escopo

• É feito com o detalhamento do fluxo de trabalho
  com a finalidade de
• Priorizar e refinar as informações fornecidas
  para selecionar as características e os
  requisitos que serão incluídos
• Listar o conjunto de casos de uso (ou cenários)
  que representam alguma funcionalidade central e
  significativa
• Definir quais atributos dos requisitos e
  rastreabilidades devem ser mantidas

45
Exemplos de Template adotado numa grande empresa
de TI
46

• Documento de Visão (VIS)
• Glossário (GLOS)
• Documento de Especificação de Caso de Uso (UCS)
• Documento de Especificação Suplementar (SUPL)
• Documento de Regras de Negócio (RN)

47
Informações de Todos os Documentos

• Código do Software
• Nome do Software
• Histórico de Revisões
• Data
• Versão
• Descrição
• Autor

48
Documento de Visão (VIS) 1/2

• Objetivo
• Referências
• Visão Geral do Problema
• Visão Geral do Ambiente Atual
• Envolvidos (Função/Papel, Descrição, Órgão)
• Usuários (Função/Papel, Descrição, Órgão,
  Envolvido)
• Visão Geral da Solução Proposta

49
Documento de Visão (VIS) 2/2

• Requisitos de Negócio
• Funcionais
• ltRequisito Funcional 1gt
• ltRequisito Funcional Ngt
• Não Funcionais
• ltRequisito Não Funcional 1gt
• ltRequisito Não Funcional Ngt
• Inversos
• ltRequisito Inverso 1gt
• ltRequisito Inverso Ngt
• Restrições

50
Documento de Visão (VIS) exemplo
51
Glossário (GLOS)

• Definições
• ltTermo 1gt
• ltsignificado 1gt
• Referências

52
Glossário (GLOS) exemplo
53
Documento de Especificação de Caso de Uso (UCS)

• ltNome do Caso de Usogt
• Breve Descrição
• Referências
• Atores
• Pré-condições
• ltpré-condição 1gt
• Fluxos de Eventos
• Fluxo Básico
• 1. Este caso de uso começa quando o ltatorgt ...
• 2. ...
• Fluxos Alternativos
• A1 ltnome do fluxo alternativo 1gt
• Se no passo ltnº do passogt do fluxo
  básicoalternativo ltcondiçãogt então
• 1. ...
• 2. ...
• ltpara onde Caso de Uso retornagt o Caso de Uso
  termina.

54
Documento de Especificação de Caso de Uso (UCS)

• Pontos de Extensão
• ltponto de extensão1gt
• Se no passo ltnº do passogt do fluxo
  básicoalternativo ltcondiçãogt, o caso de uso
  ltnome do caso de uso extendgt é acionado.
• Casos de Uso Incluídos
• ltnome do caso de uso incluído1gt
• Pós-Condições
• ltpós-condição1gt
• Outros Diagramas
• ltnome do diagramagt

55
Documento de Especificação de Caso de Uso (UCS)
exemplo
56
Documento de Especificação Suplementar (SUPL)

• Usabilidade
• ltrequisito de usabilidade 1gt
• Confiabilidade
• ltrequisito de confiabilidade 1gt
• Desempenho
• ltrequisito de performance 1gt
• Ambiente Operacional
• ltrequisito de ambiente operacional 1gt
• Segurança e Controle de Acesso
• ltrequisito de Segurança/Controle de Acesso 1gt
• Outras Categorias de Requisitos
• ltcategoria 1gt
• ltrequisito 1 da categoria 1gt
• Referências

57
Documento de Especificação Suplementar (SUPL)
exemplo
58
Documento de Regras de Negócio (RN)

• Regras de Negócio
• ltregra de negócio 1gt
• ltregra de negócio ngt
• Referências
• Documento Opcional

59
Documento de Regras de Negócio (RN) exemplo
60
Rastreabilidade Proposta

• Matrizes de Rastreabilidade
• Regra de Negócio para Caso de Uso
• Termo para Regra de Negócio
• Requisito de Negócio para Caso de Uso
• Requisito de Negócio para Especificação
  Suplementar

61
Rastreabilidade Proposta
62
Exercício Extra

• Os grupos apresentam a Agenda Telefônica, sendo
  discutida a modelagem proposta
• entregar solução aos professores
• distribuir solução xerocada, como exemplo

63
Referências Bibliográficas 1/2

• Balzer, R.M. Goldman, N.Wile, D. Informality in
  program specifications. IEEE Transactions on
  Software Engineering, Ney York, V.SE-4, p.94-103,
  1978.
• Breitman, K. Sayão, M. Gerência de Requisitos.
  Simpósio Brasileiro de Engenharia de Software -
  SBES, 2005.
• Delicato, F. Modelagem de Requisitos. Notas de
  Aula. RN L UFRN. 2006.
• Engenharia de Requisitos. RJ PUC-Rio.
  http//www.maxwell.lambda.ele.puc-rio.br/cgi-bin/P
  RG_0599.EXE/6954_3.PDF?NrOcoSis19742CdLinPrgen
  
• Fortes, R.P.M. Capítulo 6 Princípios Fundamentais
  da Análise de Requisitos Engenharia de Software
  Pressman. Notas de aula. SP USP, 2006.
• Leite, J. III. Requisitos são Frases. Notas de
  aula. RJ Puc-Rio. 1997.
• Mota, A. Engenharia de Requisitos. Notas de aula.
  PE UFPE. 2006.
• PETROBRAS, Documento de Gerenciamento de
  Requisitos. PI-PR-11-00132-0. TI/IDTA, 2006.

64
Referências Bibliográficas 2/2

• Processos da Engenharia de Requisitos elicitação
  e análise de requisitos. Notas de aula. BA
  UFBa, 2005
• Sanchez, M.L. Modelagem Semi-formal de Sistemas
  Orientação a Objetos. Notas de Aula. UFF, 2006.
• Sommerville, I. Engenharia de Software, São
  Paulo Pearson Addison Wesley, 2003.
• Techniques for Requirements Elicitation.
  http//www-di.inf.puc-rio.br/karin//pos/goguen.pd
  f
• Valacich, J et al. Essential of systems Analysis
  Design. New Jersey Pearson Education, 2001.