análise de requisitos introdução renata araujo ricardo storino núcleo de computação...
TRANSCRIPT
Análise de Requisitos
Introdução
Renata AraujoRicardo Storino
Núcleo de Computação EletrônicaCurso de Programação de Computadores
Maio a Setembro/2000
2
Evolução da Indústria de Software
Mudanças Rápidas
Sistemas mais complexos
Novas áreas de aplicação
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
Fatores de Sucesso
Envolvimento do usuário no projeto
Suporte da alta direção
Definição clara dos requisitos
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
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
Reunião
Método pelo qual se chega a descoberta dos requisitos.
Porque falham? Muitas reuniões - resolver qualquer questãoO 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
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
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
Reunião
Exemplo
Pré ReuniãoREUNIÃO
AssuntoAssunto: Curso de Análise de Sistemas
DataData : 29/05/2000 10:00 h
ParticipantesParticipantes: Renata, Storino, Jonas e Alexandre
CoordenaçãoCoordenação:: Storino Tempo de DuraçãoTempo de Duração: 1 hora
ObjetivoObjetivo: Definir ementa do curso e distribuição das aulas entre os dois professores
AnexoAnexo: Sugestão de ementa
ObsObs: É desejada uma distribuição de carga horaria igual entre os professores
11
Reunião
Pós ReuniãoREUNIÃO
AssuntoAssunto - Curso de Análise de Sistemas
DataData : 29/05/2000 InícioInício:10:10 h
ParticipantesParticipantes: Renata, Storino, Jonas e Fernanda
CoordenaçãoCoordenação: Storino Tempo de DuraçãoTempo de Duração: 1 hora e 15 min
ObjetivoObjetivo: Definir ementa do curso e distribuição das aulas entre os dois professoresAta- Foi definido que Renata preparará os testes do curso- Jonas acompanhará e avaliará os dois professores
AnexoAnexo: Ementa do curso de análise com distribuição.
ObsObs: Alexandre faltou. Foi encaminhado a ele uma copia deste documento
12
Importância de Requisitos
Ciclo de desenvolvimento de um sistema 00Ciclo 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
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 aFatos incorretos 49%Omissões 31%AmbiguidadesInconsistenciasPosicionamento Incorreto 20%
Inspeções - Ajudam a validar
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
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
Especificação de Requisitos
Requisitos funcionais (use - cases)
Requisitos não funcionaisEficienciaConfiabilidadeSegurançaPortabilidadeCapacidade Etc
17
Especificação de Requisitos CorretaCorreta
Não ambíguaNão ambígua
CompletaCompleta
VerificávelVerificável
Possível de ser entendida pelo clientePossível de ser entendida pelo cliente
ModificávelModificável
TracedTraced
AnnotatedAnnotated
18
Especificação de Requisitos
CorretaCorreta - todo requisito presente na especificação representa algo necessário
Não ambíguaNã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
Especificação de Requisitos
Completa -Completa - tudo o que o sistema deve fazer está incluido na especificaçãoTodas 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
Modificável - Modificável - mudanças devem poder ser efetuadas de modo fácil e consistenteControle de versõesIndices e referências cruzadas
TracedTraced(seguir a pista, investigar)(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
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
Requisitos não funcionais
PortabilidadePortabilidade - mudança de ambiente
ConfiabilidadeConfiabilidade - resposta corretas
EficiênciaEficiência - performace, capacidade
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
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
Prototipagem
Descartável
Rápido e sujo
Sem rigor
Construir partes não muito bem entendidas ou difíceis
Jogar fora depois
26
Prototipagem
Evolucionária
Rigorosa e com método
Partes entendidas são construídas primeiro
Evolui (Não é jogado fora)