Qual o nível de detalhe adequado para os requisitos?fattocs.com/files/pt/apresentacoes/NivelDetalhe-11-2016-Guilherme... · O evento não fará uso do vídeo (webcam), somente slides

Guilherme Siqueira Simões

22/11/2016

1

Qual o nível de detalhe adequado

para os requisitos?

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 2

Dê preferência ao uso de uma conexão de banda larga

Feche qualquer outro programa que possa interferir na transmissão de áudio ou na

conexão de Internet.

O evento não fará uso do vídeo (webcam), somente slides e áudio

Se necessário, ajuste o idioma da sala na barra de ferramentas superior

O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas

Você pode mandar suas perguntas pelo chat ao longo da apresentação

Para quem possui a certificação PMP, o evento vale 1 PDU

A apresentação será gravada e o vídeo publicado posteriormente no site e redes

sociais:

ORIENTAÇÕES INICIAIS


MISSÃO

Estimativas e Medição de Projetos de Software

Implantação da Análise de Pontos de Função (IFPUG, NESMA , COSMIC)

Auditoria de Medições de Projetos de Software Medidos com APF

Benchmarking e Análises de produtividade

Avaliação para Melhoria dos Processos de Software

Engenharia de Requisitos

Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade)

Construção e Monitoramento de Contratos de Software baseados em Resultados

Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando Métricas Funcionais

DIRECIONAMENTO ESTRATÉGICO COM:

Apoiar nossos clientes a ter mais visibilidade do desempenho de seus processos de software e a

estabelecer modelos de negócios em que eles tenham o controle sobre os mesmos.


Engenharia de Requisitos de

Software

24 horas

Estimativa de Projetos de

Software: Fundamentos e

Técnicas

16 horas

Oficina de Contagem

de Pontos de Função

Sessões de 8 ~ 40 horas

Gestão de Riscos em Projetos

16 horas

Oficina de Requisitos

Sessões de 8 ~ 40 horas

Introdução ao Gerenciamento

de Projetos

16 horas

Medição e Estimativa de

Software com o Método

COSMIC

16 horas (Presencial)

Preparação para

o Exame CFPS

96 horas (EAD e presencial)

APF: Fundamentos,

Benefícios e Implantação


Capacitação em APF:

Medição e

Estimativa de Software


Workshop APF:

Metodologia

e Práticas de Medição

16 horas (Presencial)

FORMAÇÃO PROFISSIONAL

Mais de 14.000 alunos capacitados

O livro mais vendido de APF no país foi escrito por nós

Formou >25% dos CFPS no Brasil

Preparação para

o Exame COSMIC


Objetivos desta apresentação

O que é especificação de requisitos

Por que observar o nível adequado de detalhe?

Critérios que impactam o nível de detalhe

Conclusão


O que é especificação de requisitos?

É a documentação das capacidades desejadas pelo usuário para um software ou já existentes no mesmo

É um contrato entre clientes e equipe de desenvolvimento

Deve esclarecer aos clientes o que será entregue como produto do trabalho da equipe de desenvolvimento

Assim como permitir que a equipe de desenvolvimento consiga compreender exatamente o que os clientes desejam


Requisitos para quem?

Especificação

de requisitos

Gerência de Projetos

Testes

Medição e Análise

Implantação

Implementação

Análise e Projeto

plano de projeto e acompanhamento - escopo, orçamento e prazo

projeto da solução

projeto do banco de dados

material de treinamento e de suporte ao usuário

estimativas e medições

casos de teste

necessidades do cliente

acordos sobre a entrega

Produz insumos para...

equipe

cliente

Contrato entre as partes!

7© 2016 FATTO Consultoria e Sistemas | www.fattocs.com

Exemplo Especificação de Requisitos


Quão detalhado deve ser o contrato?

É um equívoco pensar que quanto mais detalhada a especificação de requisitos, melhor ela é. Detalhar demais pode ser um elemento paralisante do projeto, o software tem que ser entregue

Documentação não substitui a comunicação entre as partes!

Quanto maior a relação de confiança entre as partes, mais enxuto pode ser esse contrato. E vice-versa

Um contrato verbal só funciona quando as partes possuem um alto nível de confiança e quando o objeto do contrato é simples

Que critérios específicos afetam o nível de detalhe?


Objetivo da especificação

Uma especificação de requisitos pode ser elaborada visando alcançar três objetivos distintos

– Delimitar o escopo de forma preliminar (visão ampla)

– Definir o funcionamento das transações (visão profunda do todo ou parte do software)

– Estruturar os requisitos para design e implementação


Inte

rno

• A interação cara a cara é mais fácil e frequente

• A equipe de desenvolvimento e clientes, em geral, são colegas de trabalho

Exte

rno

• A equipe de projeto é composta de funcionários de fornecedores

• Menos possibilidade de interação cara a cara, portanto mais necessidade de detalhes

Desenvolvimento Interno x Externo


• Todos no mesmo espaço físico

• Comunicação mais fácilAgrupada

