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)