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. 2. Obtenção e Análise dos Requisitos – cont. • Sintetizar uma ou mais soluções • conforme delineado em um Plano de Projeto de Software • o processo de avaliação e síntese continua até que o analista e o cliente concordem que o sistema esteja adequadamente especificado • é a maior área de esforço

4. Modelagem • Durante a atividade de avaliação e síntese devem ser criados • modelos do sistema para se compreender melhor o fluxo de dados e de controle: • padrão de comportamento • padrão da informação • esses modelos devem garantir o atendimento aos requisitos • O modelo serve como fundamento para o projeto do sistema e como base para a criação de sua especificação

5. 3. Especificação dos Requisitos • Refinamento detalhado de todos os requisitos  Requisitos de Produto • Funções descritas em detalhe • Estabelecimento das características de interface • Com outros subsistemas • Ambiente de implementação • Interface Humano-Computador • Segurança, etc • Identificação das restrições de projeto • Especificação dos critérios de validação

6. 4. Validação • Verifica os requisitos • Critérios: pertinência, consistência, completude • As revisões são conduzidas pelo Cliente e pelo Desenvolvedor • A base para a revisão são os documentos produzidos na Especificação dos Requisitos • O Plano de Projeto do Software deve ser revisto devido ao conhecimento adquirido durante a análise

7. A Gerência do Processo de Desenvolvimento

8. 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

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

10. 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

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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. Modelo Espiral

24. 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

25. 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

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

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

28. 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

29. Desenvolvimento Iterativo e Incremental (RUP)

30. Engenharia de Requisitos

31. 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

32. Engenharia de Requisitos

33. 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

34. Atividades de Engenharia de Requisitos – Recursos Humanos

35. Analista de Negócio Analista de Requisitos Testador Inspetor Cliente Elicitação dos Especificação e Verificação e Requisitos Modelagem dos Validação dos - Requisitos Requisitos Rastreabilidade e Gestão de Mudanças Atividades de Engenharia de Requisitos

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

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. 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

39. 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

40. 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

41. Resumo da nomenclatura e templates

42. Elicitação de Requisitos

43. 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

44. 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

45. 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, ...

46. 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)

47. 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

48. 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

49. 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)

50. 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.