SlideShare uma empresa Scribd logo
1 de 108
Prof. Msc. Paulo Furtado
paulofurtado.ti@gmail.com
@paulofurtadoti
2013
Apresentações
 Professor
 Turma
 Disciplina
2
A Turma
1. Quem é você?
2. Onde trabalha?
3. Por que está fazendoeste curso?
A Disciplina
O que é? O que não é?
Não é uma disciplina que vai te ensinar
uma receita de bolo para fazer
levantamento de requisitos;
Não é uma disciplina que vai dar um
conjunto de modelo de artefatos para você
usar como referência para fazer
levantamento de requisitos
É uma disciplina que
vai dar questionar a
forma como hoje
fazemos identificação
de requisitos
É uma disciplina que
trata a priorização
como conceito-chave
para o bom andamento
do desenvolvimento
Bibliografia
Dúvidas?
? ?
? ?
? ?
? ?
?
? ? ?
Aula 01
Conceitos Iniciais
 Palavras-chave
 O que são Requisitos?
 O que é Agilidade
 Ruídos em
Levantamento de
Requisitos
 Gráfico de
Funcionalidades
 Processo Incremental e
Iterativo
Palavras-Chave
Palavras-Chave
1. Acto de levantar ou de levantar-se.
2. Revolta; rebelião.
3. Acto de levantar um cerco.
4. Elevação.
5. Aumento; acréscimo.
6. [Topografia] Desenho da planta de um terreno, da
carta de uma região, etc., depois de feitas as necessárias
medições.
7. Listagem ou recolha de informações.
Palavras-Chave
1. Que se move com facilidade e presteza.
2. [Figurado] Vivo.
Atentem para as seguintes palavras:
- Simplicidade;
- Objetividade;
- Priorização;
- Adaptabilidade;
Palavras-Chave
1. Coisa necessária e indispensável.
2. Condição indispensável; exigência.
3. Requerido; requisitado.
Na minha visão, um software
bem desenvolvido é...
+ =
Funcionalidades
7%
13%
16%
19%
45%
Média de uso de funcionalidades de sistemas
Sempre
Frequentement
e
Às vezes
Standish Group, 2002
PROBLEMA:
“Nós temos a tendência de NÃO
tratar o cliente de software como
um cliente que gasta dinheiro.”
R$ 500.000,00
Quinhentos mil reais
R$ 500.000,00R$ 500.000,00
O Cliente é responsável, mas como
dizer isso a ele?
Nível de Ruídos em Projetos
Simples
Anarquia
Complexo
Perto da
certeza
Longe da
certeza
Tecnologia
Perto de
Acordo
Longe de
acordo
Requerimentos
Fonte: Strategic Management and
Organizational Dynamics by Ralph Stacey
in Agile Software Development with Scrum
by Ken Schwaber and Mike Beedle.
User Stories Applied
“Those who want the new software must
communicate with those who will build the
new software.”
O valor dos requisitos é RELATIVO
Contexto é importante
Escolha um cenário...
+
+
=
=
?
?
O Cliente é tratado como Cliente!
Desenvolvimento Incremental e Iterativo
Pensando um pouco...
Requisitos
Iteração 1 Iteração 2 Iteração N
...
Especific. Desenvolv Testes Produção
Isso não é
do jeito
que eu
queria !!!
Mas... por quê mesmo precisamos
investir em processos?
 Ter mais produtividade?
 Aumentar a probabilidade de
sucesso nos projetos?
 Padronização de tarefas
frequentes?
 “Garantir” a qualidade do
software?
Jim Highsmith
Agile Consultant
Martin Fowler
"Para muitas pessoas, o surgimento das
metodologias ágeis é uma reação às
metodologias de engenharia burocráticas.
Entretanto, estas "novas" metodologias
visam ser uma forma útil entre ter nenhum
processo e muito processo, fornecendo
processo suficiente para obter um retorno
satisfatório."
Conceitos Iniciais
 Visão de Produto
 Evolução
 Processo Cognitivo de
aprendizado
Visão de Produto
 Define as fronteiras do projeto deixando bem claro
o objetivo macro do produto a ser desenvolvido;
 Tem o objetivo de estabelecer um acordoinicial
entre os participantes do projeto sobre as
funcionalidades que devem ser implementadas;
 Ela ajuda a guiar as mudanças que vão ocorrer no
projeto para identificar se existem grandes distorções
em relação ao que foi acordado inicialmente;
Business Model Canvas
 Usado para realizar planejamento estratégico e
melhorar modelos de negócio (novos ou não);
 Mapa que contém 9 (nove) blocos para um modelo
de negócio
 Criado por Alexander Osterwalder
Um Business Model é um mapa
dos principais itens que constituem
uma empresa. O Mapa é um
resumo dos pontos chave de um
plano de negócio.
Alianças de negócios
que contemplam os
outros aspectos do
modelo de negócio
Principais Parceiros
Atividades
necessárias para
executar o Modelo de
Negócio
Principais Atividades
Recursos
necessários para
criar valor para o
cliente
Principais Recursos
Proposições a serem
atendidas.
Que
necessidades, do
público-alvo a que se
destina meu
negócio, precisam
ser atendidas?
Proposição de Valor Ligação entre a
empresa e seus
clientes
Relac. com Cliente
Meio pelo qual uma
empresa fornece
produtos e serviços
Canais
O Público-
alvo para os
produtos e
serviços de
uma
empresa
Segmentos de Clientes
A forma como a empresa
ganha dinheiro através de uma
variedade de fluxos de receita.
Fluxos de Receita
Consequência monetária dos
meios utilizados no modelo de
negócio. (Despesas)
Estrutura de Custos
1
2
3
4
5
6
78
9
Desenhe um modelo de
Negócio para um
produto de Software
utilizando o Business
Model Canvas
(30 min)
O Que é isso?
A visão no ajuda a seguir um caminho
E se fosse assim?
O que você entende por...
 Evolução?
 Nova fase em que entra uma ideia, um sistema, uma
ciência, etc.
 Desenvolvimento ou transformação gradual e
progressiva (operada nas ideias, etc.).
 Aprender com o Tempo
 Processo Cognitivo?
 Capacidade de aprender e evoluir levando em
consideração a
atenção, percepção, memória, raciocínio, imaginação, p
ensamento, discurso...
A comunicação é um dos
maiores facilitadores no
processo de aprendizagem e
evolução.
User Stories Applied
“Those who want the new software must
communicate with those who will build the
new software.”
Como facilitar a comunicação?
 Que tal aplicando/privilegiando o uso de
atividades cognitivas, ou seja, fazer com que
as pessoas aprendam através da
observação, percepção e comunicação?
 No que se refere ao desenvolvimento de
software, a criação/definição de papéis antes
da identificação das funcionalidades é uma
grande ajuda;
Exemplo
Compra de Tickets para a Copa 2014
 Defina uma visão para um sistema de compra de
Tickets para a copa de 2014.
 Obs: Lembre-se que a visão é uma frase que sinalize o
objetivo macro a que o sistema pretende alcançar.
 Qual o problema?
 O que pretende-se fazer?
 Quem Será beneficiado?
 Que papéis você consegue identificar?
 Que requisitos poderiam ser identificados para tal
sistema?
15 min
Como descrever uma Visão
Para (cliente alvo)
Que (declaração da necessidade ou oportunidade)
O [nome do produto] é um [estratégia do produto]
Que (benefícios, boa razão para comprar)
Diferentemente (outras opções de produto)
Nosso produto (diferenças-chave)
User Stories
 O que é uma User Story
 Estrutura de uma User
Story
 Escrevento User Stories
 Estórias devem ser
INVEST
 Personas
 Epicos, Temas
 Release Planning
Mike Cohn
Authorized
Hi Paulo--
I'm glad you've enjoyed those books. Many others teach classes based on those materials and doing so is
perfectly fine. Please note that I do own the copyright on the titles of those courses so you'll need to call your
classes something slightly different. Thank you for including references to my work.
Good luck with your classes.
Regards,
Mike
ard
onversation
onfirmation
O que é uma User Story?
 Descreve um requisito que é valiosopara um
