1. Prof. Msc. Paulo Furtado
paulofurtado.ti@gmail.com
@paulofurtadoti
2013

2. Apresentações
 Professor
 Turma
 Disciplina
2

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

5. Bibliografia

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

8. Palavras-Chave

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

19. Escolha um cenário...
+
+
=
=
?
?

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?

23. Jim Highsmith
Agile Consultant

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;

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

42. ard
onversation
onfirmation

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

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.

64. Personas

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;

67. Atores
Cadastrar
Clientes
Ator Iteração Caso de Uso

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

75. Mapeamento de User Stories

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

80. A
B
C
F
G
H
I
D
Prioridade
Alta
Baixa
E
Estórias
Relembrando a Dinâmica
do Product Backlog

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

84. Ruído em Projetos

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?

87. Kano: Exemplo

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)

90. Prototipação
 Sketch
 Mapas Mentais

91. Bibliografia
95

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

96. Técnica: SKETCH (esboço)

97. Sketch – características

98. Como nascem algumas aplicações...

99. Ferramentas para Sketch

100. Ferramentas para Sketch

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.

103. Mapa Mental

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

106. Dicas
 Melhores
práticas

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

108. Obrigado!
Prof. Paulo Furtado
paulofurtado.ti@gmail.com
@paulofurtadoti