Aula4 levantamento requisitos

761 visualizações

Publicada em

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
761
No SlideShare
0
A partir de incorporações
0
Número de incorporações
38
Ações
Compartilhamentos
0
Downloads
30
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Aula4 levantamento requisitos

  1. 1. Engenharia de Software Aula 4 – Levantamento de Requisitos do Sistema Profa. Dra. Judith Pavón Universidade Salvador – UNIFACS 2012
  2. 2. Objetivo da aulaO objetivo desta aula é apresentaralgumas técnicas de Levantamento deRequisitos. 2
  3. 3. Conteúdo1. Análise do Problema2. Técnicas de levantamento de requisitos3. Casos de Uso 3
  4. 4. Análise do Problema Domínio do Problema Conceitos, processos, necessidades, objetivos, Analistas termos..Clientes, usuários, etc. Torna-se nosso problema, compreender o problema dos usuários (de negócio/técnicos)
  5. 5. Análise do Problema Análise de problemas - processo de compreender um problema e propor soluções para resolver esse problema. Entender o problema a ser resolvido antes de iniciar o desenvolvimento da aplicação. Quando se considera este tópico (análise do problema) como principal preocupação no levantamento de requisitos denomina-se “processo de descoberta de requisitos orientado ao problema”. identificar os stakeholders entender definir as as causas fronteiras do da solução problema acordar na identificar definição as do restrições problema da solução
  6. 6. Análise do ProblemaAcordar na definição do problema Como formular um problema? O Problema de Descrição do Problema Afeta Os Stakeholders afetados pelo problema Resultando em Qual é o impacto do problema? Benefícios Indicação da solução proposta e uma lista de benefícios chaves
  7. 7. Análise do ProblemaAcordar na definição do problema Exemplo de formulação do problema O Problema de Solução inadequada e fora dos prazos das requisições de serviço dos clientes Afeta Nossos clientes, equipe de suporte ao cliente, outros técnicos Resultando em Insatisfação do cliente e dos empregados, sentimento de que qualidade dos serviços é inadequada, e queda nas vendas. Benefícios Solução: prover acesso em tempo real a uma base de dados de problemas à equipe de suporte. Benefícios: rápido acesso à informação, agilização dos processos operacionais.
  8. 8. Entender as Causas do Problema Análise da raíz do problema : Forma sistemática de descobrir o que está por trás de um problema ou dos seus sintomas
  9. 9. Entender as Causas do Problema Exemplo de técnica: diagrama de espinha de peixe pouco tempo para causa X escrever os relatórios atrasos na entrega da documentação do projeto os conteúdos causa Z causa Y estão dispersos
  10. 10. Entender as Causas do Problema Quais são as causas do problema? A maior parte das vezes não vale a pena considerar TODAS as causas que são raiz do problema!!!... (???) Porque os custos seriam muito superiores aos benefícios... Como saber quais as causas que vale a pena considerar na resolução do problema?
  11. 11. Entender as Causas do Problema Selecionar as causas a considerar: ­ Recolher dados sobre a incidência de cada causa. ­ Desenhar um diagrama de Pareto.
  12. 12. Entender as Causas do Problema diagrama de Pareto das causas raíz 50 45 40 35 30 25 20 15 10 5 0 dispersão de conteúdos causa x tempo de escrita do relatório causa y causa z Consiste em um gráfico de barras que ordena as freqüências dasocorrências da maior para menor e permite a localização das causas mais freqüentes.
  13. 13. Identificar os stakeholders Compreender as necessidades dos interessados no sistema é um fator decisivo no desenvolvimento de uma solução efetiva para um problema ­ Quem são os usuários do sistema? ­ Quem é o cliente (comprador) do sistema? ­ Quem será afetado pelas saídas que o sistema produz? ­ Quem fará a manutenção do sistema? ­ ...
  14. 14. Definir as Fronteiras da Solução E/S SOLUÇÃO E/S OUTROS Usuários SISTEMAS
  15. 15. Identificar as Restrições da Solução Identificar e compreender as restrições impostas ao sistema. Restrições ­ Econômicas; ­ Políticas; ­ Tecnológicas; ­ Sistemas existentes; ­ Ambiente; ­ Recursos.
  16. 16. Entendendo as Necessidades dos StakeholdersDiferentes Necessidades dos Stakeholders Os processos de engenharia de requisitos são dominados por fatores humanos, sociais e organizacionais porque eles sempre envolvem um conjunto de partes interessadas com backgrounds diferentes e com objetivos organizacionais e individuais diferentes As partes interessadas (stakeholders) pelo sistema podem ter uma variedade de background técnico e não técnico e de diferentes disciplinas. usuários finais gestão analistas negociação, documento aprendizagem de requisitos clientes
  17. 17. Entendendo as Necessidades dos StakeholdersCaracterísticas dos Stakeholders mais importantes: Conhecimento do assunto; Poder de decisão; Objetividade; Representatividade.
  18. 18. Entendendo as Necessidades dos Stakeholders Fatores que influenciam os requisitos: ­ Personalidade e status dos stakeholders. ­ Os objetivos pessoais dos indivíduos dentro da empresa. ­ O grau de influência política dentro de uma organização.
  19. 19. Entendendo as Necessidades dos Stakeholders Por que capturar ou levantar requisitos é tão difícil? ­ Usuários são uma fonte imperfeita de informação:  Vários usuários...inconsistências!  Falta da visão geral do processo.  Falta da visão técnica.
  20. 20. Entendendo as Necessidadesdos Stakeholders“Conversa com o alienígena” Dificuldades de comunicação entre usuários e desenvolvedores. Mundos diferentes, culturas e termos distintos. Comunicação gera problemas que afetam diretamente os requisitos no meio do caminho. O quê fazer? Buscar aprender sobre a área de conhecimento das pessoas do outro grupo. Stakeholder Desenvolvedor
  21. 21. Entendendo as Necessidades dos Stakeholders Problema Proposta de SoluçãoUsuários não sabem exatamente o que querem ou Reconheça o usuário como o especialista da área esabem mas não são capazes de organizar suas aprecie seu conhecimento; tente meios coletivos deidéias para explicar aos desenvolvedores. identificação de requisitos.Usuários somente descobrem o que realmente Gere protótipos rápidos antes de desenvolver oquerem quando os desenvolvedores lhes mostram sistema propriamente dito, apenas para validaçãoalgum resultado preliminar. dos usuários.Os analistas acham que entendem melhor os Aproxime o analista do usuário de forma que esteproblemas do usuário do que o próprio usuário. verifique se seu conhecimento procede neste caso.Todos acreditam que existem razões políticas por Seres humanos são seres políticos: devemostrás das ações dos outros. aprender a lidar com estes aspectos.
  22. 22. Identificação da Fonte de InformaçãoIdentificação das fontes de informação: Stakeholders (Clientes, Usuários, Patrocinadores) Outras fontes de Informação: ­ Documentação do macro-sistema; ­ Políticas; ­ Manuais; ­ Memos, atas, contratos... ­ Livros sobre tema relacionado; ­ Outros sistemas da empresa; ­ Outros sistemas externos.
  23. 23. Identificação da Fonte de InformaçãoPriorizar as fontes de informação: Stakeholders mais importantes; Documentos mais mencionados ou utilizados; Rede de comunicações entre os componentes do macro- sistema.
  24. 24. Técnicas de Levantamento (Elicitação) Entrevistas e Reuniões. Análise de Documentos. Brainstorm. Prototipagem. Workshop de Requisitos. ­ JAD. Questionários. Observação Direta. Casos de Uso. Role Playing. Storyboard.
  25. 25. Técnicas de LevantamentoEscrever requisitos Requisitos são geralmente escritos como textos em linguagem natural complementados por diagramas e modelos. Geralmente são iniciados com a frase: “O sistema deve permitir.....”Recomendações Evitar cláusulas condicionais complexas que podem confundir. Use a linguagem de forma simples, consistente e concisa. Use sentenças diretas e objetivas. Defina requisitos verificáveis. Evite ambigüidades. Evite sentenças muito longas. Complemente a linguagem natural com outras descrições de requisitos. Não assuma que todos os leitores dos requisitos tenham o mesmo background e usem a sua terminologia. Permita tempo para revisão e ser for necessário reescreva os requisitos.
  26. 26. Casos de Uso  Os casos de uso referem-se aos serviços ou processos de negócio que podem ser utilizados de alguma maneira pelos usuários do sistema, como emitir um relatório ou comprar um produto.  Os casos de uso são utilizados para expressar e documentar o comportamento ou funções do sistema.  Um modelo de casos de uso é composto pelo diagrama de casos de uso e a documentação dos elementos do modelo, Caixa Eletrônico Consultar Saldo Efetuar Saque Consultar Saldo - Breve descrição - Breve descrição Cliente - Fluxo de eventos - Fluxo de eventos Efetuar Saque Gerente Consultar Extrato Consultar Extrato - Breve descrição - Fluxo de eventos O Hardware é a fronteira
  27. 27. Dúvidas 27

×