06 Requisitos

830 visualizações

Publicada em

Notas de aula, baseadas no Sommerville e no Schach.

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
830
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
37
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

06 Requisitos

  1. 1. Engenharia de Requisitos Elicitação, detalhamento e documentação.
  2. 2. O que é um projeto de sucesso? “Satisfaz seus clientes e patrocinadores com resultados que atendem seus objetivos dentro das restrições de tempo e custo, com produtos de qualidade, mantendo e promovendo relações harmoniosas entre os envolvidos e contribuindo pro aprendizado da organização.” Daniel Garnier
  3. 3. “A parte mais difícil de construir um sistema de software é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil quanto estabelecer os requisitos técnicos detalhados… Nenhuma outra parte danifica tanto o sistema resultante se for feita de forma errada. Nenhuma outra parte é mais difícil de retificar posteriormente.” Frederick Brooks
  4. 4. Custo para se reparar um defeito
  5. 5. Requisitos “Eu sei que você acredita que compreendeu o que eu disse, mas não estou certo de que o que você ouviu era realmente o que eu queria dizer!”
  6. 6. Identificando requisitos  Requisito é a condição para se alcançar determinado fim (Dicionário Houaiss)  É a descrição dos serviços e das restrições de um sistema (Somerville)  Uma capacidade do software necessária ao usuário para resolver um problema para atingir um objetivo (Dorfman)
  7. 7. Processo de requisitos do software
  8. 8. O processo de elicitação e análise de requisitos
  9. 9. Técnicas para análise de requisitos  Entrevista (reunião, call, estruturada ou não)  Questionários (modelos padrão ou personalizados)  Análise de formulários (automatização)  Câmeras de vídeo (dia a dia do usuário)  Cenários  Cartões de estórias  Árvores de decisão  Prototipação
  10. 10. Classificação dos requisitos  Funcionais • Descrever a funcionalidade ou os serviços do sistema. • Depende do tipo de software, possíveis usuários e o tipo de sistema em que o software é usado. • Requisitos funcionais dos usuários podem ser declarações de alto nível a respeito do que o sistema deve fazer. • Requisitos funcionais do sistema devem descrever detalhadamente os serviços do sistema.  Não Funcionais
  11. 11. Classificação dos requisitos  Funcionais  Não Funcionais • Esses requisitos definem as propriedades e as restrições do sistema por exemplo, confiabilidade, tempo de resposta e ocupação de área. • As restrições são capacidades de dispositivos de E/S, as representações do sistema, etc. • Os requisitos de processo também podem ser especificados impondo um IDE particular, linguagem de programação ou método de desenvolvimento. • Os requisitos não-funcionais podem ser mais críticos do que os requisitos funcionais. Se esses não forem atendidos, o sistema pode ser inútil.
  12. 12. Classificação dos requisitos  De usuário  Declarações em linguagem natural com diagramas dos serviços que o sistema deverá fornecer e suas restrições operacionais. Escrito para os clientes.  De Sistema  Um documento estruturado estabelecendo descrições detalhadas das funções do sistema, serviços e restrições operacionais. Define o que deve ser implementado assim, pode ser parte de um contrato entre o cliente e o empreiteiro.
  13. 13. Classificação dos requisitos
  14. 14. Classificação dos requisitos  De usuário  De Sistema
  15. 15. Classificação dos requisitos
  16. 16. Características de bons requisitos  Não ambíguo  Verificável  Determinístico  Rastreável  Correto
  17. 17. Não ambíguo  Ambiguidade = incerteza por causa da obscuridade ou indistinção  Escrever para outra pessoa ler  Problemas:  Uso de pronomes  “O sistema de RH deverá permitir somente cinco registros de dependentes válidos e tipos de planos de saúde; ele deve incluir o mais velho”  Acrônimos e siglas  Indeterminação  “O sistema deverá fazer as correções no registro quando possível”  Assumir conhecimento prévio Características de bons requisitos
  18. 18. Verificável  Pode ser testado completamente de modo razoável (conforme a sua criticidade)  Assegurar que  Sistema funciona corretamente  As exceções são tratadas de forma adequada  Suporta vários conjuntos diferentes de dados  Exemplo:  “O sistema deve ser amigável” Características de bons requisitos
  19. 19. Determinístico  Precisa necessariamente ser determinável – todos os caminhos devem ser previstos  “O sistema deve enviar novos registros aos sistema Financeiro a cada cinco minutos”  E se não tiver novos registros neste período? Características de bons requisitos
  20. 20. Rastreável  De onde veio este requisito?  No que ele vai se transformar (ou já se transformou) no sistema?  Caminho do requisitante à implementação em duas vias  É muito importante quando  Um requisito é alterado  Um componente de software é alterado  Se negocia prioridades (ou cortes) Características de bons requisitos
  21. 21. Correto  Consistência (um requisito não pode contradizer o outro)  Deve ser assegurada a acuracidade e a correção no texto do requisito  Não enrolar  Sentenças com começo, meio e fim Características de bons requisitos
  22. 22. Atores no processo de requisitos  Clientes e usuários  Gerentes de negócios (áreas afetadas)  Gerente e líderes do projeto  Projetistas de software  Testadores
  23. 23. Documentação de requisitos  O documento de requisitos de software é a declaração oficial do que é demandado dos desenvolvedores do sistema.  Deve incluir ambas, uma definição de requisitos do usuário e uma especificação de requisitos do sistema.  NÃO é um documento de projeto. Na medida do possível, deve definir O QUE o sistema deve fazer ao invés de COMO deve fazê-lo.  Documento de especificação de requisitos: o que o desenvolvedor precisa saber  Lembrar: documento de visão, glossário e requisitos se complementam
  24. 24. Documentação de requisitos
  25. 25. Documentação de requisitos  Padronização da sintaxe  Modelo de user histories  Modelo em linguagem natural  Modelo de casos de uso
  26. 26. Estrutura do documento de requisitos
  27. 27. Estrutura do documento de requisitos
  28. 28. Formas de escrever uma especificação de requisitos de sistema
  29. 29. Usuários do documento de requisitos
  30. 30. Usuários do documento de requisitos
  31. 31. Validação dos requisitos
  32. 32. Revisão dos requisitos  Rever metas e objetivos estabelecidos para o sistema  Comparar requisitos metas o objetivos  Descrever o ambiente operacional  Examinar  interfaces  fluxo de informações  funções  Verificar omissões, imperfeições e inconsistências  Documentar riscos  Discutir sobre como o sistema será testado
  33. 33. Desafios da fase de requisitos  Funcionários do cliente podem sentir-se intimidados/substituídos pelos computadores  Habilidade em negociação  Pouco tempo para as discussões mais profundas (essenciais)  Flexibilidade e objetividade são essenciais
  34. 34. Gerenciamento de requisitos  Gerenciamento de requisitos é o processo de gerenciar os requisitos em constante mudança durante o processo de engenharia de requisitos e desenvolvimento de sistemas.  Após o sistemas começar a ser usado, surgem novos requisitos.  É preciso manter o controle das necessidades individuais e manter ligações entre os requisitos dependentes para que você possa avaliar o impacto das mudanças nos requisitos.  É necessário estabelecer um processo formal para fazer propostas de mudança e ligar essas aos requisitos de sistema.
  35. 35. Mudanças nos requisitos  O ambiente técnico e de negócios do sistema sempre muda após a instalação.  Um novo hardware pode ser introduzido, pode ser necessário para a interface do sistema com outros sistemas, as prioridades do negócio podem mudar (com as consequentes alterações no sistema de apoio necessário) e, podem ser que o sistema deve, necessariamente, respeitar.  As pessoas que pagam por um sistema e os usuários desse sistema raramente são as mesmas pessoas.  Clientes do sistema impõem requisitos devido a restrições orçamentais e organizacionais. Esses podem entrar em conflito com os requisitos do usuário final e, após a entrega, pode ser necessário adicionar novos recursos para suporte ao usuário, caso o sistema seja para atender a seus objetivos.  Sistemas de grande porte costumam ter uma comunidade de usuários diversos, com muitos usuários tendo necessidades diferentes e prioridades que podem ser conflitantes ou contraditórias.  Os requisitos do sistema final são, inevitavelmente, um compromisso entre eles e, a experiência mostra que, muitas vezes se descobre que o balanço de apoio dado aos diferentes usuários precisa ser mudado.
  36. 36. Planejamento de gerenciamento de requisitos  Estabelece o nível de detalhamento necessário para o gerenciamento de requisitos. Decisões do gerenciamento de requisitos:  Identificação de requisitos. Cada requisito deve ser identificado exclusivamente para que ele possa ser comparado com outros requisitos.  Processo de gerenciamento de mudanças. Esse é o conjunto de atividades que avaliam o impacto e o custo das mudanças. Esse processo é discutido em mais detalhes na seção seguinte.  Políticas de rastreabilidade. Essas políticas definem as relações entre cada requisito e entre os requisitos e o projeto do sistema que deve ser registrado.  Ferramentas de suporte. As ferramentas de suporte que podem ser usadas ​​variam desde sistemas especialistas, sistemas de gerenciamento de requisitos até planilhas e sistemas de banco de dados simples.
  37. 37. Gerenciamento de mundança de requisitos  Decidir se uma mudança de requisitos deve ser aceita.  Análise de problema e especificação de mudanças  Durante essa fase, o problema ou a proposta de mudança é analisada para verificar se é válida. O feedback dessa análise é devolvido para o solicitante, que pode responder com uma proposta mais específica de mudança dos requisitos, ou decidir retirar o pedido.  Análise de mudanças e custos  O efeito da mudança proposta é avaliado por meio de informações de rastreabilidade e conhecimento geral dos requisitos do sistema. Uma vez que essa análise é concluída, toma-se a decisão de prosseguir ou não com a mudança de requisitos.  Implementação de mudanças  O documento de requisitos e, se necessário, o projeto e implementação do sistema, são modificados. Idealmente, o documento deve ser organizado de modo que as mudanças possam ser facilmente implementadas.
  38. 38. Gerenciamento de mudança de requisitos
  39. 39. AVISOS PAROQUIAIS São avisos fixados nas portas de uma igreja, todos eles reais, escritos com muito boa vontade e muito má redação.
  40. 40. AVISOS AOS PAROQUIANOS Para todos os que tenham filhos e não o saibam, temos na paróquia uma área especial para crianças.
  41. 41. AVISOS AOS PAROQUIANOS Prezadas senhoras, não esqueçam a próxima venda para beneficencia. É uma boa ocasião para se livrar das coisas inúteis que há na sua casa. Tragam os seus maridos!
  42. 42. AVISOS AOS PAROQUIANOS O mês de novembro finalizará com uma missa cantada por todos os defuntos da paróquia.
  43. 43. Checklist  Os requisitos:  Estão corretos?  São consistentes?  Estão completos?  São realistas?  Descrevem algo necessário para o cliente?  Podem ser verificados?  Podem ser rastreados?
  44. 44. Relembrando
  45. 45. Pontos importantes  Você pode usar uma variedade de técnicas para a elicitação de requisitos, incluindo entrevistas, cenários, casos de uso e etnografia.  A validação dos requisitos é o processo de verificação da validade, consistência, completude, realismo e verificabilidade dos requisitos.  Mudanças organizacionais e técnicas, e de negócios, inevitavelmente levam a mudanças nos requisitos de um sistema de software.  O gerenciamento dos requisitos é o processo de gerenciamento e controle dessas mudanças.
  46. 46. Engenharia de Requisitos Elicitação, detalhamento e documentação.

×