Engenharia de requisitos

636 visualizações

Publicada em

Seminário sobre engenharia de requisitos

Publicada em: Software

Engenharia de requisitos

  1. 1. Engenharia de Requisitos Mailson de Queiroz Proença
  2. 2. Tópicos  A Engenharia de Requisitos  Importância da Engenharia de Requisitos  O que são requisitos?  Requisitos de usuário e de sistema  Funcionais e não funcionais  Documento e Especificação de requisitos  Desenvolvimento de requisitos  Estudo de viabilidade  Elicitação e análise de requisitos  Validação de requisitos  Gerenciamento de requisitos  Principais eventos  Conclusão
  3. 3. A Engenharia de Requisitos  É o ramo da engenharia de software que se preocupa com:  os objetivos, funções e restrições dos sistemas de software.  É também o processo de estabelecer quais serviços e restrições são necessários na operação e desenvolvimento de um sistema.
  4. 4. A Engenharia de Requisitos  Engenharia de Requisitos pode ser dividida em:  Desenvolvimento de Requisitos: Elicitação Análise Especificação Validação  Gerência de Requisitos Gerência de Mudanças Acompanhamento de desenvolvimento e implementação dos requisitos
  5. 5. Importância da Engenharia de Requisitos  Alguns fatos  Um trabalho consistente de análise dos requisitos é a BASE de um projeto de SOFTWARE DE SUCESSO;  Corrigir problemas na fase de especificação de requisitos pode gerar uma economia até 200 vezes maior do que em etapas posteriores.
  6. 6. Importância da Engenharia de Requisitos “Entender os requisitos de um problema está entre as tarefas mais difíceis enfrentadas por um engenheiro de software.” (Pressman, 2011)
  7. 7. Importância da Engenharia de Requisitos  Segundo pesquisa realizada pelo Standish Group* as principais razões que levam a problemas de projeto são identificadas no gráfico: * http://blog.standishgroup.com/ 0 5 10 15 20 25 23 12,8 12,3 11,8 7,5 7 6,4 5,9 5,3 4,3 3,7 % de Respostas FatoresdeProjetosCríticos
  8. 8. O que são requisitos?  São o ponto de partida para toda a definição de um sistema.  Fatores decisivos no desenvolvimento do produto final de um projeto de software.  “Capacidade que o software tem e que o usuário precisa a fim de resolver um problema e atingir seu objetivo.” (Dorfman e Thayer - 1990)
  9. 9. O que são requisitos?  Um requisito pode variar de:  Uma declaração abstrata de alto nível de um serviço a  Uma restrição do sistema para uma especificação matemática funcional.
  10. 10. Níveis de Requisitos  Requisitos de usuário:  são declarações em uma linguagem natural com diagramas de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar.  Requisitos de sistema  são descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software.
  11. 11. Identificação dos Interessados  Além do cliente e o do desenvolvedor, que podem, naturalmente, ter diferentes nomes e títulos, existem provavelmente:  O pessoal de marketing,  O pessoal de testes e garantia de qualidade.  Gerentes de produtos.  Gerente geral.  E uma variedade de “stakeholders” (interessados) que no seu dia-a-dia serão afetados pelo desenvolvimento do novo sistema.
  12. 12. Identificação dos Interessados  Sommerville – 1997 define interessados como: “Qualquer um que se beneficia de forma direta ou indireta do sistema que está sendo desenvolvido.”
  13. 13. Identificação dos Interessados  Dificuldades:  Cada interessado: Tem uma visão diferente do sistema; Obtém diferentes benefícios quando o sistema é desenvolvido com êxito; E está sujeito a diferentes riscos caso o trabalho de desenvolvimento venha a fracassar.
  14. 14. Identificação dos Interessados  Reconhecimento de diversos pontos de vista:  Gerentes Comerciais  Estão interessados no conjunto de recursos que pode ser construído dentro do orçamento e que estarão prontos para atender às oportunidades definidas de ingresso no mercado.  Pessoal do Marketing  Estão interessados nas funções e recursos que irão suscitar o mercado potencial, facilitando a venda do sistema.
  15. 15. Busca de Colaboração  Primeiro: identificar áreas em comum  requisitos com os quais os interessados concordam  Segundo: identificar áreas de conflito  requisitos desejados por um interessado, mas que conflitam com os de outros interessados.
  16. 16. Busca de Colaboração  Colaboração não significa, necessariamente, que os requisitos são definidos por um comitê.  Normalmente existe um “poderoso campeão dos projetos ” (gerente comercial ou técnico sênior) que pode tomar a decisão final sobre quais requisitos que passam pelo corte.
  17. 17. Classificação de Requisitos Com uma breve observação percebemos que há uma infinidade de objetos envolvidos que são requisitos de software, os quais devem ser classificados em dois grandes grupos...  Requisitos Funcionais;  Requisitos Não Funcionais.
  18. 18. Classificação de Requisitos  Requisitos Funcionais:  Descrevem as funcionalidades e/ou serviços do sistema;  Descrevem como o sistema deve reagir a entradas específicas;  Podem ser declarações de alto nível do que o sistema deve fazer;  Devem descrever os serviços de sistema em detalhes;  O que o sistema não deve fazer;
  19. 19. Exemplos de requisitos funcionais  O sistema deve permitir que qualquer usuário possa consultar e visualizar o perfil de outro usuário do sistema.  O sistema deve permitir a inclusão, alteração e inativação dos usuários do sistema.  O sistema deve permitir aos usuários do tipo gerente visualizar relatórios de projetos em aberto e/ou finalizados, e seus respectivos feedbacks.
  20. 20. Imprecisão de requisitos  Problemas surgem quando os requisitos não são precisamente definidos.  Requisitos ambíguos podem ser interpretados de maneiras diferentes pelos desenvolvedores e usuários.  Considere o termo “telas apropriadas”:  Intenção do usuário - telas para cada formato de documento devem ser disponibilizadas.  Intenção do desenvolvedor - disponibilizar uma tela de texto que mostra o conteúdo do documento.
  21. 21. Requisitos completos e consistentes  A princípio, todos os requisitos devem ser completos e consistentes:  Completos: Todas as funções requeridas pelo usuário devem estar definidas.  Consistentes: Não deve haver conflitos ou contradições nas descrições dos recursos de sistema.  Na prática, é quase impossível produzir um documento de requisitos completos e consistentes.
  22. 22. Classificação de Requisitos  Requisitos Não Funcionais:  Definem propriedades e restrições do sistema;  Dizem respeito ao sistema como um todo;  Muitos requisitos não funcionais são também requisitos de qualidade, como confiabilidade, tempo de resposta e espaço em disco;  Outros são restrições ou exigências de uso de tecnologia.
  23. 23. Classificação de Requisitos  Classificação dos Requisitos Não Funcionais: Especificam ou restringem o comportamento do software. Derivados das políticas e procedimentos da organização do cliente e do desenvolvedor. Derivados de fatores externos ao sistema e seu processo.
  24. 24. Exemplos de requisitos não funcionais  Requisito de Produto:  O sistema deve ser capaz de responder até, em média, a 10 requisições por segundo.  Requisito Organizacional:  Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00.  Requisito Externo:  O sistema não deve revelar quaisquer informações pessoais sobre os usuários do sistema, com exceção do nome e número de referência da biblioteca.
  25. 25. Classificação de Requisitos  Métricas para elecitar Requisitos Não Funcionais:  Velocidade:  Transações processadas/segundo;  Tamanho:  Megabytes;  Facilidade de uso:  Tempo de treinamento;  Número de frames de ajuda;
  26. 26. Classificação de Requisitos  Métricas para elicitar Requisitos Não Funcionais:  Confiabilidade:  Probabilidade de indisponibilidade;  Taxa de ocorrência de falhas;  Robustez:  Tempo de reinício após falha;  Percentual de eventos que causam falhas;  Probabilidade de corrupção de dados em caso de falha;  Portabilidade:  Percentual de declarações dependentes do sistema-alvo;
  27. 27. Documento de requisitos de software e Especificação de requisitos
  28. 28. Documento de requisitos de software e Especificação de requisitos  Variabilidade do documento de requisitos  As informações no documento de requisitos dependem do tipo de sistema e da abordagem de desenvolvimento usada.  Normalmente, os sistemas desenvolvidos de forma incremental terão menos detalhes no documento de requisitos.  Os padrões dos documentos de requisitos foram concebidos, tendo como exemplo, a norma IEEE Std 830- 1998.  Esses são aplicáveis, principalmente, aos requisitos para projetos de engenharia de sistemas de grande porte.
  29. 29. Documento de requisitos de software e Especificação de requisitos  Requisitos e Métodos ágeis  A produção de um documento de requisitos é um desperdício de tempo pois esses mudam rapidamente.  Portanto, o documento estará sempre desatualizado.  O XP, por exemplo, usa a engenharia de requisitos incremental e expressa os requisitos como “estórias de usuário”.  Prático para os sistemas de negócios e problemático para sistemas que exigem várias análises pré-entrega (por exemplo, sistemas críticos) ou sistemas desenvolvidos por várias equipes.
  30. 30. Documento de requisitos de software e Especificação de requisitos  O documento de requisitos tem um conjunto diversificado de usuários:  Desde a alta administração da organização que está pagando pelo sistema.  Até os engenheiros responsáveis pelo desenvolvimento do software.
  31. 31. Documento de requisitos de software e Especificação de requisitos  Especificação:  É o processo de escrever os requisitos de usuário e de sistema em um documento de requisitos.  Idealmente, os requisitos de usuário e de sistema devem ser:  Claros  Inequívocos  De fácil compreensão  Consistentes  Completos
  32. 32. Processos de engenharia de requisitos  Os processos de engenharia de requisitos podem incluir quatro atividades de alto nível:  Estudo de viabilidade;  Elicitação e Análise;  Especificação;  Validação.
  33. 33. Processos de engenharia de requisitos Estudo da viabilidade Relatório de viabilidade Validação de requisitos Especificações de requisitos Requisitos de usuários e de sistema Elicitação e análise de requisitos Modelos de sistema Documentação de requisitos
  34. 34. Processos de engenharia de requisitos
  35. 35. Estudo de Viabilidade  Decidir se vale a pena ou não gastar tempo e esforço com o sistema proposto;  Sistemas novos devem começar com um estudo da viabilidade;  Responder Perguntas:  O sistema contribui para os objetivos gerais da organização?  O sistema pode ser implementado com a tecnologia atual dentro das restrições de custo e de prazo?  O sistema pode ser integrado a outros?  Que contribuição direta o sistema trará para os objetivos da empresa?
  36. 36. Relatório de Viabilidade  O relatório pode:  Propor mudanças no enfoque, no orçamento e/ou no cronograma;  Sugerir outros requisitos de alto nível para o sistema;  Simplesmente cancelar o projeto de desenvolvimento do sistema.
  37. 37. Elicitação e análise de requisitos  Reúne informações sobre o sistema proposto e os existentes.  O objetivo é descobrir:  O domínio de aplicação;  Serviços que devem ser fornecidos pelo sistema;  Restrições associadas ao domínio ou serviços;  Envolvem diversos stakeholders;
  38. 38. Atividades da Elicitação e análise de requisitos 1. Descoberta de Requisitos 2. Classificação e organização de requisitos 3. Priorização e negociação de requisitos 4. Especificação de requisitos
  39. 39. Obtendo os requisitos  Técnicas para levantamento de requisitos:  Descoberta de Requisitos(Pontos de vista)  Entrevistas  Cenários  Casos de Uso  Etnografia
  40. 40. Obtendo os requisitos  Técnicas para levantamento de requisitos:  Descoberta de Requisitos(Pontos de vista)  Entrevistas  Cenários  Casos de Uso  Etnografia
  41. 41. Descoberta de Requisitos  Processo que reúne informações sobre o sistema proposto e os existentes para obter os requisitos de usuário e de sistema.  Em uma empresa de tamanho médio ou grande, existem vários stakeholders;  Cada stakeholder tem um ponto de vista diferente  Cada um vê o problema de modo diferente;  Objetivo: conhecer o problema por várias perspectivas.
  42. 42. Descoberta de Requisitos  Stakeholders frequentemente:  Não sabem na realidade o que querem;  Não conseguem expressar claramente o que desejam;  Fazem pedidos não realistas;  Se expressam com seus próprios termos (técnicos).  Diferentes stakeholders expressam o mesmo requisito de forma diferente.
  43. 43. Obtendo os requisitos  Técnicas para levantamento de requisitos:  Descoberta de Requisitos(Pontos de vista)  Entrevistas  Cenários  Casos de Uso  Etnografia
  44. 44. Entrevistas  Questionar os stakeholders sobre o sistema (ou processo) atual e sobre o sistema que será desenvolvido;  Tipos de entrevistas:  Entrevistas fechadas: conjunto pré-definido de perguntas;  Entrevistas abertas: sem agenda pré-definida; se adapta para explorar o conhecimento do stakeholder.
  45. 45. Obtendo os requisitos  Técnicas para levantamento de requisitos:  Descoberta de Requisitos(Pontos de vista)  Entrevistas  Cenários  Casos de Uso  Etnografia
  46. 46. Cenários  Descreve uma situação de uso do sistema;  Inclui informações como:  Nome do Cenário;  Ator;  Pré-condição;  Fluxo normal;  Fluxos alternativos;  Pós-condição.
  47. 47. Exemplo de Cenário  Nome do Cenário: Sacar dinheiro  Ator: Correntista  Pré-condição: Conta e senha validada  Fluxo normal:  Entrar com valor do saque  Confirmar dados e operação  Debitar valor da conta do cliente  Fluxos alternativo: Saldo insuficiente  Apresentar aviso ao cliente  Pós-condição:  Valor sacado é debitado do saldo do cliente
  48. 48. Obtendo os requisitos  Técnicas para levantamento de requisitos:  Descoberta de Requisitos(Pontos de vista)  Entrevistas  Cenários  Casos de uso  Etnografia
  49. 49. Casos de Uso  Introduzida inicialmente no método Objectory (JACOBSON et al., 1993).  Em sua forma mais simples, identificam:  Os atores envolvidos;  As funcionalidades principais;  A interação entre atores e funcionalidades do sistema.
  50. 50. Casos de Uso Retirar Dinheiro Transferir Fundos Depositar Fundos Inicializar o Sistema Cliente Operador de Caixa Eletrônico Sistema Bancário  Descrição textual;
  51. 51. Obtendo os requisitos  Técnicas para levantamento de requisitos:  Descoberta de Requisitos(Pontos de vista)  Entrevistas  Cenários  Casos de uso  Etnografia
  52. 52. Etnografia  É uma técnica de observação utilizada para compreender os processos operacionais;  O analista (engenheiro de requisitos) se insere na organização do cliente:  Observa o trabalho no dia a dia;  Anota as tarefas dos funcionários.
  53. 53. Etnografia  É eficaz para descobrir:  maneira como as pessoas realmente trabalham;  da cooperação e conscientização das atividades de outras pessoas;  Desenvolver um protótipo;  Revelar detalhes importantes que são ignorados por outras técnicas.
  54. 54. Validação de Requisitos  Custos de erros de requisitos são altos, desse modo, a validação é muito importante.  Validar é:  Demonstrar se os requisitos definem o sistema que o cliente realmente quer.
  55. 55. Validação de Requisitos  Os diferentes tipos de validação que devem ser efetuados:  Validade  O sistema fornece as funções que melhor atendem às necessidades do cliente?  Consistência  Existe algum conflito de requisitos?  Completude  Estão incluídas todas as funções e restrições requeridas pelo cliente ?
  56. 56. Validação de Requisitos  Os diferentes tipos de validação que devem ser efetuados:  Realismo  Os requisitos podem ser implementados com o orçamento e a tecnologia disponíveis?  Verificabilidade  Os requisitos podem ser verificados? Pode ser escrito um conjunto de testes que demonstrem que o sistema atende a cada requisitos especificado.
  57. 57. Validação de Requisitos  Técnicas de Validação de Requisitos:  Revisões de requisitos  Análise manual sistemática dos requisitos.  Prototipação  Usando um modelo executável do sistema para verificar os requisitos.  Geração de casos de teste  Desenvolvimento de testes para verificar os requisitos implementados.
  58. 58. Gerenciamento de Requisitos  Usuários muitas vezes mudam os requisitos ou “não sabem o que querem”...  Requisitos são, inevitavelmente, incompletos e inconsistentes:  Novos requisitos surgem durante o processo, à medida que as necessidades de negócio mudam e uma melhor compreensão do sistema é desenvolvida;  Os diferentes pontos de vista têm requisitos diferentes e estes são frequentemente contraditórios.
  59. 59. Gerenciamento de Requisitos  É o processo de gerenciamento de mudanças de requisitos durante o processo de engenharia de requisitos e o desenvolvimento de sistema.  É necessário:  Compreender e controlar as mudanças dos requisitos;  Avaliar os impactos das mudanças;
  60. 60. Gerenciamento de Requisitos  Fatores para a mudança de requisitos  Erros e inconsistência de requisitos  Evolução do conhecimento sobre o sistema  Problemas técnicos, de custo e prazo  Mudança de prioridades  Mudanças organizacionais
  61. 61. Planejamento de gerenciamento de requisitos  Durante o processo de gerenciamento de requsitos, você tem de planejar:  A Identificação de requisitos  Como os requisitos são identificados individualmente;  O processo de gerenciamento de mudanças  Avalia o impacto e o custo das mudanças;  Políticas de rastreabilidade  É a quantidade de informações sobre os relacionamentos de requisitos;  Ferramenta de apoio  O apoio de ferramenta requisitada para auxiliar no gerenciamento das mudanças requisitos.
  62. 62. Planejamento de gerenciamento de requisitos  Ferramentas:  Caliber RM – comercial – Borland;  QSS requirit – comercial – Quality System & Software;  IBM – Rational RequisitePro – comercial – IBM Rational;  OSRMT – open source;  aNimble – open source.
  63. 63. Principais Eventos  Requirements Engineering Conference 2015  23ª edição  Ottawa – Canadá, de 24 a 28 de Agosto  Qualis A1  Tema:  Requirements for the masses. Requirements from the masses.  Working Conference on Requirements Engineering: Foundation for Software Quality 2015  21ª edição  Essen – Alemanha, de 23 a 26 de Março.  Qualis b3  Workshop em Engenharia de Requisitos - WER 2015  Qualis B3  18ª edição  Lima - Peru, de 22 a 24 de Abril.
  64. 64. Principais Eventos  Principais Tópicos de Interesse:  Elicitação de requisitos, análise, documentação, validação e verificação;  O gerenciamento de requisitos, pontos de vista, priorização e negociação;  Modelagem de requisitos, objetivos e domínios;  Relacionando requisitos para objetivos de negócios, arquitetura e testes;  Requisitos em desenvolvimento ágil, linha de produtos e modelo-dirigido a desenvolvimento;
  65. 65. Principais Eventos  Principais Tópicos de Interesse:  Requisitos em serviços orientados, virtualização, embarcados, em nuvem e ambientes móveis;  Requisitos relacionados com a segurança, confiabilidade, segurança, privacidade e forense digital;  Estudos empíricos, medições e previsão;  Específicas de domínio problemas, experiências e soluções, incluindo domínios novos e emergentes;  Ferramenta de suporte para engenharia de requisitos;  Evolução dos requisitos ao longo do tempo, as famílias de produtos, a variabilidade e reutilização.
  66. 66. Conclusão  A engenharia de requisitos define, sem dúvida, um dos mais importantes conjuntos de atividades a serem realizadas em projetos de desenvolvimento de software.  Embora não garanta a qualidade dos produtos gerados, é um pré-requisitos básico para que obtenhamos sucesso no desenvolvimento do projeto.
  67. 67. Bibliografia  DORFMAN, M., THAYER, R. H., 1990. Standards, Guidelines and Examples of System and Software Requirements Engineering. Los Alamitos, CA, IEEE Computer Society Press.  Norma 830-1998 - IEEE Recommended Practice for Software Requirements Specifications.  PRESSMAN. “Engenharia de Software” 6ª Edição.  SOMMERVILLE, I. Engenharia de software. 8ª edição São Paulo: Pearson Addison- Wesley, 2007.  SOMMERVILLE, I. Engenharia de Software, 9ª Edição. Pearson Education, 2011.
  68. 68. Dúvidas

×