• Trabalho remoto

• Falta de convivência, barreira de comunicação

Dispersa

Equipe Agrupada x Dispersa


A incerteza nas estimativas está diretamente relacionada ao nível de maturidade e dos requisitos

Quanto mais cedo se necessita de uma estimativa, menos maduros estarão os requisitos

Para gerar uma estimativa de ordem de grandeza, não é necessário uma especificação de requisitos tão detalhada

Nível de Incerteza nas Estimativas


“Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.” – Princípio 4 do manifesto ágil

O cliente que é altamente participativo constrói una relação mais forte com a equipe– A comunicação cara a cara é mais

frequente

Nível de Participação dos clientes


“Para bom entendedor, meia palavra basta”Interno

– A mesma equipe executa vários projetos para a mesma área de negocio

– Comunicação com o cliente no mesmo nível

Externo– Há fornecedores que atuam exclusivamente com projetos de

áreas de negocio especificasFacilita a comunicação com o cliente

– Também há fornecedores sem tanta especialização. Neste caso os responsáveis devem estudar previamente o negócio, e ainda assim será necessário mais detalhe na especificação

Conhecimento do negócio


Precedentes são importantes fontes de informação

Trabalho com características similares

Reengenharia de sistema existente

• Por exemplo, em nova tecnologia

• Detalhes podem não ser tão necessários

Manutenções similares em sistemas distintos

• Decisões adotadas na primeira manutenção podem ser úteis nas seguintes


Quando o processo de negocio ainda não está maduro o projeto estará sujeito a uma grande demanda de solicitações de mudança

– Nestes casos produzir uma especificação mais detalhada será um desafio

– Manter esta documentação detalhada e consistente implicará muito esforço

Desenvolvimento concorrente de procedimentos de negocio


Uso de pacote na solução

Configuração

Adequação nativa do pacote

Personalização

Alterações que envolvem código

fonte

Manutenção

Adaptação de legados para o

pacote

Uma especificação para adquirir, configurar ou personalizar um pacote, em geral demanda menos detalhes que o desenvolvimento de um software inteiramente novo


Desafio para a Gestão do Conhecimento

Regra Geral:

Rotatividade de pessoal

Menos rotatividade,

menos detalhe

Mais rotatividade, mais detalhe


Nem sempre mais detalhe significa uma especificação melhor

Conclusão

Menos detalhe na especificação Mais detalhe na especificação

Visão ampla do escopo Visão profunda (do todo ou parte) do escopo

Desenvolvimento interno Desenvolvimento externo

Equipe agrupada Equipe dispersa

Exigência por estimativas menos precisas Exigência por estimativas mais precisas

Alto envolvimento dos clientes Baixo envolvimento dos clientes

Alto conhecimento da equipe no negócio Pouco conhecimento da equipe no negócio

Precedentes existentes Sem precedentes

Uso de pacotes na solução Solução não adotará pacote

Baixa expectativa de rotatividade de pessoal Alta expectativa de rotatividade de pessoal


Para saber mais

Curso: Engenharia de Requisitos: Software Orientado ao Negócio

– On-line: http://fattocs.com/pt/ereq-ead

Webinars:

– Dificuldades ao lidar com requisitos (youtu.be/mckx4m95Z88)

– Qualidade em Requisito (youtu.be/d8XmSaER2F4)

– Protótipos: um brinquedo valioso (youtu.be/4boO7LoUTmM)

– Rastreabilidade de Requisitos (youtu.be/g0q9tUzfZGI)

Grupo de discussão: Engenharia de Requisitos

– https://br.groups.yahoo.com/groups/engenharia-requisitos


http://fattocs.com/pt/ereq-ead

youtu.be/mckx4m95Z88

https://youtu.be/d8XmSaER2F4

https://youtu.be/4boO7LoUTmM

https://youtu.be/g0q9tUzfZGI

https://br.groups.yahoo.com/groups/engenharia-requisitos

22

AVALIAÇÃO DO EVENTO


23

PRÓXIMOS EVENTOS

• WEBINARS:

Aceitando o software: Como garantir a qualidade dos projetos de software

Data: 13/12/16 às 20h Inscrição: https://goo.gl/HfPL5B

• PRÓXIMAS TURMAS ENGENHARIA DE REQUISITOS

06/12 a 08/12 – São Paulo

06/12 a 08/12 – Curitiba

Curso ON-LINE - Início imediato


https://goo.gl/HfPL5B

24

PERGUNTAS?

Brasília: (61) 4063-7484

São Paulo: (11) 4063-4658

Vitória: (27) 3026-6304

Rio de Janeiro: (21) 4063-5311

Obrigado pela sua atenção!

Guilherme Siqueira Simõ[email protected]

www.linkedin.com/in/guilhermesimoes

Skype: guilherme.s.simoes


Documents

Qual o nível de detalhe adequado para os requisitos?fattocs.com/files/pt/apresentacoes/NivelDetalhe-11-2016-Guilherme... · O evento não fará uso do vídeo (webcam), somente slides