usuário ou comprador de um sistema de software;
 Estórias levam em consideração 3 aspectos:
 Uma descrição escrita da estória para servir como
lembrete da funcionalidade;
 Conversações sobre as estórias para confirmar os
detalhes escritos na descrição;
 Testes que podem ser usados para determinar quando
uma estória está completa;
Estrutura de uma User Story
Como um <PAPEL>
eu posso/gostaria/devo <FUNÇÃO>
para <VALOR DE NEGÓCIO>
Pagamento via Cartão de Crédito
Como um cliente, Eu gostaria de pagar
usando meu cartão de crédito para poder
parcelar minhas compras.
Observações:
- Aceitar Master Card, Visa e Amex
Restrições:
- Parcelar, no máximo, em 10x
- Cliente não pode estar no SPC
Pagamento via Cartão de Crédito
Critérios de Aceitação
- Teste com MC, Visa e Amex válidos deve
passar
- Compra com outros cartões válidos não
pode passar
- Compra com cartões expirados não deve passar
- Teste com CEP inválido deve bloquear pgto
- Teste com CEP inválido deve bloquear pgto
Verso
 Converta as funcionalidades que foram
encontradas no sistema de compra de tickets
para a Copa de 2014 em User Stories usando
a seguinte regra:
15 min
Como um <PAPEL>
eu posso/gostaria/devo <FUNÇÃO>
para <VALOR DE NEGÓCIO>
Exemplo
Compra de Tickets para a Copa 2014
Estórias devem ser...
I
N
V
E
S
T
ndepent
egociable
aluable
stimable
mall
estable
Sempre que possível, preocupe-se em evitar criação
de dependências entre as estórias
Estórias são negociáveis. Elas não são contratos
requisitos que um software deve implementar.
As estórias devem ter um valor visível para quem
está comprando/pagando pelo produto
Os desenvolvedores devem ter condições suficientes
para estimar uma estória
Uma estória muito grande é difícil de estimar
complexa de desenvolver
As estórias devem ser testáveis
 Dependência entre estórias levam a problemas na
priorização e na estimativa;
 Por exemplo: O cliente selecionou uma estória de alta
prioridade que tem uma outra estória de baixa prioridade
como dependente;
 Outros exemplo:
 Suponha que você tenha uma loja virtual e possui as
seguintes estórias no seu backlog:
1. O cliente pode pagar usando cartão VISA;
2. O cliente pode pagar usando cartão MasterCard;
3. O cliente pode pagar usando cartão America Express;
 Os desenvolvedores estimaram que a implementação do
primeiro cartão demoraria 3 dias;
I ndepent
 Cartões de estórias são descrições pequenas da
funcionalidade, bem como alguns detalhes que precisam
ser negociados em conversa entre desenvolvedores e
cliente;
 Exemplo:
N egociable
O cliente pode efetuar pagamento
com cartão de crédito
Nota: Aceitar VISA, MarterCard e America Express
 Tenha em mente a diferença entre usuário (alguém que
usa o software) e comprador (alguém que compra o
software)
 Muitos projetos possuem estórias que não são valiosas para
os usuários;
 Ex: Toda a informação de configuração deve ser lida de um
servidor central;
 Evite estórias que aparentam ter valor apenas para os
desenvolvedores:
V aluable
Todos os erros e controle
de log devem ser tratados
por um conjunto comum
de classes
Todos os erros devem ser
apresentados aos
usuários de uma maneira
consistente
 É importante que os desenvolvedores sintam-se aptos a
estimar a estória (pelo menos um “chute”)
 Existem pelo menos 3 razões que levam uma estória a não
ser estimada
 O time não conhece o domínio de negócio;
 Uma conversa é necessária com o cliente para sanar dúvidas. Vale
salientar que não é preciso entrar em detalhes de
implementação, mas os desenvolvedores precisam ter uma ideia do
que vão fazer;
 O time não conhece a tecnologia a ser utilizada;
 Tarefas “spike” podem ser criadas para pesquisar a tecnologia;
 A estória é muito grande para ser estimada;
 Neste caso, é importante que a estória seja “quebrada” em outras
estórias até que os desenvolvedores se sintam à vontade para dar
um chute;
E stimable
 O tamanho da estória é muito importante, pois as estórias
podem atrapalhar um planejamento caso sejam grande ou
pequenas demais;
 Um grande indício para saber se a estória está em um
tamanho razoável é observar o time, suas capacidades e a
tecnologia em uso;
 Estórias grandes são muito difíceis de serem priorizadas;
 Uma dica é definir fronteiras nas estivativas. Por exemplo:
Se você usa Planning Poker, pode definir que uma estória
½ é muito pequena e uma estória acima de 13 é muito
grande;
½ - 1 – 2 – 3 – 5 – 8 – 13 – 21 – 34 ...
S mall
 Estórias devem ser escritas de forma que possam ser
testadas;
 Se uma estória não pode ser testada, como os
desenvolvedores podem saber quando terminaram?
 É comum estórias que implementam requisitos “não
funcionais” sejam escritas de forma que não podem ser
testadas:
 Ex: “O usuário não deve esperar muito para a tela de
cadastro aparecer”
 O melhor seria escrevê-la assim:
 “A tela de cadastro deve aparecer em menos de 2 segundos
em 95% dos casos”
T estable
Épico
Épico
Gerenciamento de Emails
Gerenciamento de Contatos
Estórias com uma estimativa (Story Points) alta
Ex: Estórias com um tamanho 21, 34, ...
TEMA
Épico vs Tema
Épico
História
História História
História História História
História História História
Tema
História História História
História História História História História
Estórias mal escritas!
 Quais os sintomas para saber se uma estória:
 É pequena demais
 É Interdependente
 É Goldplating
 Possui muitos detalhes
 Difícil de ser priorizada
Estória Pequena demais
 Sintoma:
 Necessidade frequente de revisar as estimativas
 Discussão:
 Esse problema ocorre quando uma história influencia
nas estimativas caso a ordem de implementação seja
alterada
Estória Interdependente
 Sintoma:
 Dificuldade de planejar as iterações devido às
dependências entre as estórias
 Discussão:
 Acontece quando uma estória que deve entrar na
próxima iteração precisa de uma outra estória que, por
sua vez, precisa de uma terceira e que, por sua vez...
 Estória pequenas demais ou mal “quebradas” fazem com
que esse tipo de problema venha a ocorrer
Estórias Goldplating
 Sintoma:
 Desenvolvedores adicionam funcionalidades que não foram
planejadas e acabam implementando mais que o necessário
 Discussão:
 Goldplating referem-se a funcionalidades adicionais e
desnecessárias
 Razões
 Desenvolvedores querem agradar o cliente
 Desenvolvedores querem fugir da pressão da iteração e fazer outras
atividades
 Desenvolvedores gostam de “colocar sua marca” no projeto
Estória muito detalhada
 Sintoma:
 Gasta-se muito mais tempo escrevendo os detalhes da
estória que falando sobre ela
 Discussão:
 Uma das vantagens em se utilizar cartões para escrever
estórias é que eles são limitados;
 Colocar muitos detalhes em uma história indica que a
documentação está sobrepondo a comunicação;
 “Se você ficar sem espaço em um cartão, use um cartão
menor” (Tom Poppendieck)
Estória difícil de ser priorizada
 Sintoma:
 O cliente sente muita dificuldade de priorizar diversas
estórias
 Discussão:
 A primeira coisa a considerar é o tamanho das estórias. Se
elas são muito grandes, é muito difícil priorizá-las;
 O seu valor de negócio não está claro.
Personas
Perfis de usuário
(User Roles)
 Por que é importante definir diferentes perfis de
