Ebook 5 maneiras de descrever requisitos de software

Prévia do material em texto

MANEIRAS DE 
DESCREVER 
REQUISITOS DE 
SOFTWARE
As a____ 
I want___ 
So that__ 
www.leandrobodo.com
Porque nem tudo são User Stories
5
http://www.leandrobodo.com
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 2
A P R E S E N T A Ç Ã O 
Se você é um Gerente de Produto, Gerente de Projeto ou Dono de Produto (Product 
Owner), trabalha em um ambiente ágil, e está à procura de alternativas para 
descrever requisitos de produto/projeto, ou está apenas interessado em saber o que 
as empresas de software do exterior estão utilizando para levantamento de 
requisitos, este E-book é para você.
“Meu nome é Leandro Bodo, trabalho com transformação 
digital há quase 10 anos, entregando soluções de software 
‘people-centred' para uma gama de empresas como 
Coca-Cola, Unilever, GSK, Smithers e Forest England. 
Atualmente, atuo como Senior Technical Product Owner 
em uma agência digital na Inglaterra” 
Neste E-book, apresentarei versões em português e inglês dos templates que eu 
tenho usado no dia-a-dia para descrever requisitos de software e facilitar a 
conversa com o time, bem como a negociação com os clientes / Product Owners 
(Donos do Produto). 
Abordarei também as principais aplicações e os fatores mais importantes de cada 
um dos modelos, que incluem:
• User Story
• Improvement Story 
• Job Story
• Technical Story 
• Use Case
• Bug (Extra)

Obviamente que esses modelos não são as únicas maneiras de se descrever um 
requisito de software, porém eles têm se mostrado alternativas bastante viáveis nos 
meus projetos e produtos e tenho certeza que também TE AJUDARÃO na geração 
e manutenção de seu backlog.
Enjoy!
www.leandrobodo.com
 
@leboldy
 
Leandro Bodo
 
Leandro Bodo
 
@le_boldy
 
