O processo de Engenharia de Requisitos

1. Plano Aprovado O processo de Engenharia de Requisitos

2. 2. Obtenção e Análise dos Requisitos • Avaliar os problemas na situação atual • Principal foco para o novo sistema: O QUE e não COMO: • qual o fluxo e o conteúdo de informação • quais as funções do sistema • quais dados o sistema produz e consome • qual o comportamento do sistema • quais as características de interface com outros subsistemas • quais são as restrições do projeto

3. A Gerência do Processo de Desenvolvimento

4. Ciclo de Vida • Qual o propósito de estabelecer um Ciclo de Vida para o Software? • Definir que atividades devem ser executadas em um projeto de desenvolvimento de sistemas • Introduzir consistência entre vários projetos de desenvolvimento de sistemas de uma mesma organização • Prover pontos de controle para prever, gerenciar e controlar o desenvolvimento de sistemas

5. Ciclo de Vida • Cascata • Evolucionário • Formal • Orientado a Reuso • Espiral • Incremental

6. Cascata • Ciclo de Vida Clássico • Prevê um processo de desenvolvimento com etapas seqüenciais • Base: engenharia convencional • O resultado de cada fase envolve a elaboração de um ou mais documentos que são aprovados

7. Cascata Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção

8. Cascata • Problemas: • Para grandes projetos o tempo que decorre desde a especificação até sua implantação é grande • O Ambiente Externo evolui e é diferente daquele que deu origem a sua especificação • Na prática os estágios se sobrepõem • O processo de software envolve interações

9. Evolucionário • Base • Desenvolver uma implementação inicial • Expor o resultado ao comentário do usuário • Aprimoramento por meio de muitas versões • Até que o sistema tenha sido totalmente desenvolvido • Dois tipos: • Exploratório • Protótipos descartáveis

10. Evolucionário • Exploratório • Trabalhar com o cliente • O desenvolvimento inicia com as partes do sistema que são compreendidas • O sistema evolui com as novas características propostas pelo cliente • Protótipos descartáveis • O protótipo experimenta os requisitos não compreendidos • Neste caso o objetivo é a Especificação de Requisitos • Falaremos de protótipos mais adiante

11. Evolucionário Especificação Versão Inicial Desenvolvimento Versões Intermediárias Descrição do Esboço Descrição do Esboço Validação Versão Final

12. Evolucionário • Produz sistemas que atendem as necessidades imediatas do cliente • Problemas • O processo não é visível • Não se produzem documentos que reflitam as versões do sistema • Freqüentemente são mal estruturados • Software sem estrutura • Modificações cada vez mais custosas • Ferramentas e técnicas especiais • Possibilitam rápido desenvolvimento • Poucas pessoas podem ter a habilitação necessária para usá-las

13. Definição de Requisitos e Refinamento Produto Final Projeto Rápido Refinamento do protótipo Constru- ção do Protótipo Avaliação do Usuário Início Evolucionário Fim

14. Especificação de Requisitos Especificação Formal Transformação Formal Testes Formal • Base: a transformação matemática formal de uma especificação de sistema em um programa executável • A especificação de requisitos é redefinida com uma linguagem formal

15. Formal • Transformação formal • Várias etapas • Representação mais detalhada, matematicamente correta • Adequada a sistemas críticos • Permite verificação automática de consistência • Model checking • utiliza máquinas de estado para verificar onde uma determinada propriedade é satisfeita sob todas as condições • Prova de teoremas • axiomas do comportamento do sistema são empregados para derivar uma prova de que o sistema vai se comportar de uma determinada forma

16. Orientado a Reuso • Ampla base de componentes reusáveis • Infra-estrutura de integração • Etapas: • De posse da Especificação de Requisitos, buscam-se componentes para implementá-la • Negociação – requisitos são modificados para que se possa usar os componentes • Redução do esforço de desenvolvimento

17. Iteração de processo • Existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema • Partes do processo são repetidas enquanto os requisitos evoluem • Modelos Híbridos • Apóiam a iteração do processo • Desenvolvimento Espiral • Desenvolvimento Incremental

18. Modelo Espiral • O processo de desenvolvimento se move sobre uma espiral evolucionária • Melhores características do • Ciclo de vida clássico • Evolucionário – Prototipação • Acrescenta Análise de Riscos • As fases são executadas de forma iterativa • As fases de análise e projeto não são monolíticas e distintas

19. Modelo Espiral

20. Modelo Espiral • Planejamento • objetivos, alternativas e restrições • Análise de Riscos • Análise de alternativas e identificação/resolução de riscos • Prototipação pode ser usada • Simulações e outros modelos podem ser usados para definir melhor o problema • Desenvolvimento e Validação • Desenvolvimento do produto no “nível seguinte” • Avaliação feita pelo Cliente • Volta ao Planejamento

21. Enfoque Incremental • Uma variação do modelo cascata onde a partir da fase de especificação de requisitos são feitos incrementos sucessivos. • Estratégia para minimizar riscos, obtendo-se resultados de médio e curto prazo sem se descuidar do objetivo final

22. Requisitos Requisitos Design Design Codificação Codificação Testes Testes Implantação Implantação Uma interação Enfoque Incremental tempo

23. Desenvolvimento Incremental • O Processo de Desenvolvimento RUP está em conformidade com o Desenvolvimento Incremental.

24. Desenvolvimento Incremental • Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em partes, com cada incremento entregando parte da funcionalidade requerida • Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais • Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados“, embora possam continuar a evoluir para incrementos posteriores

25. Desenvolvimento Iterativo e Incremental (RUP)

26. Engenharia de Requisitos