usuário?
 Você acha que, para um mesmo perfil de usuário (ex:
Professor, em um sistema acadêmico) temos
características diferentes?
 Cite alguns exemplos de aplicações com uma vasta gama de
usuários;
Passos para criação de Perfis de
Usuário
 Fazer um brainstorm para identificar o conjunto de
perfis iniciais
 Organizar o conjunto de perfis inicial;
 Consolidar os perfis;
 Refinar os perfis;
Atores
Cadastrar
Clientes
Ator Iteração Caso de Uso
Personas
 A criação de personas é uma técnica utilizada para
especificar usuários com um determinado perfil;
 Esta técnicas personaliza o software, fazendo com que
pessoas de perfis diferentes fiquem satisfeitas com o
produto;
Exemplo de Persona
Teovaldo é professor de História
com mais de 20 anos de
experiência. Sempre fez todas
as suas atividades de forma
manual e, apesar de não gostar
de computadores, fica fascinado
com a possibilidade de ganhar
tempo com tarefas
automatizadas por ferramentas
de software.
Mapeamento
de User Stories
 Definindo o Backbone
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
BENEFÍCIOS OU SERVIÇOS OFERECIDOS
FUNCIONALIDADES DO SOFTWARE
DETALHAMENTO
DAS
FUNCIONALIDADES
BACKBONE
ESQUELETO DA APLICAÇÃO
O MAPA
 Backbone:
 Lista de atividades essenciais que dão
suporte à aplicação
 Benefícios do produto
 Esqueleto
 É o software em construção que atende a
um número mínimo de tarefas necessárias
para abranger a todo o ciclo de atividades
do usuário
Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
T E M P O
IMPORTÂNCIA
MAIS IMPORTANTES OU ESSENCIAIS
MENOS IMPORTANTES OU DESCARTÁVEIS
Mapeamento de User Stories
Mapeamento de User Stories
Home Page
Hot jobs ads
Job hunting tips
Post Resume
Resume data fields
Employer Entrance
Account Info
Search Jobs
Search fields
Review Applicants
List of applicants
Post Jobs
Job description fields
Resume View
All resume data
Job Results
List of matching jobs
Job Details
All job information
Estórias identificadas para o site de
empregos
 Uma pessoa pode publicar seu currículo
 Um empregador pode publicar vagas de trabalho
 Um empregador pode revisar currículos submetidos
 Uma pessoa pode procurar por empregos
 Uma pessoa pode visualizar resultados de empregos de
uma pesquisa
 Uma pessoa pode visualizar detalhes sobre empregos
específicos
 É interessante criar protótipos de baixa fidelidade para
ajudar a entender as necessidades do usuário
 Algumas perguntas que podem ser feitas para ajudar a
identificar estórias “escondidas”:
 O que o usuário gostaria fazer em seguida?
 Que erros o usuário poderia cometer aqui?
 O que poderia confundir o usuário neste momento?
 Que informações adicionais seriam interessantes para o
usuário?
 Pense em perfis de usuário e Personas enquanto faz
estas perguntas
Mapeamento de User Stories
Dicas
Priorização
 Dinâmica do Backlog
 Técnica MoSCoW
 Técnica Kano
A
B
C
F
G
H
I
D
Prioridade
Alta
Baixa
E
Estórias
Relembrando a Dinâmica
do Product Backlog
A priorização
 Como objetivo de lançar uma release
do produto, o cliente precisa priorizar
as estorias;
 Existe uma técnica descrita no DSDM
(Dynamic Systems Development
Method) que pode ser usada para
facilitar o processo de priorizacão;
 Esta técnica pode ser encontrada no
livro Business Focused Development;
 Esta técnica recebe o nome de
MoSCow;
Priorização
MoSCoW
Must Have
(Deve ter)
Funcionalidades
fundamentais
para o sistema.
Sem estas
funcionalidades
o sistema não
tem valor para o
cliente
Should Have
(Deveria ter)
Funcionalidades
importantes, ma
s existem
alternativas a
curto prazo para
elas
Could Have
(Poderia ter)
Funcionalidades
que podem ser
“deixadas de
lado” caso o
tempo do projeto
esteja muito
escasso
Won’t have
(Não terá)
Funcionalidades
que não serão
feitas ou não
serão entregues
na release
planejada
# Item BV %BV Size ROI %ROI
1 F1 1000 20% 13 76,92 7%
2 F2 500 10% 8 62,50 6%
3 F3 600 12% 5 120,00 11%
4 F4 400 8% 21 19,05 2%
5 F5 800 16% 3 266,67 24%
6 F6 500 10% 5 100,00 9%
7 F7 900 18% 5 180,00 16%
8 F8 300 6% 1 300,00 27%
TOTAL 5000 61
Ruído em Projetos
Priorização KANO
 É uma das técnicas de priorização mais utilizadas
 Realizar perguntas direcionadas para um grupos de usuários
 Você deve realizar uma pergunta funcional:
 Como você se sentirá se o requisito estiver presente no produto?
 Você deve realizar uma pergunta disfuncional:
 Como você se sentirá se o requisito NÃO estiver presente no
produto?
 Feito isso, você deve combinar as respostas e colher as
informações
Kano: Exemplo
 Termômetro de temperatura em uma cerveja em lata
 Pergunta Funcional: Como você se sentirá ao ver um
termômetro de temperatura na latinha de cerveja?
 Pergunta Disfuncional : Como você se sentirá em
não ver um termômetro de temperatura na latinha de
cerveja?
Kano: Exemplo
Kano: Exemplo
 Pergunta Funcional: Como você se sentirá ao ver um
termômetro de temperatura na latinha de cerveja?
( ) Me Agradaria
( ) Quero que tenha
( ) Tanto faz
( ) Não Gostaria
 Pergunta Disfuncional: Como você se sentirá a NÃO ver um
termômetro de temperatura na latinha de cerveja?
( ) Me Agradaria, desejo
( ) Quero que tenha, espero imagino
( ) Tanto faz, posso conviver sem isso
( ) Não Gostaria
X
X
Kano: Resultado
 Após efetuar o questionário a um grupo de 20 usuários, você
deve checar a resposta funcional e não funcional de cada um
deles e chegar a um valor da tabela.
 No exemplo anterior:
 Pergunta Funcional: Como você se
sentirá ao ver um termômetro de
temperatura na latinha de cerveja?
(Resposta: Me agradaria)
 Pergunta Disfuncional: Como você se
sentirá a NÂO ver um termômetro de
temperatura na latinha de cerveja?
(Resposta: Tanto faz)
 Dessa forma, para este usuário, o valor
obtido com o cruzamento da informações
foi Atrativo (A)
Prototipação
 Sketch
 Mapas Mentais
Bibliografia
95
Protótipo
Do latim, proto ORIGINAL e
tipo MODELO.
Um tipo, forma ou exemplar
original que serve como base ou
padrão para futuros estágios de
um projeto ou simplesmente: um
exemplar inicial que comunica
uma idéia.
Prototipação
 Processo iterativo, para a
criação de protótipos que serve
para rapidamente testar
conceitos, produtos e negócios e
trazer respostas a uma pergunta.
Dica...
Quanto mais cedo
erramos, mais cedo
temos sucesso
Comunicação Visual
Visão Imagem
 A comunicação visual é rápida, eficiente e
simples.
 Como fazer isso
 Sketch (esboço)
 Protótipo
Técnica: SKETCH (esboço)
Sketch – características
Como nascem algumas aplicações...
Ferramentas para Sketch
Ferramentas para Sketch
Mapeamento de User Stories
Home Page
Hot jobs ads
Job hunting tips
Post Resume
Resume data fields
Employer Entrance
Account Info
Search Jobs
Search fields
Review Applicants
List of applicants
Post Jobs
Job description fields
Resume View
All resume data
Job Results
List of matching jobs
Job Details
All job information
Técnica: Mapa mental
Diagrama usado para representar
palavras, ideias, tarefas e outros
itens ligados e dispostos ao redor
de uma palavra ou ideia central.
Mapa Mental
Mapas mentais são bons para...
 Visualizar ideias
 Relacionamentos entre elementos
 Brainstorming, Ideação
 Tomar decisões a partir de anotações
 Quebrar problemas em pedaços
 Organizar a mente