fb.com/leboldy
http://instagram.com/leboldy/
http://twitter.com/le_boldy
https://www.linkedin.com/in/lebodo
http://youtube.com/leandro-bodo
http://fb.com/leboldy
http://instagram.com/leboldy/
http://twitter.com/le_boldy
http://fb.com/leboldy
https://www.linkedin.com/in/lebodo
http://youtube.com/leandro-bodo
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 3
User Story 
Se você trabalha em um ambiente ágil, você certamente deve conhecer este, que é 
o mais popular de todos, o famoso “User Story” ou “História de Usuário”.
História de usuário é um jeito bastante simples e eficiente de representar um 
requisito de software ou descrever uma funcionalidade, pois foca na linguagem de 
negócio e não se preocupa em detalhar a parte técnica, muito menos em tentar 
descrever o “como" uma funcionalidade será implementada.
Sua principal característica é representar um requisito de software sob a 
perspectiva do usuário final, incluindo os diferentes tipos de usuários e focando no 
resultado que este usuário está tentando atingir, bem como no valor que aquilo trará 
àquele usuário.
APLICAÇÃO 
Histórias de usuário são mais indicadas quando o usuário ou tipo de usuário é o 
foco central da ação e geralmente ocorrem em situações onde deseja-se criar algo 
novo, novos requisitos ou novas funcionalidades de software.
FORMATO 
User Stories seguem basicamente o formato abaixo.
Formato em Inglês: 
Formato em Português: 
Exemplo: 
www.leandrobodo.com
As a <Type of user> 
I want to <Action/Some goal> 
So that <Some Reason/Expected outcome>
Como um <Tipo de usuário> 
Eu quero <Ação/Objetivo> 
Para que <Porque/Resultado esperado>
Como um gerente de marketing 
Eu quero poder comprar um relatório de desempenho mercado 
Para que eu possa ler seu conteúdo e entender o comportamento dessas 
empresas no mercado em que atuam
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 4
As histórias de usuário são excelentes alternativas para facilitar a conversa entre o 
Product Owner (Dono do produto) e o time, permitindo que o foco dessa conversa 
seja no resultado e no valor que uma determinada funcionalidade trará ao usuário 
final, ao invés de no ‘como’ uma funcionalidade será implementada tecnicamente.
Improvement Story 
Você já esteve em uma situação em que achou que história de usuário era “too 
much”, era um “exagero” para aquela pequena melhoria que precisava ser 
implementada? Pois é, você não é o único! Todos nós já passamos por isso, mas 
fique tranquilo que as Improvement Stories vão te ajudar nessa missão.
Improvement Stories, ou “histórias para melhoria”, são alternativas bastante 
interessantes às histórias de usuário e funcionam muito bem em situações em que 
deseja-se melhorar uma funcionalidade existente, desde que essa melhoria seja 
relativamente pequena e bastante óbvia, pois focam na solução daquela situação.
APLICAÇÃO 
As Improvement Stories são recomendas em produtos de software mais “maduros”, 
bem depois da entrega do MVP (Minimum Viable Product - Produto Minimamente 
Viável), geralmente em suporte ou BAU (Business as Usual).
FORMATO 
Elas seguem basicamente o formato descrito abaixo.
Formato em Inglês: 
Formato em Português: 
Exemplo: 
www.leandrobodo.com
Nós temos <Situação do momento>, 
Nós queremos ter <Situação desejada>,
Para que <Porque/Resultado esperado>
Atualmente, nós temos o ícone de informação aparecendo apenas quando se 
passa o mouse sobre o ícone, nós queremos que o ícone esteja visível todo 
o tempo, para que seja mais fácil encontrá-lo.
We have <Current situation>, 
We want to have <Desired situation>,
So that <Some Reason/Expected outcome>
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 5
As Improvement Stories são rápidas de se criar e bem fáceis de ser entendidas, o 
que ajuda a facilitar o entendimento do time, e, ao mesmo tempo, evita que o 
Product Owner (Dono do Produto) se esforce escrevendo User Stories mais 
completas, que não adicionariam muito valor nestes casos específicos, já que não 
há muita margem para negociação, nestes casos.
DICA EXTRA 
Improvement Stories também podem ser utilizadas em situações que não se 
têm certeza se algo é bug, evitando todo aquela discussão se “é bug ou não”. 
Afinal é mais importante que o time resolva aquela situação ou implemente 
aquela funcionalidade o mais rápido possível, do que perca tempo discutindo 
ou tentando achar um culpado.
Job Story 
Se você já criou um backlog de produto bastante extenso usando a tradicional 
história de usuário [“Como um <tipo de usuário>, etc”], você certamente já se 
deparou com a situação em que o usuário não era tão relevante quanto a ação [“Eu 
quero…”], e que se talvez você tivesse substituído o “Como um consumidor” por 
“Como um usuário”, não teria feito nenhuma diferença significativa para o 
entendimento daquela história. 
Pois bem, se você estiver em uma situação em que você se sinta meio que 
‘obrigado’ a identificar um tipo de usuário só porque faz parte do template, ou a 
definir um usuário ‘genérico’ só pra não deixar o “Como um….” sem preencher, 
talvez você deva tentar substituir essa história de usuário por Job Story. 
As Job Stories são uma alternativa interessante às User Stories, principalmente 
quando se precisa focar mais na situação que será o gatilho daquela ação, do que 
no tipo de usuário que quer algo. Isso, obviamente, pode variar de item pra item, a 
depender da necessidade, podendo resultar em um product backlog misto, com 
histórias de usuário E Job Stories no mesmo backlog, sem problemas.
APLICAÇÃO 
Job Stories são indicadas em situações em que é difícil conseguir identificar um 
usuário específico, ou ainda em cenários em que a situação é mais relevante do que 
o usuário que irá executar aquela ação.
www.leandrobodo.com
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 6
FORMATO 
As Job Stories seguem basicamente o formato abaixo.
Formato em Inglês: 
Formato em Português: 
Exemplo: 
As Job Stories são uma alternativa bastante interessante em empresas que 
trabalham no modelo cascata (waterfall), e que queiram dar o primeiro passo para 
iniciar com a transformaçãodigital, mas que ainda não possuem processos 
maduros o suficiente para se desfazer do documento de requisitos tradicional, por 
exemplo.
Por fim, Job Stories podem também ser eficazes em projetos curtos, onde o tempo 
e o esforço para treinar e tentar convencer os clientes/times dos benefícios das 
histórias de usuário e critérios de aceitação são tão grandes, comparado ao 
tamanho e duração do projeto, que não justifica o esforço.
Technical Story (História Técnica) 
Technical Story talvez seja o modelo mais controverso de todos apresentados neste 
E-book, pois contradiz o princípio da história de usuário que consiste em “contar a 
história de um determinado usuário usando linguagem de negócio - SEM SER 
www.leandrobodo.com
When <Situation> 
I want to <Motivation>  
So I can <Expected outcome>
Quando <Situação> 
Eu quero <Motivação>  
Para que eu possa <Resultado esperado> 
Quando eu comprar uma camisa no tamanho errado no website, 
Eu quero poder fazer a troca do produto online sem a necessidade de ligar 
para a empresa, 
Para que eu possa receber o produto certo e ir a formatura
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 7
TÉCNICA -, focando no objetivo e no resultado/valor esperado”. Porém, como o 
nome sugere, as Technical Stories são mais focadas na parte técnica da 
implementação e são usadas principalmente em “SPIKES”, embora também 
possam ser usadas para identificação de requisitos não funcionais.
De maneira resumida, SPIKE - originado no XP (Extreme Programming) - trata-se de 
um pequeno experimento, semelhante a uma investigação, que permite ao time 
aprender mais sobre uma determinada área da aplicação, geralmente o suficiente 
para poder realizar a estimativa e minimizar os riscos da implementação de uma 
funcionalidade.
APLICAÇÃO 
Technical Stories são recomendadas quando se deseja descrever requisitos 
técnicos, não funcionais e/ou SPIKES.
FORMATO 
Histórias técnicas seguem basicamente o formato abaixo.
Formato em Inglês: 
Formato em Português: 
Exemplo: 
www.leandrobodo.com
In order to <Achieve some goal>, 
<A system or persona> needs to <Some action> 
Expected outcome: <Report on the investigation> or <List of actions that will 
be incorporated in the backlog> 
A fim de OU Para <Atingir um objetivo>, 
<Um sistema ou persona> precisa < 'Fazer' alguma ação> 
Resultado esperado: <Relatório da investigação> OU <Lista de ações que 
serão incorporadas no backlog>
A fim de adicionar o Google carrossel no website, nós precisamos entender 
como API do google carrossel funciona para que possamos entender as 
funcionalidades disponíveis, bem como suas limitações.
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 8
Uma Technical Story nunca deve estar sozinha no backlog do produto. Isso porque, 
não é recomendado implementar uma tarefa técnica, SPIKE, task ou chore 
simplesmente porque alguém interno disse que algo precisa ser feito (e.g. 
desenvolvedor, arquiteto, gerente, etc). Geralmente, elas surgem a partir da 
necessidade de se entregar algo maior ao cliente, e por este motivo é que devem 
sempre estar associadas aos requisitos/desejos originais, como a uma User Story 
por exemplo. Essa associação cria uma relação hierárquica entre a User Story 
original e a Technical Story, como se fosse uma relação de dependência.
A relação de dependência entre uma história de usuário e uma história técnica, 
normalmente ocorre a partir da “quebra” da história de usuário original (“pai”), em 
uma ou mais histórias técnicas (“filhas”). Essa relação pode ocorrer basicamente de 
duas maneiras:
1. A primeira maneira consiste em “quebrar” a história de usuário original (“pai”) 
em uma ou mais histórias “filhas” usando tarefas técnicas (chores ou tasks), 
conforme apresentado na Figura 1.
www.leandrobodo.com
Resultado esperado: saber o que é possível de se ter com a API do Google 
carrossel em termos de estilo (style) e funcionalidades, tendo a resposta para as 
perguntas abaixo: 
• O que é possível de ser customizado no estilo (style) disponível? 
• É possível controlarmos quantos items são exibidos? 
• É possível controlarmos o conteúdo que é disponível? 
• O recurso funciona sem limitações em tablets e celulares? 
• Podemos trazer os reviews do Google dentro do mesmo carrossel que já 
temos para reviews do Facebook?
Configurar 
SMTP
Notificar 
comprador 
por email
Instalar 
licença
Azul = User Story original 
Verde = Technical Story
Figura 1 - Technical Story com tasks (tarefas)
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 9
2. A segunda maneira (e a mais usada) consiste em criar um SPIKE usando 
Technical Story (“filha”), a partir da User Story original (“pai”), conforme 
apresentado na Figura 2.
Essa relação de dependência impede o time de concluir a história original 
enquanto a história “filha” não esteja concluída. Por este motivo, recomenda-se 
separar as iterações, trazendo a Technical Story (SPIKE) em uma Sprint e a User 
Story original para uma Sprint subsequente. Desta forma, o time terá tempo 
suficiente de completar a SPIKE e remover a dependência, antes do início da 
implementação da história original.
Use Case (Caso de Uso) 
Use Cases ou Casos de Uso descrevem uma sequência de ações que permitirão a 
um ator atingir um ou mais objetivos. Geralmente, eles estão relacionados a um 
processo bem definido e basicamente descrevem de uma maneira bem estruturada, 
as interações entre o sistema que será construído e seus atores, que pode ser uma 
pessoa, um sub-sistema ou um dispositivo físico que interage com esse sistema.
APLICAÇÃO 
Casos de uso podem ser usados em projetos onde seja necessário documentar 
todos os requisitos de uma vez e em bastante detalhe. Uma aplicação interessante 
de Use Cases fora do âmbito de requisitos é para a identificação dos principais 
cenários e fluxos para teste de carga (Load testing). 
www.leandrobodo.com
Google 
review 
carrossel
Investigar 
API do 
Google
Google 
review 
carrossel
(Implementação)
Figura 2 - Technical Story com SPIKES
Azul = User Story original 
Verde = Technical Story
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 10
FORMATO 
A estrutura básica de Caso de Uso segue esse formato.
Formato em Inglês: 
Formato em Português: 
Exemplo: 
www.leandrobodo.com
Goal <What the actor wants to achieve> 
Pre-conditions <What must be true before the use case starts> 
Primary Actor <Users, roles, types of actors> 
Main success scenario <Describes the steps in successful use case> 
Post-conditions <What are true after the use case successfully finishes>
Objetivo <O que o ator quer atingir> 
Pré-condições <Condições que devem ser verdade antes to caso de uso iniciar> 
Ator primário <Usuários, papéis, tipos de usuários> 
Cenário principal de sucesso <Descreve o passo-a-passo de um caso de 
uso de sucesso> 
Pós-condições <Condições que são verdades após um caso de uso encerrar 
com sucesso>
Objetivo: comprar ingresso para show sem cadastro 
Pré-condições 
Página do evento publicada 
Ingresso disponível para compras 
Comprador sem cadastro no sistema 
Ator primário: comprador 
Principal cenário de sucesso 
1. Comprador vai na página do evento 
2. Comprador clica em comprar ingresso 
3. Comprador seleciona opção de comprar sem cadastro 
4. O sistema calcula o preço 
5. Comprador clica em pagar com cartão 
6. Comprador insere dados do cartão 
7. Comprador insere endereço de cobrança 
8. Comprador clica em finalizar 
9. O sistema valida os dados do cartão e endereço de cobrança 
10.O sistema exibe um resumo da ordem de compra 
Pós condições 
1. A ordem será salva no sistema 
2. O comprador terá um código de rastreamento único para a ordem 
de compra
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 11
Existem variações desse modelo básico de caso de uso acima apresentado, que 
incluem coisas como: o nível e oescopo do caso de uso, assim como qualquer 
fluxo alternativo, qualquer extensão e pós-condição. Na prática, essa complexidade 
e detalhamento vão variar de caso a caso, dependendo da situação e necessidade.
Bugs 
Não é objetivo deste E-book entrar mérito do que é bug, defeito, falha ou erro. 
Porém, discutiremos um modelo genérico o bastante para poder ser utilizado em 
praticamente todas essas situações, e que tem se demonstrado bastante eficaz na 
identificação e reprodução de problemas deste gênero. 
APLICAÇÃO 
Este template pode ser utilizado para identificação, reprodução e resolução de 
bugs, defeitos, falhas ou erros de software.
FORMATO 
O modelo genérico para ‘bugs’ segue este formato.
Formato em Inglês: 
Formato em Português: 
www.leandrobodo.com
Title <Short description of the issue> 
Repro-step <How to reproduce the issue - steps by step> 
1. Step 1 
2. Step 2 
3. … 
Expected behaviour <Expected/correct output> 
Actual behaviour <Actual output>
Título <Breve descrição do problema> 
Passo-a-passo <Passo-a-passo de como reproduzir o problema> 
1. Passo 1 
2. Passo 2 
3. … 
Comportamento esperado <Saída esperada/correta> 
Comportamento atual <Saída atual>
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 12
Exemplo: 
Este modelo é bastante simples e muito poderoso, pois reune o mínimo de 
informação necessária para que seja possível realizar uma investigação eficaz, 
evitando que o time perca tempo buscando/perguntando por informações faltantes. 
DICA EXTRA 
Caso queira aumentar ainda mais a chance do seu time resolver um bug, 
defeito, falha ou erro sem precisar perder tempo procurando por informação 
faltante, adicione ao modelo os items complementares abaixo apresentados. 
Formato em Inglês (Items complementares): 
Formato em Português (Items complementares): 
www.leandrobodo.com
Título: Cliente não consegue excluir nenhum produto do carrinho de compras 
Passo-a-passo 
1. Vá para a página do produto 
2. Adicione um produto no carrinho 
3. Vá para o carrinho 
4. Clicando no botão de deletar deveria remover o item 
Comportamento esperado: Item excluído do carrinho 
Comportamento atual: Sistema não está excluindo produto do carrinho
URL <Link to the page where the issue was found> 
Environment <Environment where the issue was found-e.g. Dev/QA/STG/PRD> 
Screenshot <Evidences/photos of the error message or any relevante info> 
Browser version <Current version on the device where the issue was found> 
Device <Type of device - e.g. laptop, tablet, mobile> 
User type <Type of user - e.g. vendor, admin, visitor> 
Comment <Any relevant comment>
URL <Link para a página onde o problema foi encontrado> 
Ambiente <Ambiente onde o problema foi encontrado - ex. Dev/QA/STG/PRD> 
Screenshot <Evidências/fotos/mensagens de erro ou qualquer fato relevante> 
Versão do navegador <Versão vigente do dispositivo onde problema ocorreu> 
Dispositivo <Tipo de dispositivo - ex. computador, tablet, celular> 
Tipo de usuário <Tipo de usuário - ex. vendedor, admin, visitante> 
Comentário <Qualquer comentário relevante>
http://www.leandrobodo.com
5 MANEIRAS DE DESCREVER REQUISITOS DE SOFTWARE PAG 13
Formato completo em Português (com items complementares): 
A adição dos items complementares pode até não parecer muito significativa, mas 
certamente é o suficiente para fazer a diferença no time, pois ajuda a evitar perda 
de tempo tentando adivinhar coisas como: o dispositivo que o usuário estava 
usando, ou se isso aconteceu no IE or Mozila, ou ainda se foi num ambiente de 
teste ou em produção. 
Material Auxiliar 
Para saber mais sobre o assunto, assista o vídeo abaixo e siga-me nas redes sociais.
www.leandrobodo.com
Título <Breve descrição do problema> 
Passo-a-passo <Passo-a-passo de como reproduzir o problema> 
1. Passo 1 
2. Passo 2 
3. … 
Comportamento esperado <Saída esperada/correta> 
Comportamento atual <Saída atual> 
URL <Link para a página onde o problema foi encontrado> 
Ambiente <Ambiente onde o problema foi encontrado - ex. Dev/QA/STG/PRD> 
Screenshot <Evidências/fotos/mensagens de erro ou qualquer fato relevante> 
Versão do navegador <Versão vigente do dispositivo onde problema ocorreu> 
Dispositivo <Tipo de dispositivo - ex. computador, tablet, celular> 
Tipo de usuário <Tipo de usuário - ex. vendedor, admin, visitante> 
Comentário <Qualquer comentário relevante>
 
@leboldy
 
Leandro Bodo
 
Leandro Bodo
 
@le_boldy
 
fb.com/leboldy
https://www.youtube.com/watch?v=_UoSOGsjlts&t=141s
http://fb.com/leboldy
http://twitter.com/le_boldy
http://instagram.com/leboldy/
http://twitter.com/le_boldy
https://www.linkedin.com/in/lebodo
http://youtube.com/leandro-bodo
http://fb.com/leboldy
http://instagram.com/leboldy/
http://youtube.com/leandro-bodo
https://www.linkedin.com/in/lebodo
http://www.leandrobodo.com
https://www.youtube.com/watch?v=_UoSOGsjlts&t=141s
	A P R E S E N T A Ç Ã O
	User Story
	Aplicação
	Formato
	Improvement Story
	Aplicação
	Formato
	Dica extra
	Job Story
	Aplicação
	Formato
	Technical Story (História Técnica)
	Aplicação
	Formato
	Use Case (Caso de Uso)
	Aplicação
	Formato
	Bugs
	Aplicação
	Formato
	Dica extra
	Material Auxiliar