“Cliente premium recebe 10% de desconto” ainda é superficial. Uma regra completa responde quem define premium, desde quando vale, quais produtos entram, se acumula, quem altera, como registrar exceção e o que acontece se o status mudar no meio da compra.
Software quebra não apenas por erro de programação. Quebra porque a regra foi especificada de forma incompleta e cada pessoa preencheu o vazio de um jeito.
Regra de negócio não pode ficar apenas na cabeça de quem pediu o sistema. Precisa de condição, responsável, validade, exceção e rastros.
O que torna o cliente premium: fatura, contrato, selo manual?
Comercial, financeiro ou o próprio sistema a partir de dados?
Retroage? Vale só para pedidos novos?
Todos, só linha própria, nunca item em promoção?
Soma com cupom, campanha, acordo?
Qual perfil muda o percentual e isso fica no histórico?
Como registrar um desconto fora da política?
E se o status mudar durante a compra?
Como essa decisão aparece no fechamento?
Preço, imposto, rateio, índice.
Alçada, prazo, substituição.
Faturamento, baixa, estorno.
Quem ganha, sobre qual base, quando perde.
Ver, editar, exportar, impersonar.
Quem entra no benefício ou no fluxo.
SLA, vencimento, feriado, fuso.
Transições permitidas e irreversíveis.
Como sair do padrão sem apagar o rastro.
O que acontece quando o outro sistema falha ou atrasa.
Se a regra está só na tela, alguém furará pelo atalho.
Decisão aplicada precisa poder ser explicada depois.
Regra sem exemplo de aceite vira discussão na homologação.
O que as pessoas dizem que o sistema “já sabe”.
E se, desde quando, quem pode, o que não entra.
O caso que só a operação conhece.
Catálogo com condição, ator, dado e aceite.
Um catálogo de regras que o time de desenvolvimento — da LD ou de outro — consegue implementar sem completar a frase no palpite.
Depende de quantas famílias de regra existem e se já há sistema ou só planilha.
Um conjunto de regras de um fluxo cabe em poucas entrevistas. Um comercial inteiro, não.
A pergunta “e se o status mudar no checkout?” só aparece cedo se quem pergunta já viu isso quebrar em produção.
Uma decisão operacional que o sistema precisa aplicar sempre da mesma forma, com condição, exceção e rastro.
Porque cada pessoa completa o vazio de um jeito — inclusive o programador.
Não. O requisito diz o que o sistema deve garantir. A regra é a decisão que muda o resultado — e costuma ser o miolo do requisito.
Sim. O catálogo pode ser o objeto da consultoria, independente da fábrica.
Se a frase ainda cabe num post-it, ainda não está pronta para virar código.
Fale com a LD: labs@ld.app.br · WhatsApp +55 11 95373-8551 · Av. Brigadeiro Faria Lima, 1572, Sala 1022 — Jardim Paulistano, São Paulo/SP.