O processo de Engenharia de Requisitos 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 A Gerência do Processo de Desenvolvimento 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 Ciclo de Vida Cascata Evolucionário Formal Orientado a Reuso Espiral Incremental 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 Cascata Engenharia de Sistemas Análise Projeto Codificação Teste Manutenção 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 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 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 Evolucionário Especificação Descrição do Esboço Desenvolvimento Validação Versão Inicial Versões do Descrição Intermediárias Esboço Versão Final 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 Início Evolucionário Definição de Requisitos e Refinamento Fim Produto Final Projeto Rápido Refinamento do protótipo Construção do Protótipo Avaliação do Usuário 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 Especificação de Requisitos Especificação Formal Transformação Formal Testes 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 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 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 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 Modelo Espiral 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 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, obtendose resultados de médio e curto prazo sem se descuidar do objetivo final Uma interação Enfoque Incremental Requisitos Requisitos Design Design Codificação Codificação Testes Testes Implantação tempo Implantação Desenvolvimento Incremental O Processo de Desenvolvimento RUP está em conformidade com o Desenvolvimento Incremental. 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 Desenvolvimento Iterativo e Incremental (RUP) Engenharia de Requisitos 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: 1. Descobrir 3. Documentar 2. Analisar 4. Verificar É chamado de Engenharia de Requisitos Engenharia de Requisitos 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 Atividades de Engenharia de Requisitos – Recursos Humanos Organização e Responsabilidade - Papéis Analista de Negócios Negocia junto com os clientes e os demais envolvidos a lista dos requisitos iniciais e suas ampliações, priorizando-os e quando necessário agrupando-os em pacotes a serem desenvolvidos em iterações. É responsável por explicitar as regras de negócio e o glossário associado ao negócio. Analista de Requisitos Elicita os requisitos de produto e registrá-os de forma adequada. Garante a rastreabilidade dos requisitos de negócio e requisitos de produto ao longo do projeto. Cliente Aprova a versão final do escopo da aplicação, descrito na Especificação de Requisitos de software Inspetor Inspeciona a Especificação de Requisitos de Software com relação ao formato. Testador Aplica o Plano de Testes e assegura que os requisitos implementados estão de acordo com o requisitado pelo cliente. Elicitação dos Requisitos de Negócio Necessidades 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 Regras de Negócio Glossário Analista de Negócios Documento de Visão 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 Casos de Uso e Esp. Suplementar Plano e Casos de Teste Analista de Requisitos Requisitos p/ Inspeção 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 Rastreabilidade e Gestão de Mudanças Necessidade Solic. Mudança Avaliar o impacto nos requisitos Validar com o cliente Notificar os envolvidos Atualizar as especificações de requisitos Garantir a rastreabilidade nos requisitos Especificação de Requisitos Atualizada Documento de Visão Atualizado Analista de Negócios Analista de Requisitos Elicitação de Requisitos Elicitação dos Requisitos de Negócio Necessidades 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 Regras de Negócio Glossário Analista de Negócios Documento de Visão 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 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, ... 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) 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 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 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) 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. 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 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 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 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 Verificação de Requisitos Os requisitos são verificados – Completos? – Consistentes? – Em concordância com o que os stakeholders desejam?
Download