Fonte: Paolo Passeri – Técnicas de Prototipação
Dicas
 Melhores
práticas
Melhores Práticas
1. Stakeholders actively participate
2. Adopt inclusive models
3. Model storm details just in time (JIT)
4. Treat requirements like a prioritized stack
5. Prefer executable requirements over static documentation
6. Your goal is to implement requirements, not document them
7. Recognize that you have a wide range of stakeholders
8. Smaller is better
9. Question traceability
10. Explain the techniques
11. Adopt stakeholder terminology
12. Keep it fun
13. Obtain management support
14. Turn stakeholders into developers
Obrigado!
Prof. Paulo Furtado
paulofurtado.ti@gmail.com
@paulofurtadoti

Mais conteúdo relacionado

Mais procurados

Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Elaine Cecília Gatto
 
Modelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareModelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareBruno Bitencourt Luiz
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitosMailson Queiroz
 
Aps lista de exercícios
Aps lista de exercíciosAps lista de exercícios
Aps lista de exercíciosGuilherme
 
Banco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de ConcorrênciaBanco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de ConcorrênciaJuliano Padilha
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Cloves da Rocha
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Luís Fernando Richter
 
Aula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de InformaçãoAula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de InformaçãoDaniel Brandão
 
Metodologia ágil das Desenvolvimento Adaptativo Software
Metodologia ágil das   Desenvolvimento Adaptativo SoftwareMetodologia ágil das   Desenvolvimento Adaptativo Software
Metodologia ágil das Desenvolvimento Adaptativo SoftwareMarilainny Martins da Silva
 
Diagrama de Estados
Diagrama de EstadosDiagrama de Estados
Diagrama de EstadosMaikynata
 
Metodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de SoftwaresMetodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de SoftwaresAragon Vieira
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitoselliando dias
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de ConfiguraçãoWagner Zaparoli
 

Mais procurados (20)

Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4Modelos de Processo de Software Parte 4
Modelos de Processo de Software Parte 4
 
Modelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de SoftwareModelo V - Desenvolvimento de Software
Modelo V - Desenvolvimento de Software
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Engenharia de requisitos
Engenharia de requisitosEngenharia de requisitos
Engenharia de requisitos
 
Aps lista de exercícios
Aps lista de exercíciosAps lista de exercícios
Aps lista de exercícios
 
Banco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de ConcorrênciaBanco de Dados - Transações e Controle de Concorrência
Banco de Dados - Transações e Controle de Concorrência
 
O que é um Banco de Dados Relacional?
O que é um Banco de Dados Relacional?O que é um Banco de Dados Relacional?
O que é um Banco de Dados Relacional?
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
Aula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de InformaçãoAula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de Informação
 
Metodologia ágil das Desenvolvimento Adaptativo Software
Metodologia ágil das   Desenvolvimento Adaptativo SoftwareMetodologia ágil das   Desenvolvimento Adaptativo Software
Metodologia ágil das Desenvolvimento Adaptativo Software
 
Escrevendo Estórias do Usuário Eficazes
Escrevendo Estórias do Usuário EficazesEscrevendo Estórias do Usuário Eficazes
Escrevendo Estórias do Usuário Eficazes
 
Diagrama de Estados
Diagrama de EstadosDiagrama de Estados
Diagrama de Estados
 
Metodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de SoftwaresMetodologia de Desenvolvimento de Softwares
Metodologia de Desenvolvimento de Softwares
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
 
Gerência de Configuração
Gerência de ConfiguraçãoGerência de Configuração
Gerência de Configuração
 

Semelhante a Levantamento de requisitos para sistema de compra de ingressos para a Copa de 2014

Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economia
 Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economia Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economia
Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economiaRaphael Donaire Albino
 
Requisitos ageis paulofurtado_2014
Requisitos ageis paulofurtado_2014Requisitos ageis paulofurtado_2014
Requisitos ageis paulofurtado_2014Paulo Furtado
 
Desenvolvimento de Negócios Inovadores
Desenvolvimento de Negócios InovadoresDesenvolvimento de Negócios Inovadores
Desenvolvimento de Negócios InovadoresSoraia Gomes
 
Gestão Ágil de projetos
Gestão Ágil de projetosGestão Ágil de projetos
Gestão Ágil de projetosPaulo Furtado
 
Desenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowskiDesenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowskiErick Krulikowski
 
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016Coletivo Mola
 
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016DTStartups
 
Resumo Eureca! - The Lean Startup
Resumo Eureca! - The Lean StartupResumo Eureca! - The Lean Startup
Resumo Eureca! - The Lean StartupEureca!
 
Transformational Design Thinking - Aula 8
Transformational Design Thinking - Aula 8Transformational Design Thinking - Aula 8
Transformational Design Thinking - Aula 8Lu Terceiro
 
Ok118 slids como planejar projeto logístico pelo modelo canvas
Ok118 slids  como planejar projeto logístico pelo modelo canvasOk118 slids  como planejar projeto logístico pelo modelo canvas
Ok118 slids como planejar projeto logístico pelo modelo canvasdelano chaves gurgel do amaral
 
[Product Camp 2021] Escalando a gestão de produtos internos
[Product Camp 2021] Escalando a gestão de produtos internos[Product Camp 2021] Escalando a gestão de produtos internos
[Product Camp 2021] Escalando a gestão de produtos internosProduct Camp Brasil
 
Apresentação do vídeo introdutório do workshop inception enxuta
Apresentação do vídeo introdutório do workshop inception enxutaApresentação do vídeo introdutório do workshop inception enxuta
Apresentação do vídeo introdutório do workshop inception enxutaMayra de Souza
 
Workshop Inception Enxuta
Workshop Inception EnxutaWorkshop Inception Enxuta
Workshop Inception EnxutaMayra de Souza
 
Workshop sobre modelos de negocio (canvas) Empreenda-2015 no Insper
Workshop sobre modelos de negocio (canvas) Empreenda-2015 no InsperWorkshop sobre modelos de negocio (canvas) Empreenda-2015 no Insper
Workshop sobre modelos de negocio (canvas) Empreenda-2015 no InsperNei Grando
 
Planejamento e Gestão Em Mídias Digitais - Aula 02
Planejamento e Gestão Em Mídias Digitais - Aula 02Planejamento e Gestão Em Mídias Digitais - Aula 02
Planejamento e Gestão Em Mídias Digitais - Aula 02Caio Oliveira
 
Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)Alessandro Almeida
 

Semelhante a Levantamento de requisitos para sistema de compra de ingressos para a Copa de 2014 (20)

Aula lumus
Aula lumusAula lumus
Aula lumus
 
Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economia
 Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economia Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economia
Os desafios de desenvolver uma cultura ágil: eficácia, eficiência e economia
 
Requisitos ageis paulofurtado_2014
Requisitos ageis paulofurtado_2014Requisitos ageis paulofurtado_2014
Requisitos ageis paulofurtado_2014
 
Desenvolvimento de Negócios Inovadores
Desenvolvimento de Negócios InovadoresDesenvolvimento de Negócios Inovadores
Desenvolvimento de Negócios Inovadores
 
Gestão Ágil de projetos
Gestão Ágil de projetosGestão Ágil de projetos
Gestão Ágil de projetos
 
Desenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowskiDesenvolvimento e modelagem de negócios criativos erick krulikowski
Desenvolvimento e modelagem de negócios criativos erick krulikowski
 
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
 
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
Workshop de Jornada do Usuário - The Developer's Conference São Paulo 2016
 
Resumo Eureca! - The Lean Startup
Resumo Eureca! - The Lean StartupResumo Eureca! - The Lean Startup
Resumo Eureca! - The Lean Startup
 
