Histórias de Usuário: Escrevendo Requisitos que Geram Valor

As atividades de ler e escrever documentações de software dificilmente entram na lista das tarefas mais empolgantes do dia a dia.
Documentação técnica, quase que por natureza, tende a ser bastante engessada — repleta de jargões, termos específicos e estruturas que nem sempre conversam com quem realmente vai usar o sistema. Curiosamente, toda essa formalidade deveria servir justamente para trazer fluidez e clareza ao processo, o que, pela minha experiência, está longe de ser uma realidade.

No extremo oposto disso, surgiu um movimento curioso. Um grupo de pessoas — sabe-se lá por que — entendeu que o valor ágil “indivíduos e interações acima de processos e ferramentas” significava algo como: “documentação é irrelevante, vamos demitir os analistas de requisitos.”
Até hoje não entendi bem de onde saiu essa interpretação… mas ela ganhou força em alguns cantos do globo.

E então, eis que, eentre a rigidez excessiva da documentação tradicional e o “vale-tudo” do anti-documentacionismo, surgiram as Histórias de Usuário: uma forma mais leve, acessível e funcional de registrar requisitos — sem abrir mão do entendimento, da clareza e, principalmente, do valor para quem usa o produto.

1. De Onde Vieram as Histórias de Usuário?

A ideia surgiu lá no início das metodologias ágeis, com o Extreme Programming (XP) — que você talvez conheça como um dos precursores do movimento ágil, mas essa história já foi contada em inúmeros lugares de forma muito mais eloquente do que eu contaria, então vou me ater a parte prática da coisa.

Na época, a proposta era simples e poderosa: em vez de deixar só os analistas definirem o que seria feito, os próprios clientes passariam a descrever o que precisavam, por meio de histórias curtas e objetivas. Algo como:

Com o tempo, as Histórias de Usuário evoluíram. Ganharam estrutura, propósito e se distanciaram da formalidade dos casos de uso, tornando-se um dos pilares da documentação em projetos ágeis.

2. Afinal, o Que É uma História de Usuário?

A História de Usuário é um artefato de requisitos — assim como o caso de uso — mas com uma diferença essencial: ela é simples, informal e centrada no usuário.

Outro detalhe importante, especialmente para o nosso contexto: enquanto o caso de uso foca no comportamento do sistema (o que ele faz, como reage, o que acontece em cada etapa), a história de usuário foca no usuário, em sua intenção, na ação que deseja realizar e no valor que espera receber como resultado da ação.

O comportamento interno do sistema? Ele importa, claro. Mas só até a página dois. A história de usuário não está preocupada com o que acontece “por trás das cortinas” — ela quer mostrar o que realmente interessa para o usuário: o resultado prático.

Ou seja, enquanto o caso de uso pergunta “Como o sistema deve se comportar?”, a história de usuário pergunta “O que o usuário quer fazer — e por quê isso importa pra ele?”

3. Como Elaborar uma História de Usuário?

Tem várias formas de escrever, mas todas seguem mais ou menos a mesma lógica. Listei abaixo alguns exemplos que costuam ser utilizados:

• Modelo clássico (Connextra, 2001):
  “Como um <papel>, eu quero <meta> de modo que <benefício>.”
• Mike Cohn (versão simplificada):
  “Como um <papel>, eu quero <meta>.”
• Chris Matts (injeção de funcionalidade):
  “A fim de <benefício>, como um <papel>, eu quero <meta>.”
• Modelo baseado no Five Ws (quem/quando/onde/o quê/por quê):
  “Como <quem>, <quando>, <onde>, eu <o quê>, porque <por quê>.”

Contudo, noto que o formato mais comum hoje em dia é esse aqui:

“Como um [papel], eu quero [ação/desejo], a fim de [benefício].”

Ou uma pequena variação, como está outra:

“Eu, como [papel], desejo [ação], a fim de [benefício].”

No fim das contas, o modelo exato não importa tanto. O que vale é que ele faça sentido pra equipe, seja legível, compreensível e compreendida por todos, que esclareça fortemente a necessidade do usuário.

O foco SEMPRE será a clareza e a comunicação, e essa é justamente a diferença entre seguir regras burocráticas.

4. Um Exemplo Rápido (E esportivo)

Como um vendedor
Eu quero cadastrar um cliente
A fim de incluí-lo no programa de fidelidade

Vamos destrinchar?

• Ator: vendedor
• Objetivo: cadastrar um cliente
• Benefício esperado: incluí-lo no programa de fidelidade

Percebe como a história é extremamente simples e direta? Ela apresenta uma ação real do dia-a-dia, com um propósito claro e bem definido. E o mais importante: qualquer pessoa da equipe — técnica ou não — consegue entender.

No exemplo anterior, o “a fim de” até poderia ser opcional. Mas aqui, acho que faz sentido mantê-lo, porque o valor da ação não é tão óbvio assim — e esse detalhe importa. Dizer apenas “quero cadastrar um cliente” pode levantar dúvidas: para quê? Com que objetivo? O “a fim de incluí-lo no programa de fidelidade” fecha a ideia com clareza.

Agora, se o benefício estiver implícito na ação, você pode tranquilamente omitir essa parte — sem peso na consciência. Afinal, a ideia não é engessar. Ficaria algo assim:

Como um vendedor
Eu quero cadastrar um cliente para que seja incluído no programa de fidelidade

O segredo não está em seguir o template ao pé da letra, mas sim em garantir que a história comunique claramente o que o usuário quer fazer e por que isso importa.

Pronto. Uma história simples, clara e completa. Aqui, a gente:

• Identificou quem é o ator (vendedor)
• Entendeu o que ele quer fazer (cadastrar o cliente)
• E por quê (para incluí-lo no programa de fidelidade)

Tudo isso em uma frase que qualquer pessoa entende — até quem nunca viu uma linha de código.

---

Para Fechar…

Histórias de Usuário são uma forma super eficiente de aproximar a equipe de desenvolvimento do mundo real dos usuários. Elas ajudam a tirar os requisitos do papel de forma leve, rápida e com foco no que realmente importa: a experiência de quem vai usar o produto.

Então, da próxima vez que alguém sugerir começar um projeto com casos de uso gigantes e formais… talvez valha a pena perguntar:
“E se a gente começasse com uma boa história?”