Treinamento de Análise de Requisitos

DB1 InformáticaSoftware e Consultoria

ANÁLISE DE REQUISITOS

19/03/2012

Jasper W. Perrú

2DB1 Informática: Software e Consultoria

Instrutor

• Jasper Willian Perrú – EGP DB1• Analista de Sistemas e Negócios e

Coordenador de Projetos• Atua na DB1 desde 2006


Conteúdo

• O que é o Documento de Requisitos e sua importância;• Como pensar e organizar um requisito;• Quais os passos para descrever um requisito;• Como preencher cada tópico do documento de requisito;• Boas práticas para Análise do Requisitos;


E se…

Construíssemos Prédios?


Correríamos este risco?


Ou…

Produzíssemos Aviões?


Imagine se fosse você o responsável por isto…


Agora, pergunto:

Qual a diferença sobre oque

fazemos hoje?


Você sabia que...

A Análise dos Requisitos é responsável pela identificação dos objetivos do cliente. Oslevantamentos dos requisitos mal formulados, mal definidos ou incompletos, levarão para a

fase do projeto e no desenvolvimento do software. Conseqüentemente o projeto ficarácomprometido na medida em que os requisitos não forem consistentes e seguros.

Segundo a SPCI(Software Productivity Consortium Incl) os custos relativos para a eliminação dos mesmos problemas nas etapas do desenvolvimento do projeto de software elevarão os custos

4X maior para eliminação do erro na fase de testes e na fase de manutenção do software será

100X maior

Custo de Re-trabalho;Quebra de planejamento de Sprints;Impacto sobre prazo de entrega;

Impacto da imagem do Produto DB1;Impacto sobre a imagem dos

profissionais DB1;


Erros de análise levam a construírmos vários caminhos que …

1) Podem levar ao mesmo lugar…2) Podem nos confundir e dificultar o

trajeto…3) Podem ocorrer acidentes…4) Podem nos fazer desistir …


Um erro de requisito em um cálculo de margem de venda por exemplo pode

levar uma empresa a quebrar…

Um erro no cálculo de impostos pode acarretar em multas gigantes para

empresas…

Uma brecha no sistema financeiro porfalta de análise pode deixar o sistema

vulnerável a fraudes…


Pela definição de Dean, 1994: “é qualquer coisa que restringe o sistema”. Segundo SPCI (Software Productivity Consortium Incl): “os requisitos definem o problema. Eles lhe dizem o que o software deverá fazer. Os demais passos do processo tradicional de desenvolvimento de software criam solução”. Segundo Breitman, 1998: “A análise de requisitos de software é a disciplina usada para capturar correta e complementando os requisitos de software e expectativas dos usuários de software e as técnicas e disciplinas da análise de requisitos de software tem como objetivo a elicitação de requisitos do macrosistemas.” É a identificação das necessidades dos usuários de informações e comunicação dessas necessidades aos processos de construção de software.

O que é um Documento de Requisitos?


• Elicitação (Levantamento) – identificar quais são os requisitos desejados do produto de software.

• Análise – organizar e fazer considerações técnicas acerca dos requisitos levantados.

• Especificação – formalização dos requisitos de acordo com o documento padrão da empresa.

• Validação (Negociação) – apresentação aos usuários os requisitos especificados para validação e possíveis correções.

• Gerenciamento – controlar as alterações nos requisitos e promover a rastreabilidade.

Fases da Análise de Requisitos

Elicitação Análise Especificação Validação

Gerenciamento


Com intuito de padronizarmos a documentação de tudo que a empresa produz, foi criado um novo modelo para o documento de especificação de requisitos, este

modelo além de nos direcionar à forma de escrever, contribui com a estruturação lógica da necessidade a ser documentada. Trata-se de algo objetivo, que

possibilita a contextualização da estória de forma mais clara, sendo assim, para todas as partes o sentido real da produção passa a ser conhecido.

Pontos positivos da boa utilização do modelo:

