Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Es capítulo 4 - engenharia de requisitos

688 views

Published on

Engenharia de Software

Published in: Education
  • Be the first to comment

  • Be the first to like this

Es capítulo 4 - engenharia de requisitos

  1. 1. Universidade Federal da Paraíba - UFPB Programa de Pós Graduação em Informática- PPGI Engenharia de Software Mestrado – UFPB Mestranda Stephany Vitório Capítulo 04 do livro de Sommerville Ed. 9 Engenharia de Requisitos
  2. 2. Roteiro  O que é Requisito, Engenharia de Requisitos e Stakeholder?  Importância da Engenharia de Requisitos  Atividades principais da ER  Requisitos  Tipos de Requisitos  Requisitos de Qualidade  Características Importantes
  3. 3. O que é requisito?  Uma descrição do que o sistema tem que fazer. “Condição que se deve satisfazer para alcançar um objetivo”
  4. 4. O que é requisito?  Condição para satisfazer um contrato, um padrão, especificação ou outro documento formalmente imposto.  “Exigência que deve ser cumprida para atingir um objetivo” 
  5. 5. O que é Engenharia de Requisitos?  “É o processo pelo qual os requisitos de um produto de software são coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software.”  “É a ciência que estuda a criação, construção, análise, desenvolvimento e manutenção dos requisitos que devem ser cumpridos por um sistema.”
  6. 6. O que é Engenharia de Requisitos?  Engenharia de requisitos é uma abordagem sistemática e disciplinada para a especificação e gerenciamento de requisitos com os seguintes objetivos:  Conhecer os requisitos pertinentes, alcançar um consenso entre os stakeholders sobre esses requisitos, documentando-os de acordo com as normas dadas e gerenciando-as sistematicamente.  Compreender e documentar os desejos e necessidades dos stakeholders, que especifica o gerenciamento de requisitos para minimizar o risco de entregar um sistema que não atende os desejos das partes interessadas.
  7. 7. O que é Stakeholder?  “É uma pessoa ou uma organização que tem algum impacto direto ou indireto sobre os requisitos do sistema.” Interessados Envolvidos
  8. 8. Importância da Engenharia de Requisitos  “A parte mais árdua na construção de um software consiste exatamente em identificar o que construir . Nenhuma outra fase compromete tanto o resultado do trabalho se elaborada de forma incorreta. Nenhuma outra parte dificulta tanto as correções posteriores.” Frederick P. Brooks  Problemas com requisitos levam a: - Clientes insatisfeitos; - Altos custos; - Perda de reputação; - Compreensão do “problema incorreto”; - Efeito cascata nas demais fases de desenvolvimento de software.
  9. 9. Importância da Engenharia de Requisitos
  10. 10. Problemas de Comunicação
  11. 11. Problemas de Comunicação  Quando conversar com um colega de trabalho ou um cliente, lembre- se de que a comunicação transcende as palavras .” Mari Geuer  Omissão de Requisitos
  12. 12. Sintomas e Causas de uma ER inadequada  Pressão do cliente para uma construção rápida do sistema  “Temos que nos acostumar com a pressão. Mais além, toda vez que sentirmos pressão, mentalizar que isso nos ajuda a alcançar nossos objetivos. Dá-nos mais gás para agir em direção à nossa meta.” Lauro Valente  Requisitos Incorretos
  13. 13. Sintomas e Causas de uma ER inadequada  Suposição incorreta, por parte dos stakeholders, de que muito do assunto é evidente  “Geralmente as pessoas falham em serem bons ouvintes. Elas simplesmente presumem que sabem o que a outra pessoa esta dizendo ou simplesmente porque elas já ouviram isso antes adotam a ideia de que aquela pessoa é igual a outra “  Requisitos Ambíguos
  14. 14. 4 atividades principais da ER Elicitação Documentação Validação Gerenciamento de Requisitos
  15. 15. Elicitação  Para a etapa de identificação, levantamento e detalhamento de requisitos, podem ser utilizadas diversas técnicas, como, entrevista, estudo arqueológico, JAD, brainstorming, dentre outros.  O engenheiro de requisitos precisa extrair, sugar todas as informações possíveis dos stakeholders e identificar requisitos através de pesquisas.
  16. 16. Documentação  Para documentar requisitos podem ser utilizadas a linguagem natural e modelos formais, utilizando UML, como por exemplo, diagrama de estado, sequência, casos de uso e especificações de casos de uso.  É importante registrar as informações coletadas e identificadas na etapa de levantamento de requisitos de forma adequada.
  17. 17. Validação e Negociação  Para negociar e validar os requisitos é importante ter a avaliação de um especialista, de modo que possa ser verificado se o que foi levantado condiz com o que foi solicitado.  Deve ser garantida a qualidade dos requisitos, validando se estão corretos. Para isso é importante negociar com o cliente o que realmente é necessário para o produto.
  18. 18. Gerenciamento  Gerenciar consiste em manter os dados consistentes, com qualidade garantindo que eles possam ser implementados. É uma etapa ortogonal as outras 3 visto que trabalha garantindo a execução destas.  Compreende todas as medidas que são necessárias às exigências de estrutura para que as outras 3 etapas da ER possa ocorrer.
  19. 19. Tipos de Requisitos de Sistema  Requisitos Funcionais - Descrevem os serviços que se espera que o sistema deve oferecer. - Especificam as funcionalidades do sistema.  Requisitos Não Funcionais - Descrevem aspectos de qualidade que o software deverá apresentar, ou as restrições a serem atendidas. - Os requisitos não funcionais referem-se às condições nas quais deve funcionar o sistema. - Podem estar relacionados a propriedades do sistema, tais como, confiabilidade, desempenho, etc.
  20. 20. Como especificar requisitos funcionais?  Linguagem Natural - Os requisitos funcionais podem ser descritos em linguagem natural em nível macro.  Casos de uso - Um modelo de casos de uso é utilizado para representar as funcionalidades do sistema de forma detalhada. - Um modelo de casos de uso identifica quem ou o que interage com o sistema e o que sistema deve fazer. - Casos de uso são técnicas baseadas em cenários onde são identificados atores e sua interação com o sistema.
  21. 21. Requisitos Não Funcionais
  22. 22. TIPOS DE REQUISITOS NÃO FUNCIONAIS (Sommerville)  Requisitos de produtos - São os requisitos que especificam o comportamento do produto. - Exemplo: requisitos de desempenho, que especificam com que rapidez o sistema deve operar.  Requisitos organizacionais - São procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. - Entre os exemplos estão os padrões de processos que devem ser utilizados, os requisitos de implementação, como a linguagem de programação ou a metodologia de processo de desenvolvimento.  Requisitos externos - Abrange todos os requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento. - Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos éticos.
  23. 23. Desafios da Análise de Requisitos  Como descobrir os requisitos;  Como comunicar os requisitos para as outras fases ou equipes do projeto;  Como lembrar dos requisitos durante o desenvolvimento e verificar se foram todos atendidos  Como gerenciar a mudança
  24. 24. Conclusão  Um processo de engenharia de requisitos eficiente evita uma compreensão incorreta dos requisitos.
  25. 25. Universidade Federal da Paraíba - UFPB Programa de Pós Graduação em Informática- PPGI Engenharia de Software Mestrado – UFPB Mestranda Stephany Vitório Capítulo 04 do livro de Sommerville Ed. 9 Engenharia de Requisitos

×