Skip to content
BodhiProtocol

Guia BA

O Negócio Diz Que É Defeito. A Tecnologia Diz Que É Comportamento Esperado.

Os dois lados podem estar falando a verdade. Veja como descobrir qual.

Surya · 14 de agosto de 2026 · 5 min de leitura · 10 práticas

Requisitos

Para Business Analysts presos entre "isso é um defeito" e "isso é comportamento esperado", BAs que querem um jeito repetível de classificar um comportamento de sistema em disputa, QA e desenvolvedores decidindo se algo é um bug ou uma especificação e Líderes de entrega que querem discordâncias resolvidas com evidência, não opinião.

Um usuário tenta retroagir um sinistro de seguro em dez dias. O sistema rejeita. O Negócio diz: "Defeito. A gente precisa retroagir sinistros." A Tecnologia diz: "Comportamento esperado. O sistema rejeita datas com mais de sete dias." Agora o BA está no meio. É um defeito? Comportamento esperado? Ou cada um construiu uma expectativa diferente? O trabalho do BA não é escolher um lado. É responder uma pergunta melhor: o que o sistema deveria realmente fazer? Talvez o requisito realmente diga sete dias. Talvez o processo de negócio tenha mudado depois de ele ser escrito. Talvez os critérios de aceitação nunca tenham coberto esse cenário. Talvez sete dias seja uma configuração que ninguém explicou. Então não comece com "quem está certo?" Comece com "o que foi pretendido, o que foi construído e o que o negócio precisa agora?" Essa pergunta se divide em oito passos: escute a dor do negócio, recrie o cenário exato, verifique o requisito, verifique os critérios de aceitação, compare as três visões lado a lado, classifique que tipo de problema isso realmente é, pergunte se a necessidade de negócio mudou desde então, depois decida e documente para que a mesma discussão não volte na próxima sprint.

01

Passo 01

ESCUTAR — Entenda a dor do negócio

"O sistema não permite retroatividade" descreve comportamento. "A Operação não consegue processar sinistros tardios legítimos" descreve o problema de negócio.

Resumo

  • O que você estava tentando alcançar?
  • O que aconteceu no lugar disso?
  • Que impacto isso cria?
  • Existe um workaround?
  • Com que frequência isso acontece?
  • Quem é afetado?

Por que isso ajuda

Abrir o Jira antes de entender o problema de negócio significa que você está prestes a investigar a coisa errada com precisão.

02

Passo 02

RECRIAR — Veja o comportamento você mesmo

Não discuta um defeito que você não consegue descrever com precisão.

Pegue o cenário exato. Data do sinistro: 1º de agosto. Data de entrada: 11 de agosto. O negócio espera: sinistro aceito. Real: "A data do sinistro não pode ser mais de 7 dias no passado." Agora você tem algo testável.

Resumo

  • Capture: usuário
  • dado
  • passos
  • esperado
  • real

Por que isso ajuda

Um cenário preciso e reproduzível é o que transforma uma discussão de corredor numa investigação que todo mundo consegue checar.

03

Passo 03

REQUISITO — O que foi realmente pedido?

A Tecnologia pode ter construído o requisito exatamente como escrito — mas isso não é o fim da investigação.

Suponha que o requisito diga que sinistros podem ser retroagidos por no máximo sete dias corridos. A Tecnologia pode ter implementado isso corretamente, então o comportamento atual pode não ser um defeito de software. Mas o requisito em si ainda pode estar incompleto, desatualizado ou não servir mais à necessidade de negócio.

Resumo

  • requisito
  • user story
  • regras de negócio
  • fluxo de processo
  • design
  • registro de decisão
  • histórico de mudanças
  • política relevante

Por que isso ajuda

Verificar o requisito antes de discutir sobre o comportamento impede que os dois lados discutam de memória em vez de evidência.

04

Passo 04

ACEITAÇÃO — Que resultado nós concordamos?

Requisitos descrevem intenção. Critérios de aceitação tornam o comportamento testável.

Comparação

Critério de aceitação claro

"Dado um sinistro com data anterior a sete dias, quando o usuário envia, então o sistema impede o envio." — o comportamento é claramente intencional.

Critério de aceitação ambíguo

"Sinistros podem ser criados com uma data passada." Sete dias? Trinta? Qualquer data passada? Isso não é um defeito de código — é uma lacuna de requisito.

Resumo

  • fronteiras
  • exceções
  • casos negativos
  • papéis
  • mensagens de erro
  • fluxos alternativos

Por que isso ajuda

O CA te diz se o cenário em disputa foi realmente decidido algum dia ou só presumido.

05

Passo 05

COMPARAR — Necessidade de negócio vs requisito vs comportamento

Coloque as três visões lado a lado e a conversa fica útil.

O sistema bate com o requisito. Mas o requisito pode não satisfazer a necessidade de negócio atual. Isso é diferente de dizer "a Tecnologia está certa". Uma conclusão melhor: o sistema está se comportando como especificado, mas a regra atual não sustenta o cenário de negócio.

Resumo

  • Necessidade de negócio — Sinistros tardios legítimos precisam ser processados.
  • Requisito — Retroatividade limitada a 7 dias.
  • Sistema — Rejeita qualquer coisa com mais de 7 dias.

Por que isso ajuda

Nomear qual das três visões está fora de sintonia com as outras te diz que tipo de problema você está realmente resolvendo.

06

Passo 06

CLASSIFICAR — Que tipo de problema é esse?