27. Engenharia de Requisitos • Compreender a natureza do software a ser desenvolvido é realmente muito complexo • Conseqüentemente é difícil estabelecer o que o sistema deve fazer • Estabelecer o que o sistema deve fazer descrevendo suas funções e restrições é conseguir determinar todos os seus requisitos • O Processo de: É chamado de Engenharia de Requisitos

28. Engenharia de Requisitos

29. Engenharia de Requisitos • O processo de estabelecer as funções que um cliente requer de um sistema e as restrições sob as quais ele deve funcionar e ser desenvolvido • Os requisitos são descrições das funções e restrições que são geradas durante o processo de engenharia de requisitos

30. Atividades de Engenharia de Requisitos – Recursos Humanos

31. Organização e Responsabilidade - Papéis

32. Elicitação dos Requisitos de Negócio • Explicitar o domínio do problema • Identificar possibilidade de reuso de solução • Identificar pessoas e áreas impactadas • Elicitar e classificar os requisitos de negócio • Envolver a área de serviços e definir alternativas de solução • Analisar e validar os requisitos Necessidades Analista de Negócios Regras de Negócio Glossário Documento de Visão

33. Especificação e Modelagem de Requisitos Regras de Negócio Glossário Documento de Visão • Elicitar Requisitos de Produto • Especificar casos de uso e validá-los • Especificar requisitos não funcionais • Analisar e validar os requisitos Analista de Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção

34. Verificação e Validação dos Requisitos Casos de Uso e Esp. Suplementar Plano e Casos de Teste Requisitos p/ Inspeção • 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

35. Rastreabilidade e Gestão de Mudanças Necessidade • Avaliar o impacto nos requisitos • Validar com o cliente • Notificar os envolvidos • Atualizar as especificações de requisitos • Garantir a rastreabilidade nos requisitos Analista de Negócios Solic. Mudança Analista de Requisitos Especificação de Requisitos Atualizada Documento de Visão Atualizado

36. Elicitação de Requisitos

37. Elicitação dos Requisitos de Negócio • Explicitar o domínio do problema • Identificar possibilidade de reuso de solução • Identificar pessoas e áreas impactadas • Elicitar e classificar os requisitos de negócio • Envolver a área de serviços e definir alternativas de solução • Analisar e validar os requisitos Necessidades Analista de Negócios Regras de Negócio Glossário Documento de Visão

38. Elicitação de Requisitos • Atividades que envolvem a descoberta de requisitos de um sistema: • identificação das fontes de informação • técnicas de elicitação (coleta de fatos) • comunicação (estabelecer uma linguagem comum) • Envolve pessoal objetivando descobrir: • o domínio de aplicação • serviços que devem ser fornecidos • restrições

39. Elicitação de Requisitos • Pode envolver diferentes tipos de pessoas em uma organização (stakeholders): • usuários • gerentes • desenvolvedores • especialistas de domínio • sindicatos,... • A equipe de desenvolvimento e clientes trabalham em conjunto visando identificar: • detalhes do domínio da aplicação • serviços que o sistema deve oferecer • desempenho • restrições de hardware, ...

40. Elicitação de Requisitos • Problemas: • Em geral, stakeholders não sabem o que querem de fato • dificuldade de expressão • pedidos não realistas • Stakeholders expressam requisitos em sua própria terminologia • conhecimento implícito • Stakeholders distintos podem ter requisitos conflitantes • Fatores políticos podem influenciar os requisitos do sistema • Ambientes econômicos e de negócios são dinâmicos • requisitos mudam durante o processo de análise • novos requisitos podem surgir (novos stakeholders)

41. Elicitação de Requisitos • Atividades do Processo: • Compreensão do domínio • Coleta de requisitos • Classificação • Resolução de conflitos • Definição de Prioridades • Verificação de requisitos

42. Compreensão do Domínio • Os analistas devem desenvolver sua compreensão do domínio da aplicação • se estiver desenvolvendo um sistema de supermercado deverá descobrir como este funciona • utilizar técnicas para descobrir este funcionamento • aprender a linguagem do usuário • elaborar um Glossário

43. Coleta de Requisitos • Interagir com stakeholders para descobrir os requisitos • A coleta de requisitos é feita através de técnicas • Os requisitos são simplesmente documentados à medida que são coletados • resulta em documento preliminar (draft)

44. Classificação dos Requisitos • Consiste basicamente em agrupar os diversos requisitos coletados em categorias bem-definidas • Classificação: • Funcional Ex.: Deve ser possível consultar o preço de uma mercadoria • Não Funcional Ex.: A consulta deve retornar uma resposta em no máximo 5s • Inversos Ex.: O sistema não fará controle de estoque.

45. Resolução de Conflitos • É normal que ocorram requisitos conflitantes • Por exemplo • R-23: O sistema deve ... • R-45: O sistema não deve ... • Cliente é o responsável por resolver conflitos e ambigüidades

46. Atribuição de Prioridade • Alguns requisitos são mais urgentes que outros • É essencial determinar a prioridade dos requisitos junto ao cliente • Requisitos de maior prioridade são considerados em primeiro lugar

47. Prioridade • Requisitos podem ser agrupados em classes, por exemplo: • Essenciais • Importantes • Desejáveis • Em princípio, o sistema deve abranger todos os requisitos de essenciais para desejáveis

48. Exemplo de Prioridade • A consulta ao extrato bancário deve retornar dados do movimento até o dia anterior • Prioridade: Essencial • A consulta ao extrato bancário deve visualizar dados segundo padrão X • Prioridade: Importante • A consulta ao extrato bancário deve usar cores vermelhas para saldos negativos • Prioridade: Desejável

49. Verificação de Requisitos • Os requisitos são verificados • Completos? • Consistentes? • Em concordância com o que os stakeholders desejam?