Skip to content

Guia BA

Ninguém Sabe Quem É o Dono do Requisito

Quando todo mundo está envolvido, a responsabilidade pode silenciosamente não pertencer a ninguém.

Surya · 8 de agosto de 2026 · 6 min de leitura · 3 práticas

Stakeholders

Para Business Analysts presos mandando um requisito em círculos entre departamentos, BAs cujos documentos de requisito dizem "Dono: Negócio" e nada mais específico, Líderes de entrega desembaraçando quem realmente pode aprovar uma mudança e Qualquer um que já ouviu "pergunta pro negócio" como resposta.

Alguém pergunta:

“Quem é dono desse requisito?”

O Produto diz:

“O Negócio é dono.”

O Negócio diz:

“O BA vem cuidando disso.”

O BA diz:

“O Risco tomou a decisão.”

O Risco diz:

“A Operação precisa confirmar.”

A Operação diz:

“O Compliance deveria decidir.”

O Compliance diz:

“Isso não é do Risco?”

Seis respostas depois, ainda não temos um dono.

Essa é a coisa estranha sobre requisitos.

Um requisito pode ter um monte de gente em volta dele e ainda assim não pertencer a ninguém.

Aqui está o requisito

REQ-218 — Bloquear operações quando o dado de risco do cliente estiver indisponível

O requisito diz:

Se a informação de risco do cliente não puder ser obtida, a operação não deve prosseguir.

O desenvolvimento começa.

Aí o QA pergunta:

“O que exatamente deveria acontecer?”

A operação deveria:

  • Falhar completamente?
  • Ir para Revisão Manual?
  • Continuar e ser sinalizada depois?

Boa pergunta.

Então o BA pergunta:

Quem pode decidir?

É aí que o problema de verdade começa.

“Pergunta pro negócio”

Você vai ouvir isso muito.

“Pergunta pro negócio.”

Certo.

Qual negócio?

Risco?

Operações?

Front Office?

Compliance?

Produto?

“Negócio” não é um dono.

É um grupo de pessoas que podem querer coisas bem diferentes.

Se a resposta para “quem decide?” é o nome de um departamento, continue perguntando.

O BA não é dono automaticamente

Você pode ter:

  • escrito a story
  • conduzido os workshops
  • documentado as regras
  • atualizado o Jira
  • explicado para o desenvolvimento
  • apoiado o QA

Isso ainda não significa que você deveria tomar a decisão de negócio.

Um BA costuma ser dono da clareza do requisito.

Não necessariamente da escolha por trás dele.

Essa diferença importa.

O REQ-218 começa a viajar

Perguntamos ao Risco.

O Risco diz:

“A Operação precisa confirmar o fluxo.”

A Operação diz:

“O Compliance precisa confirmar se a Revisão Manual é aceitável.”

O Compliance diz:

“O Risco é dono da política.”

Risco → Operação → Compliance → Risco.

Todo mundo está envolvido.

Ninguém está decidindo.

É assim que costuma parecer uma responsabilidade não clara.

Não é silêncio.

É circulação.

Encontre a responsabilidade no ponto de decisão

Aqui está o teste mais simples:

Se dois stakeholders discordam, quem toma a decisão final?

Essa pergunta é muito mais útil do que:

“Quem está envolvido?”

Para o REQ-218, alguém eventualmente precisa escolher entre:

Rejeitar, Revisão Manual ou Continuar.

A pessoa com autoridade para fazer essa escolha está bem mais perto do dono de verdade.

A responsabilidade fica visível quando uma decisão precisa ser tomada.

Três papéis que vale a pena separar

Boa parte da confusão desaparece se pararmos de chamar todo mundo de “dono”.

Dono do Requisito

Responsável por como o comportamento de negócio deveria ser.

Consegue aprovar uma mudança relevante e sustentar o resultado.

Guardião do Requisito

Mantém o requisito claro, atualizado e testável.

Geralmente é o BA.

O guardião garante que todo mundo entenda o requisito, mas não toma a decisão de negócio automaticamente.

Responsável pela Decisão

Toma uma decisão específica de especialista. Por exemplo:

  • Risco → tratamento de risco
  • Compliance → interpretação regulatória
  • Operações → processo operacional
  • Tecnologia → design técnico

Podem ser pessoas diferentes.

Isso é perfeitamente normal.

O problema é quando ninguém sabe qual papel pertence a quem.

Voltando ao REQ-218

Em vez de escrever:

Dono: Negócio

escrevemos:

Dono do requisito
Head de Controles de Risco de Cliente
Guardião do requisito
Business Analyst
Decisão em aberto
O que acontece quando o dado de risco do cliente está indisponível?
Responsável pela decisão
Head de Controles de Risco de Cliente
Consultados
Operações, Compliance, Tecnologia
Impacto se não resolvido
O QA não consegue validar o fluxo de exceção.

Ainda precisamos da decisão.

Mas agora sabemos quem precisa tomá-la.

Isso sozinho já muda a conversa.

Em vez de mandar o requisito circulando pela organização, o BA pode levar a pergunta direto para quem realmente tem autoridade para resolvê-la.

Não confunda conhecimento técnico com responsabilidade

O especialista pode conhecer o processo melhor que ninguém.

Isso não significa automaticamente que ele pode mudá-lo.

O especialista pode dizer:

“É assim que o processo funciona hoje.”

O dono precisa conseguir dizer:

“É assim que o processo deveria funcionar amanhã.”

Conhecimento e autoridade são coisas diferentes.

Os dois importam.

Mas não são a mesma coisa.

O teste de responsabilidade de cinco minutos

Escolha um requisito importante.

Pergunte:

1. Quem consegue explicar por que ele existe?

2. Quem consegue aprovar uma mudança relevante?

3. Quem aceita o resultado de negócio?

4. Se os stakeholders discordarem, quem toma a decisão final?

Essa última pergunta é a importante.

Se ninguém consegue responder isso com clareza, você provavelmente ainda não encontrou o dono.

O que aconteceu com o REQ-218?

O Head de Controles de Risco de Cliente finalmente toma a decisão:

Se o dado de risco estiver indisponível, a operação não deve prosseguir automaticamente.

Em vez disso:

Mande para Revisão Manual.

Agora o requisito fica muito mais claro.

Regra de Negócio

Uma operação não deve prosseguir automaticamente quando o dado de risco do cliente exigido estiver indisponível.

Critério de Aceitação

Dado que o dado de risco do cliente não pode ser obtido
Quando a validação pré-operação roda
Então o processamento automático para
E a operação entra em Revisão Manual.

Agora sabemos os dois lados:

o que o sistema deveria fazer

e

quem sustenta a decisão.

Um requisito não tem dono porque um nome está do lado dele no Jira.

Ele tem dono quando alguém diz "eu sou responsável por essa decisão".

Da próxima vez que um requisito chegar numa bifurcação, não mande ele circulando pela organização de novo. Faça uma pergunta: quem tem o direito de escolher? Se ninguém sabe, o requisito ainda não tem dono.

Leve isso com você

Checagem de Responsabilidade do Requisito

CHECAGEM DE RESPONSABILIDADE DO REQUISITO

Requisito:

Por que ele existe?

Dono do requisito:

Guardião do requisito:

Quem aprova mudanças relevantes?

Quem toma a decisão final quando as pessoas discordam?

Decisão em aberto:

Responsável pela decisão:

Impacto se não resolvido:

Receba novos guias em primeira mão.