• Único padrão para toda empresa, todos os setores e células de produção conhecem o mesmo modelo;

• Forma de escrever é mais direta, abordando assim oque realmente é de valor ;

• Os testes de aceitação auxiliam no desenvolvimento, direcionando em pensar soluções para contemplar os testes, programando preventivamente ;

• Os critérios de aceitação do requisito certificam que iremos entregar oque realmente oque o cliente necessita ;

Documento Padrão de Especificação de Requisitos


Tópicos

• Descrição do Requisito: deve contemplar em tópicos, cada necessidade a ser desenvolvida para atender a funcionalidade, de forma clara e objetiva, que possa ser validada apenas pelo tópico.Neste ponto quem está escrevendo deve ser o mais especifico possível.

BOAS PRÁTICAS �

• Dividir as alterações em tópicos. • Separar as alterações por tela e indicar o caminho da tela, exemplo: Cadastro de Pessoa.• Não generalizar, não utilizar palavras como SEMPRE, NUNCA, AS VEZES.• Buscar focar em um evento especifico.• Indicar os nomes de campos desejados.• Indicar as possíveis validações, e indicar qual deverá ser a mensagem a emitir.• Quando tratar-se de criação de parâmetro de sistema, sugerir nome de parâmetro, possíveis

valores e descrição do parâmetro.

Tentar utilizar o maior número de exemplos possíveis sobre a situação.


Tópicos

• Os testes de aceitação são a MELHOR GARANTIA DE QUALIDADE do requisito e por consequência da entrega!!!

• A boa descrição de casos de testes ajudam a analisar a efetividade da análise no momento da produção do requisito e produção da ferramenta.

• DICAS PARA DESCREVER OS TESTES ��

• DESCREVA CASOS REAIS COM ENTRADAS E SAÍDAS ESPERADAS. NÃO UTILIZE TERMOS SUBJETIVOS.

• DESCREVA ALGUM CASO DE TESTE QUE MOSTRE ALGUMA MENSAGEM DE VALIDAÇÃO SE EXISTIR

• EX. INCORRETO � QUANDO DIGITAR O % DE DESCONTO ESPERO QUE APLIQUE SOBRE O PRODUTO. SE DIGITAR O VALOR DO PRODUTO E O DESCONTO FOR NEGATIVO ESPERO QUE AVISE.

• EX. CORRETO: 1) QUANDO DIGITAR UM PEDIDO COM ITEM NO VALOR DE 100,00 r$ E APLICAR 15 % DE DESCONTO, ESPERO QUE O VALOR TOTAL BRUTO = 100,00 r$ VALOR TOTAL LIQUIDO SEJA = 85,00 r$ E O VALORDE DESCONTO SEJA = 15,00 r$. 2) QUANDO O USUÁRIO INSERIR UM ITEM COM VALOR 100,00 r$ E ALTERAR O VALOR LIQUIDO PARA 110,00 r$, ESPERA-SE QUE O SISTEMA INDIQUE O VALOR DESCONTO = -10,00 r$, E % DESCONTO = -10% E EMITA A MENSAGEM “ATENÇÃO, O VALOR DIGITADO ACARRETOU EM ACRÉSCIMO PARA O VALOR DO ITEM. POR ESTE MOTIVO O VL DESCONTO FICOU NEGATIVO”.


CONCLUSÃO

A chave para construirmos um ótimo produto e cenário para trabalharmos está em nossas mãos.

Já possuimos o conhecimento e ferramentas necessárias…

Vamos utilizar, compartilhar e nos responsabilizar.

Como aprendi com Adriano Dutra:

Pense que você é o cara que dobra o paraquedas após um salto, quando está desenvolvendo uma funcionalidade.

Após entregar, você saltaria com teu paraquedas?


• Muito obrigado,• Jasper W. Perrú• documentaçã[email protected]

Treinamento de Análise de Requisitos

Technology

Transcript of Treinamento de Análise de Requisitos