Transformational Design Thinking - Aula 8
Transformational Design Thinking - Aula 8Transformational Design Thinking - Aula 8
Transformational Design Thinking - Aula 8
 
The Lean LaunchPad
The Lean LaunchPadThe Lean LaunchPad
The Lean LaunchPad
 
Guia modelagem-negocios
Guia modelagem-negociosGuia modelagem-negocios
Guia modelagem-negocios
 
Ok118 slids como planejar projeto logístico pelo modelo canvas
Ok118 slids  como planejar projeto logístico pelo modelo canvasOk118 slids  como planejar projeto logístico pelo modelo canvas
Ok118 slids como planejar projeto logístico pelo modelo canvas
 
Business Model Canvas
Business Model CanvasBusiness Model Canvas
Business Model Canvas
 
[Product Camp 2021] Escalando a gestão de produtos internos
[Product Camp 2021] Escalando a gestão de produtos internos[Product Camp 2021] Escalando a gestão de produtos internos
[Product Camp 2021] Escalando a gestão de produtos internos
 
Apresentação do vídeo introdutório do workshop inception enxuta
Apresentação do vídeo introdutório do workshop inception enxutaApresentação do vídeo introdutório do workshop inception enxuta
Apresentação do vídeo introdutório do workshop inception enxuta
 
Workshop Inception Enxuta
Workshop Inception EnxutaWorkshop Inception Enxuta
Workshop Inception Enxuta
 
Workshop sobre modelos de negocio (canvas) Empreenda-2015 no Insper
Workshop sobre modelos de negocio (canvas) Empreenda-2015 no InsperWorkshop sobre modelos de negocio (canvas) Empreenda-2015 no Insper
Workshop sobre modelos de negocio (canvas) Empreenda-2015 no Insper
 
Planejamento e Gestão Em Mídias Digitais - Aula 02
Planejamento e Gestão Em Mídias Digitais - Aula 02Planejamento e Gestão Em Mídias Digitais - Aula 02
Planejamento e Gestão Em Mídias Digitais - Aula 02
 
Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (08/08/2013)
 

Último

Aula - 2º Ano - Cultura e Sociedade - Conceitos-chave
Aula - 2º Ano - Cultura e Sociedade - Conceitos-chaveAula - 2º Ano - Cultura e Sociedade - Conceitos-chave
Aula - 2º Ano - Cultura e Sociedade - Conceitos-chaveaulasgege
 
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdfcartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdfIedaGoethe
 
Sociologia Contemporânea - Uma Abordagem dos principais autores
Sociologia Contemporânea - Uma Abordagem dos principais autoresSociologia Contemporânea - Uma Abordagem dos principais autores
Sociologia Contemporânea - Uma Abordagem dos principais autoresaulasgege
 
DIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdf
DIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdfDIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdf
DIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdfIedaGoethe
 
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃOLEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃOColégio Santa Teresinha
 
Aula 1, 2 Bacterias Características e Morfologia.pptx
Aula 1, 2  Bacterias Características e Morfologia.pptxAula 1, 2  Bacterias Características e Morfologia.pptx
Aula 1, 2 Bacterias Características e Morfologia.pptxpamelacastro71
 
Época Realista y la obra de Madame Bovary.
Época Realista y la obra de Madame Bovary.Época Realista y la obra de Madame Bovary.
Época Realista y la obra de Madame Bovary.keislayyovera123
 
Slides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptx
Slides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptxSlides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptx
Slides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptxLuizHenriquedeAlmeid6
 
Habilidades Motoras Básicas e Específicas
Habilidades Motoras Básicas e EspecíficasHabilidades Motoras Básicas e Específicas
Habilidades Motoras Básicas e EspecíficasCassio Meira Jr.
 
Slides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptx
Slides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptxSlides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptx
Slides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptxLuizHenriquedeAlmeid6
 
Aula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologia
Aula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologiaAula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologia
Aula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologiaaulasgege
 
Apostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptx
Apostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptxApostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptx
Apostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptxIsabelaRafael2
 
FCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimirFCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimirIedaGoethe
 
activIDADES CUENTO lobo esta CUENTO CUARTO GRADO
activIDADES CUENTO  lobo esta  CUENTO CUARTO GRADOactivIDADES CUENTO  lobo esta  CUENTO CUARTO GRADO
activIDADES CUENTO lobo esta CUENTO CUARTO GRADOcarolinacespedes23
 
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANOInvestimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANOMarcosViniciusLemesL
 
Prática de interpretação de imagens de satélite no QGIS
Prática de interpretação de imagens de satélite no QGISPrática de interpretação de imagens de satélite no QGIS
Prática de interpretação de imagens de satélite no QGISVitor Vieira Vasconcelos
 
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024Sandra Pratas
 
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdfO Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdfPastor Robson Colaço
 

Último (20)

Aula - 2º Ano - Cultura e Sociedade - Conceitos-chave
Aula - 2º Ano - Cultura e Sociedade - Conceitos-chaveAula - 2º Ano - Cultura e Sociedade - Conceitos-chave
Aula - 2º Ano - Cultura e Sociedade - Conceitos-chave
 
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdfcartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
cartilha-pdi-plano-de-desenvolvimento-individual-do-estudante.pdf
 
Sociologia Contemporânea - Uma Abordagem dos principais autores
Sociologia Contemporânea - Uma Abordagem dos principais autoresSociologia Contemporânea - Uma Abordagem dos principais autores
Sociologia Contemporânea - Uma Abordagem dos principais autores
 
DIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdf
DIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdfDIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdf
DIA DO INDIO - FLIPBOOK PARA IMPRIMIR.pdf
 
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃOLEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
LEMBRANDO A MORTE E CELEBRANDO A RESSUREIÇÃO
 
Em tempo de Quaresma .
Em tempo de Quaresma                            .Em tempo de Quaresma                            .
Em tempo de Quaresma .
 
Orientação Técnico-Pedagógica EMBcae Nº 001, de 16 de abril de 2024
Orientação Técnico-Pedagógica EMBcae Nº 001, de 16 de abril de 2024Orientação Técnico-Pedagógica EMBcae Nº 001, de 16 de abril de 2024
Orientação Técnico-Pedagógica EMBcae Nº 001, de 16 de abril de 2024
 
Aula 1, 2 Bacterias Características e Morfologia.pptx
Aula 1, 2  Bacterias Características e Morfologia.pptxAula 1, 2  Bacterias Características e Morfologia.pptx
Aula 1, 2 Bacterias Características e Morfologia.pptx
 
Época Realista y la obra de Madame Bovary.
Época Realista y la obra de Madame Bovary.Época Realista y la obra de Madame Bovary.
Época Realista y la obra de Madame Bovary.
 
Slides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptx
Slides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptxSlides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptx
Slides Lição 03, Central Gospel, O Arrebatamento, 1Tr24.pptx
 
Habilidades Motoras Básicas e Específicas
Habilidades Motoras Básicas e EspecíficasHabilidades Motoras Básicas e Específicas
Habilidades Motoras Básicas e Específicas
 
Slides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptx
Slides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptxSlides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptx
Slides Lição 4, CPAD, Como se Conduzir na Caminhada, 2Tr24.pptx
 
Aula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologia
Aula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologiaAula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologia
Aula - 1º Ano - Émile Durkheim - Um dos clássicos da sociologia
 
Apostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptx
Apostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptxApostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptx
Apostila da CONQUISTA_ para o 6ANO_LP_UNI1.pptx
 
FCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimirFCEE - Diretrizes - Autismo.pdf para imprimir
FCEE - Diretrizes - Autismo.pdf para imprimir
 
activIDADES CUENTO lobo esta CUENTO CUARTO GRADO
activIDADES CUENTO  lobo esta  CUENTO CUARTO GRADOactivIDADES CUENTO  lobo esta  CUENTO CUARTO GRADO
activIDADES CUENTO lobo esta CUENTO CUARTO GRADO
 
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANOInvestimentos. EDUCAÇÃO FINANCEIRA 8º ANO
Investimentos. EDUCAÇÃO FINANCEIRA 8º ANO
 
