Análise de Requisitos Introdução Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores Maio a Setembro/2000.

Apresentação em tema: "Análise de Requisitos Introdução Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores Maio a Setembro/2000."— Transcrição da apresentação:

1 Análise de Requisitos Introdução Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores Maio a Setembro/2000

2 2 Evolução da Indústria de Software Mudanças Rápidas Sistemas mais complexos Novas áreas de aplicação

3 3 Estatística 50 % Entregues mas nunca utilizados com sucesso 30 % Não entregues 25 % Utilizado com grande retrabalho sendo depois abandonado 03 % Utilizado após algumas modificações 02 % Utilizado conforme entregue

4 4 Fatores de Sucesso Envolvimento do usuário no projeto Suporte da alta direção Definição clara dos requisitos

5 5 Requisito Algo que se deseja ou precisa Uma característica que o usuário necessita para resolver um problema ou atingir um objetivo Uma característica que o sistema deve possuir ou atingir para satisfazer um contrato padrão ou outro documento formal

6 6 Requisito Sua especificação é feita através de um documento contendo uma descrição completa do que o sistema deverá fazer sem conter informações de como será feito. Análise do negócio O QUE X COMO

7 7 Reunião Método pelo qual se chega a descoberta dos requisitos. Porque falham? Muitas reuniões - resolver qualquer questão O que é que estou fazendo aqui ? Reuniões que consomem muito tempo - sem tempo pré determinado - sem coordenação Reuniões ineficientes e improdutivas - falta de preparação - muitos donos da verdade - poucos advogados do diabo

8 8 Reunião Pré Reunião Essencial para o sucesso da reunião normalmente esquecida ou não enfatizada Agenda - assunto - participantes - tempo - papéis (definir coordenador) - problemas e resultados esperados - objetivo Preparação e distribuição de material para Reunião

9 9 Reunião Pós Reunião Aumenta confiabilidade nas reuniões Descrição das decisões e planos Feed Back para os participantes Responsabilidades

10 10 Reunião Exemplo Pré Reunião REUNIÃO Assunto Assunto: Curso de Análise de Sistemas Data Data : 29/05/2000 10:00 h Participantes Participantes: Renata, Storino, Jonas e Alexandre Coordenação:Tempo de Duração Coordenação: Storino Tempo de Duração: 1 hora Objetivo Objetivo: Definir ementa do curso e distribuição das aulas entre os dois professores Anexo Anexo: Sugestão de ementa Obs Obs: É desejada uma distribuição de carga horaria igual entre os professores

11 11 Reunião Pós Reunião REUNIÃO Assunto Assunto - Curso de Análise de Sistemas DataInício Data : 29/05/2000 Início:10:10 h Participantes Participantes: Renata, Storino, Jonas e Fernanda CoordenaçãoTempo de Duração Coordenação: Storino Tempo de Duração: 1 hora e 15 min Objetivo Objetivo: Definir ementa do curso e distribuição das aulas entre os dois professores Ata - Foi definido que Renata preparará os testes do curso - Jonas acompanhará e avaliará os dois professores Anexo Anexo: Ementa do curso de análise com distribuição. Obs Obs: Alexandre faltou. Foi encaminhado a ele uma copia deste documento

12 12 Importância de Requisitos Ciclo de desenvolvimento de um sistema 00 Custo de Erro Requisito 1 Análise 5 Projeto 10 Código 20 Teste 50 Manutenção 200 Quanto mais tarde no processo de desevolvimento um erro for detectado, maior será o custo para consertá-lo

13 13 Importância de Requisitos Muitos erros permanecem latentes e somente são detectados muito após o ponto onde foram cometidos É muito difícil descobrir erros na fase requisitos São geralmente causados devido a Fatos incorretos 49% Omissões 31% Ambiguidades Inconsistencias Posicionamento Incorreto 20% Inspeções - Ajudam a validar

14 14 Importância de Requisitos Muitos erros de requisitos são cometidos e não são detectados cedo Não detectando o custo cresce exponencialmente com o tempo Validação dos requisitos através de inspeções

15 15 Especificação de Requisitos Meio de comunicação entre clientes, usuarios, analistas e projetistas. Deve ser específica e precisa Contem: Quais requisitos são novos, quando foram requisitados, quem os requisitou Descrição concisa e completa de todo comportamento externamente visível do sistema definindo as suas interfaces com usuários, equipamentos, outros sistemas.

16 16 Especificação de Requisitos Requisitos funcionais (use - cases) Requisitos não funcionais Eficiencia Confiabilidade Segurança Portabilidade Capacidade Etc

17 17 Especificação de Requisitos Correta Correta Não ambígua Não ambígua Completa Completa Verificável Verificável Possível de ser entendida pelo cliente Possível de ser entendida pelo cliente Modificável Modificável Traced Traced Annotated Annotated

18 18 Especificação de Requisitos Correta Correta - todo requisito presente na especificação representa algo necessário Não ambígua Não ambígua - todo requisito da especificação possui apenas uma interpretação Ex: Aviões inimigos e que tenham uma missão não conhecida ou com potencial para entrar no espaço aéreo restrito dentro de 5 min, devem disparar um alerta

19 19 Especificação de Requisitos Completa - Completa - tudo o que o sistema deve fazer está incluido na especificação Todas as respostas possíveis do sistema estão especificadas Verificável - Verificável - para todo requisito especificado, existe um processo finito e de custo exequível que permite verificar se o produto construido o atende Entendida pelo cliente - Entendida pelo cliente - notações muito formais podem tornar a especificação impossível de ser entendida pelo cliente. Notação informal tem um potencial para ambiguidade.

20 20 Modificável - Modificável - mudanças devem poder ser efetuadas de modo fácil e consistente Controle de versões Indices e referências cruzadas Traced (seguir a pista, investigar) - Traced (seguir a pista, investigar) - definição da origem de cada requisito como surgiu, quem definiu Annotated - Annotated - Atributos dos requisitos Responsáveis Data criação / Modificação Versão Prioridade Status Etc Especificação de Requisitos

21 21 Conclusão Atingir, na prática todos os objetivos citados é praticamente impossível Inconsistência e Ambiguidade X Facilidade de Entendimento Especificação completa X Tamanho e facilidade para leitura Facilidade de modificação X Facilidade de entendimento

22 22 Requisitos não funcionais Portabilidade Portabilidade - mudança de ambiente Confiabilidade Confiabilidade - resposta corretas Eficiência Eficiência - performace, capacidade

23 23 Prototipagem Técnica de constução de uma implementação parcial do sistema de modo que o cliente, usuário e/ou desenvolvedores possam aprender um pouco mais sobre o problema ou sobre sua solução DESCARTÁVEL ou EVOLUCIONÁRIA

24 24 Prototipagem Descartável Determinar a viabilidade do requisito Verificar se uma determinada característica é realmente necessária Descobrir novos requisitos Determinar a viabilidade de uma interface com o usuário Com a experiência obtida com o protótipo, a especificação é construída FeedBack com o usuário

25 25 Prototipagem Descartável Rápido e sujo Sem rigor Construir partes não muito bem entendidas ou difíceis Jogar fora depois

26 26 Prototipagem Evolucionária Rigorosa e com método Partes entendidas são construídas primeiro Evolui (Não é jogado fora)