A mesma discordância pode se resolver em quatro classificações bem diferentes.

Resumo

  • Defeito — o comportamento difere do requisito/CA acordado (o requisito permite 7 dias, o sistema rejeita 5).
  • Comportamento esperado — o comportamento bate com a regra acordada (o requisito permite 7 dias, o sistema rejeita 10) — embora isso não signifique que nada deva mudar; agora pode ser uma solicitação de mudança em vez de uma correção de defeito.
  • Lacuna de requisito — o cenário nunca foi claramente definido (o requisito diz "sinistros podem ser retroagidos", sem limite, sem exceção, sem fronteira) — o time precisa de uma decisão.
  • Problema de configuração ou dado — a lógica está correta, mas a configuração não está (o requisito diz 7 dias, a configuração diz 3) — o sintoma parece um defeito, mas a causa raiz está em outro lugar.

Por que isso ajuda

Cada classificação aponta para uma ação seguinte diferente — corrigir código, atualizar um requisito, conseguir uma decisão ou corrigir uma config. Errar isso manda a correção para o time errado.

07

Passo 07

NECESSIDADE ATUAL — Alguma coisa mudou?

Um sistema pode implementar corretamente o requisito de ontem e ainda assim estar errado para o negócio de hoje.

Resumo

  • Talvez a regulação tenha introduzido uma exceção.
  • Talvez a Operação tenha mudado seu processo.
  • Talvez um produto novo precise de retroatividade de 30 dias.
  • Talvez a suposição original estivesse errada.

Por que isso ajuda

Não force a necessidade de hoje dentro da documentação de ontem — nomear a mudança explicitamente é o que transforma "comportamento esperado" numa solicitação de mudança legítima.

08

Passo 08

DECIDIR E DOCUMENTAR — Encerre a ambiguidade

No final, capture o suficiente para que a mesma discussão não volte na próxima sprint.

Resumo

  • Comportamento observado — o que o sistema faz?
  • Comportamento esperado — o que ele deveria fazer agora?
  • Evidência — qual requisito, CA, regra ou política sustenta a conclusão?
  • Classificação — defeito / comportamento esperado / lacuna de requisito / problema de configuração-dado / mudança.
  • Decisão — corrigir, mudar, configurar, esclarecer ou aceitar.
  • Responsável — quem decide ou entrega a próxima ação?

Por que isso ajuda

Depois atualize o requisito, CA, registro de decisão, configuração ou defeito relevante — a decisão só se sustenta se a documentação mudar junto.

09

Passo 09

Um segundo exemplo: mesma discordância, resposta diferente

A evidência decide — não qual lado soa mais confiante.

Verifique o requisito: "Pedidos podem ser cancelados antes do envio." SEPARADO é antes de ENVIADO. A regra da Tecnologia é mais rígida que o requisito acordado. Isso é um defeito — a conclusão oposta do exemplo do sinistro retroagido, alcançada pelo mesmo método.

Comparação

O Negócio diz

"Clientes não conseguem cancelar pedidos depois da separação. Isso é um defeito."

A Tecnologia diz

"Esperado. O cancelamento é desabilitado assim que status = SEPARADO."

Por que isso ajuda

O método não pré-decide quem está certo. Ele só garante que o requisito, não a voz mais alta, resolve a questão.

10

Passo 10

A armadilha do BA: virar o árbitro

Não repasse opiniões. Traga evidência.

Comparação

Repassando opiniões

"O Negócio diz que isso está errado." / "A Tecnologia diz que é exatamente o que você pediu."

Trazendo evidência

"O requisito permite cancelamento até o envio. O comportamento atual bloqueia na separação. Isso difere da regra acordada."

Por que isso ajuda

Um BA não precisa provar que alguém cometeu um erro — o objetivo é remover a ambiguidade para que todo mundo saiba o que construir e testar.

Dica — Ou: "O limite de sete dias bate com o requisito aprovado. O negócio agora precisa de uma exceção de 30 dias, então isso é uma mudança de requisito." De qualquer jeito, a conversa avança em vez de recomeçar.

"Defeito" não significa que o negócio não gostou do resultado.

Um bom BA deixa o comportamento esperado claro o suficiente para a discussão desaparecer.

Às vezes o sistema está errado. Às vezes a expectativa está errada. Às vezes o requisito está incompleto. Às vezes a necessidade de negócio mudou. O trabalho do BA é separar essas possibilidades — não escolha lados, compare intenção, evidência e resultado.

Leve isso com você

Ficha de Decisão Defeito vs Comportamento Esperado

DEFEITO vs COMPORTAMENTO ESPERADO — FICHA DE DECISÃO
Classifique com evidência, não opinião.

TABELA DE EVIDÊNCIA RÁPIDA
Necessidade de negócio: ______________________________
Requisito / CA diz: ______________________________
O sistema realmente faz: ______________________________
Classificação: Defeito / Esperado / Lacuna / Config-Dado / Mudança
Decisão + responsável: ______________________________

ANTES DE FECHAR
[ ] O cenário está preciso.
[ ] A evidência de requisito/CA foi checada.
[ ] O resultado de negócio está entendido.
[ ] A classificação é baseada em evidência.
[ ] O responsável pela decisão está claro.
[ ] A story/CA/defeito/config relevante foi atualizada.

REGRA DE OURO
Não escolha lados. Compare intenção, evidência e resultado.
O objetivo não é vencer a discussão. É deixar o comportamento esperado inequívoco.

Receba novos guias em primeira mão.