Prática de interpretação de imagens de satélite no QGIS
Prática de interpretação de imagens de satélite no QGISPrática de interpretação de imagens de satélite no QGIS
Prática de interpretação de imagens de satélite no QGIS
 
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
HORA DO CONTO5_BECRE D. CARLOS I_2023_2024
 
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdfO Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
O Universo Cuckold - Compartilhando a Esposas Com Amigo.pdf
 

Levantamento de requisitos para sistema de compra de ingressos para a Copa de 2014

  • 1. Prof. Msc. Paulo Furtado paulofurtado.ti@gmail.com @paulofurtadoti 2013
  • 3. A Turma 1. Quem é você? 2. Onde trabalha? 3. Por que está fazendoeste curso?
  • 4. A Disciplina O que é? O que não é? Não é uma disciplina que vai te ensinar uma receita de bolo para fazer levantamento de requisitos; Não é uma disciplina que vai dar um conjunto de modelo de artefatos para você usar como referência para fazer levantamento de requisitos É uma disciplina que vai dar questionar a forma como hoje fazemos identificação de requisitos É uma disciplina que trata a priorização como conceito-chave para o bom andamento do desenvolvimento
  • 6. Dúvidas? ? ? ? ? ? ? ? ? ? ? ? ?
  • 7. Aula 01 Conceitos Iniciais  Palavras-chave  O que são Requisitos?  O que é Agilidade  Ruídos em Levantamento de Requisitos  Gráfico de Funcionalidades  Processo Incremental e Iterativo
  • 9. Palavras-Chave 1. Acto de levantar ou de levantar-se. 2. Revolta; rebelião. 3. Acto de levantar um cerco. 4. Elevação. 5. Aumento; acréscimo. 6. [Topografia] Desenho da planta de um terreno, da carta de uma região, etc., depois de feitas as necessárias medições. 7. Listagem ou recolha de informações.
  • 10. Palavras-Chave 1. Que se move com facilidade e presteza. 2. [Figurado] Vivo. Atentem para as seguintes palavras: - Simplicidade; - Objetividade; - Priorização; - Adaptabilidade;
  • 11. Palavras-Chave 1. Coisa necessária e indispensável. 2. Condição indispensável; exigência. 3. Requerido; requisitado.
  • 12. Na minha visão, um software bem desenvolvido é... + =
  • 13. Funcionalidades 7% 13% 16% 19% 45% Média de uso de funcionalidades de sistemas Sempre Frequentement e Às vezes Standish Group, 2002
  • 14. PROBLEMA: “Nós temos a tendência de NÃO tratar o cliente de software como um cliente que gasta dinheiro.”
  • 15. R$ 500.000,00 Quinhentos mil reais R$ 500.000,00R$ 500.000,00 O Cliente é responsável, mas como dizer isso a ele?
  • 16. Nível de Ruídos em Projetos Simples Anarquia Complexo Perto da certeza Longe da certeza Tecnologia Perto de Acordo Longe de acordo Requerimentos Fonte: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
  • 17. User Stories Applied “Those who want the new software must communicate with those who will build the new software.”
  • 18. O valor dos requisitos é RELATIVO Contexto é importante
  • 20. O Cliente é tratado como Cliente!
  • 21. Desenvolvimento Incremental e Iterativo Pensando um pouco... Requisitos Iteração 1 Iteração 2 Iteração N ... Especific. Desenvolv Testes Produção Isso não é do jeito que eu queria !!!
  • 22. Mas... por quê mesmo precisamos investir em processos?  Ter mais produtividade?  Aumentar a probabilidade de sucesso nos projetos?  Padronização de tarefas frequentes?  “Garantir” a qualidade do software?
  • 24. Martin Fowler "Para muitas pessoas, o surgimento das metodologias ágeis é uma reação às metodologias de engenharia burocráticas. Entretanto, estas "novas" metodologias visam ser uma forma útil entre ter nenhum processo e muito processo, fornecendo processo suficiente para obter um retorno satisfatório."
  • 25. Conceitos Iniciais  Visão de Produto  Evolução  Processo Cognitivo de aprendizado
  • 26. Visão de Produto  Define as fronteiras do projeto deixando bem claro o objetivo macro do produto a ser desenvolvido;  Tem o objetivo de estabelecer um acordoinicial entre os participantes do projeto sobre as funcionalidades que devem ser implementadas;  Ela ajuda a guiar as mudanças que vão ocorrer no projeto para identificar se existem grandes distorções em relação ao que foi acordado inicialmente;
  • 27.
  • 28.
  • 29. Business Model Canvas  Usado para realizar planejamento estratégico e melhorar modelos de negócio (novos ou não);  Mapa que contém 9 (nove) blocos para um modelo de negócio  Criado por Alexander Osterwalder Um Business Model é um mapa dos principais itens que constituem uma empresa. O Mapa é um resumo dos pontos chave de um plano de negócio.
  • 30. Alianças de negócios que contemplam os outros aspectos do modelo de negócio Principais Parceiros Atividades necessárias para executar o Modelo de Negócio Principais Atividades Recursos necessários para criar valor para o cliente Principais Recursos Proposições a serem atendidas. Que necessidades, do público-alvo a que se destina meu negócio, precisam ser atendidas? Proposição de Valor Ligação entre a empresa e seus clientes Relac. com Cliente Meio pelo qual uma empresa fornece produtos e serviços Canais O Público- alvo para os produtos e serviços de uma empresa Segmentos de Clientes A forma como a empresa ganha dinheiro através de uma variedade de fluxos de receita. Fluxos de Receita Consequência monetária dos meios utilizados no modelo de negócio. (Despesas) Estrutura de Custos 1 2 3 4 5 6 78 9
  • 31. Desenhe um modelo de Negócio para um produto de Software utilizando o Business Model Canvas (30 min)
  • 32. O Que é isso?
  • 33. A visão no ajuda a seguir um caminho
  • 34. E se fosse assim?
  • 35. O que você entende por...  Evolução?  Nova fase em que entra uma ideia, um sistema, uma ciência, etc.  Desenvolvimento ou transformação gradual e progressiva (operada nas ideias, etc.).  Aprender com o Tempo  Processo Cognitivo?  Capacidade de aprender e evoluir levando em consideração a atenção, percepção, memória, raciocínio, imaginação, p ensamento, discurso...
  • 36. A comunicação é um dos maiores facilitadores no processo de aprendizagem e evolução.
  • 37. User Stories Applied “Those who want the new software must communicate with those who will build the new software.”
  • 38. Como facilitar a comunicação?  Que tal aplicando/privilegiando o uso de atividades cognitivas, ou seja, fazer com que as pessoas aprendam através da observação, percepção e comunicação?  No que se refere ao desenvolvimento de software, a criação/definição de papéis antes da identificação das funcionalidades é uma grande ajuda;
  • 39. Exemplo Compra de Tickets para a Copa 2014  Defina uma visão para um sistema de compra de Tickets para a copa de 2014.  Obs: Lembre-se que a visão é uma frase que sinalize o objetivo macro a que o sistema pretende alcançar.  Qual o problema?  O que pretende-se fazer?  Quem Será beneficiado?  Que papéis você consegue identificar?  Que requisitos poderiam ser identificados para tal sistema? 15 min
  • 40. Como descrever uma Visão Para (cliente alvo) Que (declaração da necessidade ou oportunidade) O [nome do produto] é um [estratégia do produto] Que (benefícios, boa razão para comprar) Diferentemente (outras opções de produto) Nosso produto (diferenças-chave)
  • 41. User Stories  O que é uma User Story  Estrutura de uma User Story  Escrevento User Stories  Estórias devem ser INVEST  Personas  Epicos, Temas  Release Planning Mike Cohn Authorized Hi Paulo-- I'm glad you've enjoyed those books. Many others teach classes based on those materials and doing so is perfectly fine. Please note that I do own the copyright on the titles of those courses so you'll need to call your classes something slightly different. Thank you for including references to my work. Good luck with your classes. Regards, Mike
  • 43. O que é uma User Story?  Descreve um requisito que é valiosopara um usuário ou comprador de um sistema de software;  Estórias levam em consideração 3 aspectos:  Uma descrição escrita da estória para servir como lembrete da funcionalidade;  Conversações sobre as estórias para confirmar os detalhes escritos na descrição;  Testes que podem ser usados para determinar quando uma estória está completa;
  • 44. Estrutura de uma User Story Como um <PAPEL> eu posso/gostaria/devo <FUNÇÃO> para <VALOR DE NEGÓCIO>
  • 45. Pagamento via Cartão de Crédito Como um cliente, Eu gostaria de pagar usando meu cartão de crédito para poder parcelar minhas compras. Observações: - Aceitar Master Card, Visa e Amex Restrições: - Parcelar, no máximo, em 10x - Cliente não pode estar no SPC
  • 46. Pagamento via Cartão de Crédito Critérios de Aceitação - Teste com MC, Visa e Amex válidos deve passar - Compra com outros cartões válidos não pode passar - Compra com cartões expirados não deve passar - Teste com CEP inválido deve bloquear pgto - Teste com CEP inválido deve bloquear pgto Verso
  • 47.  Converta as funcionalidades que foram encontradas no sistema de compra de tickets para a Copa de 2014 em User Stories usando a seguinte regra: 15 min Como um <PAPEL> eu posso/gostaria/devo <FUNÇÃO> para <VALOR DE NEGÓCIO> Exemplo Compra de Tickets para a Copa 2014
  • 48. Estórias devem ser... I N V E S T ndepent egociable aluable stimable mall estable Sempre que possível, preocupe-se em evitar criação de dependências entre as estórias Estórias são negociáveis. Elas não são contratos requisitos que um software deve implementar. As estórias devem ter um valor visível para quem está comprando/pagando pelo produto Os desenvolvedores devem ter condições suficientes para estimar uma estória Uma estória muito grande é difícil de estimar complexa de desenvolver As estórias devem ser testáveis
  • 49.  Dependência entre estórias levam a problemas na priorização e na estimativa;  Por exemplo: O cliente selecionou uma estória de alta prioridade que tem uma outra estória de baixa prioridade como dependente;  Outros exemplo:  Suponha que você tenha uma loja virtual e possui as seguintes estórias no seu backlog: 1. O cliente pode pagar usando cartão VISA; 2. O cliente pode pagar usando cartão MasterCard; 3. O cliente pode pagar usando cartão America Express;  Os desenvolvedores estimaram que a implementação do primeiro cartão demoraria 3 dias; I ndepent
  • 50.  Cartões de estórias são descrições pequenas da funcionalidade, bem como alguns detalhes que precisam ser negociados em conversa entre desenvolvedores e cliente;  Exemplo: N egociable O cliente pode efetuar pagamento com cartão de crédito Nota: Aceitar VISA, MarterCard e America Express
  • 51.  Tenha em mente a diferença entre usuário (alguém que usa o software) e comprador (alguém que compra o software)  Muitos projetos possuem estórias que não são valiosas para os usuários;  Ex: Toda a informação de configuração deve ser lida de um servidor central;  Evite estórias que aparentam ter valor apenas para os desenvolvedores: V aluable Todos os erros e controle de log devem ser tratados por um conjunto comum de classes Todos os erros devem ser apresentados aos usuários de uma maneira consistente
  • 52.  É importante que os desenvolvedores sintam-se aptos a estimar a estória (pelo menos um “chute”)  Existem pelo menos 3 razões que levam uma estória a não ser estimada  O time não conhece o domínio de negócio;  Uma conversa é necessária com o cliente para sanar dúvidas. Vale salientar que não é preciso entrar em detalhes de implementação, mas os desenvolvedores precisam ter uma ideia do que vão fazer;  O time não conhece a tecnologia a ser utilizada;  Tarefas “spike” podem ser criadas para pesquisar a tecnologia;  A estória é muito grande para ser estimada;  Neste caso, é importante que a estória seja “quebrada” em outras estórias até que os desenvolvedores se sintam à vontade para dar um chute; E stimable
  • 53.  O tamanho da estória é muito importante, pois as estórias podem atrapalhar um planejamento caso sejam grande ou pequenas demais;  Um grande indício para saber se a estória está em um tamanho razoável é observar o time, suas capacidades e a tecnologia em uso;  Estórias grandes são muito difíceis de serem priorizadas;  Uma dica é definir fronteiras nas estivativas. Por exemplo: Se você usa Planning Poker, pode definir que uma estória ½ é muito pequena e uma estória acima de 13 é muito grande; ½ - 1 – 2 – 3 – 5 – 8 – 13 – 21 – 34 ... S mall
  • 54.  Estórias devem ser escritas de forma que possam ser testadas;  Se uma estória não pode ser testada, como os desenvolvedores podem saber quando terminaram?  É comum estórias que implementam requisitos “não funcionais” sejam escritas de forma que não podem ser testadas:  Ex: “O usuário não deve esperar muito para a tela de cadastro aparecer”  O melhor seria escrevê-la assim:  “A tela de cadastro deve aparecer em menos de 2 segundos em 95% dos casos” T estable
  • 55.
  • 56. Épico Épico Gerenciamento de Emails Gerenciamento de Contatos Estórias com uma estimativa (Story Points) alta Ex: Estórias com um tamanho 21, 34, ... TEMA
  • 57. Épico vs Tema Épico História História História História História História História História História Tema História História História História História História História História
  • 58. Estórias mal escritas!  Quais os sintomas para saber se uma estória:  É pequena demais  É Interdependente  É Goldplating  Possui muitos detalhes  Difícil de ser priorizada
  • 59. Estória Pequena demais  Sintoma:  Necessidade frequente de revisar as estimativas  Discussão:  Esse problema ocorre quando uma história influencia nas estimativas caso a ordem de implementação seja alterada
  • 60. Estória Interdependente  Sintoma:  Dificuldade de planejar as iterações devido às dependências entre as estórias  Discussão:  Acontece quando uma estória que deve entrar na próxima iteração precisa de uma outra estória que, por sua vez, precisa de uma terceira e que, por sua vez...  Estória pequenas demais ou mal “quebradas” fazem com que esse tipo de problema venha a ocorrer
  • 61. Estórias Goldplating  Sintoma:  Desenvolvedores adicionam funcionalidades que não foram planejadas e acabam implementando mais que o necessário  Discussão:  Goldplating referem-se a funcionalidades adicionais e desnecessárias  Razões  Desenvolvedores querem agradar o cliente  Desenvolvedores querem fugir da pressão da iteração e fazer outras atividades  Desenvolvedores gostam de “colocar sua marca” no projeto
  • 62. Estória muito detalhada  Sintoma:  Gasta-se muito mais tempo escrevendo os detalhes da estória que falando sobre ela  Discussão:  Uma das vantagens em se utilizar cartões para escrever estórias é que eles são limitados;  Colocar muitos detalhes em uma história indica que a documentação está sobrepondo a comunicação;  “Se você ficar sem espaço em um cartão, use um cartão menor” (Tom Poppendieck)
  • 63. Estória difícil de ser priorizada  Sintoma:  O cliente sente muita dificuldade de priorizar diversas estórias  Discussão:  A primeira coisa a considerar é o tamanho das estórias. Se elas são muito grandes, é muito difícil priorizá-las;  O seu valor de negócio não está claro.
  • 65. Perfis de usuário (User Roles)  Por que é importante definir diferentes perfis de usuário?  Você acha que, para um mesmo perfil de usuário (ex: Professor, em um sistema acadêmico) temos características diferentes?  Cite alguns exemplos de aplicações com uma vasta gama de usuários;
  • 66. Passos para criação de Perfis de Usuário  Fazer um brainstorm para identificar o conjunto de perfis iniciais  Organizar o conjunto de perfis inicial;  Consolidar os perfis;  Refinar os perfis;
  • 68. Personas  A criação de personas é uma técnica utilizada para especificar usuários com um determinado perfil;  Esta técnicas personaliza o software, fazendo com que pessoas de perfis diferentes fiquem satisfeitas com o produto;
  • 69. Exemplo de Persona Teovaldo é professor de História com mais de 20 anos de experiência. Sempre fez todas as suas atividades de forma manual e, apesar de não gostar de computadores, fica fascinado com a possibilidade de ganhar tempo com tarefas automatizadas por ferramentas de software.
  • 70. Mapeamento de User Stories  Definindo o Backbone
  • 71. Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/)
  • 72. Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/) BENEFÍCIOS OU SERVIÇOS OFERECIDOS FUNCIONALIDADES DO SOFTWARE DETALHAMENTO DAS FUNCIONALIDADES BACKBONE ESQUELETO DA APLICAÇÃO
  • 73. O MAPA  Backbone:  Lista de atividades essenciais que dão suporte à aplicação  Benefícios do produto  Esqueleto  É o software em construção que atende a um número mínimo de tarefas necessárias para abranger a todo o ciclo de atividades do usuário
  • 74. Fonte: Carlos Crosetti (http://carlos-crosetti.blogspot.com.br/) T E M P O IMPORTÂNCIA MAIS IMPORTANTES OU ESSENCIAIS MENOS IMPORTANTES OU DESCARTÁVEIS
  • 76. Mapeamento de User Stories Home Page Hot jobs ads Job hunting tips Post Resume Resume data fields Employer Entrance Account Info Search Jobs Search fields Review Applicants List of applicants Post Jobs Job description fields Resume View All resume data Job Results List of matching jobs Job Details All job information
  • 77. Estórias identificadas para o site de empregos  Uma pessoa pode publicar seu currículo  Um empregador pode publicar vagas de trabalho  Um empregador pode revisar currículos submetidos  Uma pessoa pode procurar por empregos  Uma pessoa pode visualizar resultados de empregos de uma pesquisa  Uma pessoa pode visualizar detalhes sobre empregos específicos
  • 78.  É interessante criar protótipos de baixa fidelidade para ajudar a entender as necessidades do usuário  Algumas perguntas que podem ser feitas para ajudar a identificar estórias “escondidas”:  O que o usuário gostaria fazer em seguida?  Que erros o usuário poderia cometer aqui?  O que poderia confundir o usuário neste momento?  Que informações adicionais seriam interessantes para o usuário?  Pense em perfis de usuário e Personas enquanto faz estas perguntas Mapeamento de User Stories Dicas
  • 79. Priorização  Dinâmica do Backlog  Técnica MoSCoW  Técnica Kano
  • 81. A priorização  Como objetivo de lançar uma release do produto, o cliente precisa priorizar as estorias;  Existe uma técnica descrita no DSDM (Dynamic Systems Development Method) que pode ser usada para facilitar o processo de priorizacão;  Esta técnica pode ser encontrada no livro Business Focused Development;  Esta técnica recebe o nome de MoSCow;
  • 82. Priorização MoSCoW Must Have (Deve ter) Funcionalidades fundamentais para o sistema. Sem estas funcionalidades o sistema não tem valor para o cliente Should Have (Deveria ter) Funcionalidades importantes, ma s existem alternativas a curto prazo para elas Could Have (Poderia ter) Funcionalidades que podem ser “deixadas de lado” caso o tempo do projeto esteja muito escasso Won’t have (Não terá) Funcionalidades que não serão feitas ou não serão entregues na release planejada
  • 83. # Item BV %BV Size ROI %ROI 1 F1 1000 20% 13 76,92 7% 2 F2 500 10% 8 62,50 6% 3 F3 600 12% 5 120,00 11% 4 F4 400 8% 21 19,05 2% 5 F5 800 16% 3 266,67 24% 6 F6 500 10% 5 100,00 9% 7 F7 900 18% 5 180,00 16% 8 F8 300 6% 1 300,00 27% TOTAL 5000 61
  • 85. Priorização KANO  É uma das técnicas de priorização mais utilizadas  Realizar perguntas direcionadas para um grupos de usuários  Você deve realizar uma pergunta funcional:  Como você se sentirá se o requisito estiver presente no produto?  Você deve realizar uma pergunta disfuncional:  Como você se sentirá se o requisito NÃO estiver presente no produto?  Feito isso, você deve combinar as respostas e colher as informações
  • 86. Kano: Exemplo  Termômetro de temperatura em uma cerveja em lata  Pergunta Funcional: Como você se sentirá ao ver um termômetro de temperatura na latinha de cerveja?  Pergunta Disfuncional : Como você se sentirá em não ver um termômetro de temperatura na latinha de cerveja?
  • 88. Kano: Exemplo  Pergunta Funcional: Como você se sentirá ao ver um termômetro de temperatura na latinha de cerveja? ( ) Me Agradaria ( ) Quero que tenha ( ) Tanto faz ( ) Não Gostaria  Pergunta Disfuncional: Como você se sentirá a NÃO ver um termômetro de temperatura na latinha de cerveja? ( ) Me Agradaria, desejo ( ) Quero que tenha, espero imagino ( ) Tanto faz, posso conviver sem isso ( ) Não Gostaria X X
  • 89. Kano: Resultado  Após efetuar o questionário a um grupo de 20 usuários, você deve checar a resposta funcional e não funcional de cada um deles e chegar a um valor da tabela.  No exemplo anterior:  Pergunta Funcional: Como você se sentirá ao ver um termômetro de temperatura na latinha de cerveja? (Resposta: Me agradaria)  Pergunta Disfuncional: Como você se sentirá a NÂO ver um termômetro de temperatura na latinha de cerveja? (Resposta: Tanto faz)  Dessa forma, para este usuário, o valor obtido com o cruzamento da informações foi Atrativo (A)
  • 92. Protótipo Do latim, proto ORIGINAL e tipo MODELO. Um tipo, forma ou exemplar original que serve como base ou padrão para futuros estágios de um projeto ou simplesmente: um exemplar inicial que comunica uma idéia.
  • 93. Prototipação  Processo iterativo, para a criação de protótipos que serve para rapidamente testar conceitos, produtos e negócios e trazer respostas a uma pergunta.
  • 94. Dica... Quanto mais cedo erramos, mais cedo temos sucesso
  • 95. Comunicação Visual Visão Imagem  A comunicação visual é rápida, eficiente e simples.  Como fazer isso  Sketch (esboço)  Protótipo
  • 98. Como nascem algumas aplicações...
  • 101. Mapeamento de User Stories Home Page Hot jobs ads Job hunting tips Post Resume Resume data fields Employer Entrance Account Info Search Jobs Search fields Review Applicants List of applicants Post Jobs Job description fields Resume View All resume data Job Results List of matching jobs Job Details All job information
  • 102. Técnica: Mapa mental Diagrama usado para representar palavras, ideias, tarefas e outros itens ligados e dispostos ao redor de uma palavra ou ideia central.
  • 104. Mapas mentais são bons para...  Visualizar ideias  Relacionamentos entre elementos  Brainstorming, Ideação  Tomar decisões a partir de anotações  Quebrar problemas em pedaços  Organizar a mente
  • 105. Fonte: Paolo Passeri – Técnicas de Prototipação
  • 107. Melhores Práticas 1. Stakeholders actively participate 2. Adopt inclusive models 3. Model storm details just in time (JIT) 4. Treat requirements like a prioritized stack 5. Prefer executable requirements over static documentation 6. Your goal is to implement requirements, not document them 7. Recognize that you have a wide range of stakeholders 8. Smaller is better 9. Question traceability 10. Explain the techniques 11. Adopt stakeholder terminology 12. Keep it fun 13. Obtain management support 14. Turn stakeholders into developers