1. O problema da regra implícita
Em projetos de implantação de sistemas de gestão empresarial, parte substancial do retrabalho decorre de critérios que ninguém escreveu. O limite a partir do qual uma compra exige aprovação de diretoria, a condição que impede o faturamento de um pedido, a fórmula que determina o limite de crédito de um cliente: são decisões de negócio que governam a operação diariamente e que, com frequência, existem apenas na prática de quem executa a atividade.
A consequência é previsível. O critério aparece pela primeira vez em teste de aceitação, quando a configuração já foi realizada. A área de negócio afirma que o comportamento está errado; a área de tecnologia demonstra que implementou o que havia sido especificado. Ambas as afirmações procedem, porque a regra nunca foi enunciada.
A regra existe no negócio independentemente de estar escrita. A ausência de enunciado não elimina a regra: transfere sua guarda para a memória individual, impede a verificação e torna a decisão do sistema inauditável.
Tratar a elicitação de regras como etapa de documentação posterior ao desenho do processo. Se a regra não é declarada antes da configuração, o que se configura é a interpretação de quem configurou.
2. Definição de regra de negócio
Adota-se a definição consolidada pelo Business Rules Group: regra de negócio é uma diretriz que define ou restringe algum aspecto do negócio, com o propósito de assertar sua estrutura ou de controlar e influenciar seu comportamento.
Três atributos decorrem dessa definição e orientam toda a prática do módulo.
- Origem no negócio. A regra provém de legislação, contrato, norma setorial, política interna ou decisão de gestão. Não provém do sistema, ainda que o sistema seja o meio pelo qual ela é aplicada.
- Independência tecnológica. A regra permanece válida se o processo for executado manualmente. O sistema de informação é um dos meios de aplicá-la, não sua justificativa.
- Efeito determinado. A regra estabelece o que é obrigatório, proibido ou permitido, ou define como um valor é derivado de outros valores.
Uma distribuidora de peças de reposição industrial vende para clientes de três segmentos: novo (menos de seis meses de relacionamento), regular e estratégico (contrato de fornecimento vigente e faturamento anual superior a R$ 2.000.000,00, com autonomia negocial maior: desconto de até 15% não passa por aprovação intermediária). O vendedor concede desconto diretamente no pedido de venda; a partir de determinado percentual, o pedido precisa de aprovação antes da confirmação. Este caso é retomado ao longo de toda a aula e é o objeto da atividade guiada da seção 15.
O enunciado acima ilustra a forma esperada: uma única obrigação, com sujeito determinado, condição objetiva e momento de aplicação explícito.
3. Regra, requisito, processo e política
Os quatro conceitos são frequentemente empregados como equivalentes, o que produz especificações ambíguas e processos rígidos. A distinção é operacional.
| Conceito | Natureza | Exemplo |
|---|---|---|
| Política | Orientação geral da organização, não operacionalizável de forma direta. | A empresa mantém controle rigoroso sobre gastos discricionários. |
| Regra de negócio | Enunciado atômico e verificável, derivado de uma política ou de norma externa. | É proibido reembolsar despesa de viagem sem documento fiscal eletrônico. |
| Requisito | Obrigação imposta ao sistema para que a regra seja cumprida. | O sistema deve bloquear o lançamento de despesa sem documento fiscal anexado. |
| Processo | Sequência de atividades que produz um resultado de negócio. | Prestação de contas de viagem: registrar, conferir, aprovar, reembolsar. |
A regra é declarativa e responde o que deve valer. O processo é procedimental e responde em que ordem as atividades ocorrem. Quando o critério de decisão é dissolvido na estrutura do fluxo, toda alteração de limite ou de faixa exige redesenhar e republicar o processo.
Se a frase descreve quando algo ocorre na sequência de trabalho, trata-se de processo. Se descreve sob que condição algo é permitido, exigido ou calculado, trata-se de regra.
4. Princípios do Business Rules Manifesto
O Business Rules Manifesto (Business Rules Group, 2003) enuncia princípios que fundamentam a prática. Quatro são diretamente aplicáveis ao trabalho deste módulo.
Regras constituem artefato próprio
A regra não é subproduto do processo nem do código. É declarada explicitamente, mantida em repositório próprio e referenciada pelo fluxo que a aplica.
Regras pertencem ao negócio
A propriedade e a autoridade de alteração cabem à área de negócio. A área de tecnologia responde pela implementação fiel do enunciado, não por seu conteúdo.
Regras são declarativas
Enunciam condições e obrigações, não algoritmos. A mesma regra admite implementações distintas — parâmetro, fluxo de aprovação ou serviço de decisão — sem que o enunciado se altere.
Regras fundamentam-se em vocabulário
Cada termo empregado no enunciado possui definição única e compartilhada entre as áreas. Sem vocabulário controlado, o mesmo enunciado admite leituras divergentes.
Regra existente apenas no código-fonte, sem enunciado correspondente em repositório de negócio, constitui falha de governança ainda que o comportamento do sistema esteja correto: não há quem responda pela regra nem como demonstrar sua vigência.
5. Taxonomia das regras
A classificação da regra não é exercício terminológico: cada categoria corresponde a um mecanismo distinto de implementação no sistema de gestão.
| Categoria | Exemplo de enunciado | Implementação típica |
|---|---|---|
| Definição de termo e fato | Cliente estratégico é o cliente com contrato de fornecimento vigente e faturamento anual superior a R$ 2.000.000,00. | Campo, domínio de valores, relacionamento no modelo de dados. |
| Derivação | O desconto automático de um cliente corresponde a um ponto percentual por ano de relacionamento comercial, até o limite de oito pontos percentuais. | Fórmula, campo calculado, rotina de cálculo. |
| Restrição | É proibido conceder desconto a cliente com título vencido há mais de trinta dias. | Validação de entrada, verificação de integridade, bloqueio de status. |
| Regra de ação | Quando um pedido for aprovado com desconto superior a 15%, deve ser gerado alerta para revisão trimestral da política comercial. | Fluxo de trabalho, evento, tarefa automática. |
A classificação incorreta produz implementação inadequada. Uma derivação tratada como restrição obriga o usuário a informar manualmente um valor que o sistema poderia calcular; uma regra de ação tratada como validação bloqueia a operação em vez de disparar o efeito previsto.
6. Vocabulário controlado e SBVR
A norma SBVR (Semantics of Business Vocabulary and Business Rules, OMG) estabelece que toda regra se apoia em um vocabulário de negócio previamente definido. O vocabulário é composto por três elementos.
- Termo: designa um conceito do domínio —
pedido de venda,segmento do cliente,título vencido. - Nome: designa uma instância única —
Diretoria Comercial. - Fato: associa termos por meio de um verbo —
pedido de venda é vinculado a segmento do cliente.
O enunciado da regra emprega exclusivamente termos e fatos declarados no vocabulário. Essa restrição produz três efeitos verificáveis na implantação: elimina a sinonímia entre áreas, que costumam alternar entre "solicitação", "pedido" e "requisição" para o mesmo objeto; alinha o vocabulário de negócio ao dicionário de dados do ERP; e permite verificar, antes da configuração, se a regra é expressável com os dados que o sistema efetivamente mantém.
A elicitação do vocabulário precede a elicitação das regras. Regra cujo enunciado emprega termo ausente do vocabulário não é implementável sem que antes se decida o significado do termo.
7. Modalidades e enunciados padronizados
A modalidade do enunciado determina o comportamento exigido do sistema. A adoção de fórmulas fixas reduz a ambiguidade e torna a regra diretamente traduzível em critério de teste.
| Modalidade | Fórmula | Comportamento exigido |
|---|---|---|
| Obrigação | É obrigatório que… | O sistema impede a conclusão da operação enquanto a condição não for satisfeita. |
| Proibição | É proibido que… | O sistema rejeita a operação e registra a tentativa. |
| Permissão | É permitido que… | O sistema autoriza a operação, usualmente condicionada a perfil ou situação. |
| Necessidade | É necessariamente o caso que… | Verdade estrutural do domínio, assumida como invariante do modelo. |
Comparem-se os dois enunciados a seguir. O primeiro não é implementável nem testável; o segundo determina univocamente o comportamento do sistema e o critério de verificação.
O sistema deve tratar corretamente os pedidos com desconto alto, avisando quem for responsável.
É obrigatório que pedido de venda com desconto solicitado superior a 15% seja aprovado por diretor comercial antes da confirmação do pedido.
8. Critérios de qualidade e ficha de catálogo
Um enunciado só é aceito no catálogo se satisfaz quatro critérios.
- Atomicidade. Expressa uma única obrigação. Enunciado que emprega "e também" ou "exceto quando" deve ser decomposto em enunciados independentes.
- Univocidade. Admite uma única interpretação. Expressões como "relevante", "adequado" ou "em tempo hábil" são substituídas por critérios mensuráveis.
- Verificabilidade. É possível determinar objetivamente, em qualquer instância, se a regra foi cumprida ou violada.
- Rastreabilidade. Possui identificador estável, origem declarada e vínculo com o processo e com o objeto de configuração que a implementa.
O registro é feito em ficha com estrutura mínima estável, o que permite referenciar a regra em testes de aceitação, registros de mudança e evidências de auditoria.
| Campo | Conteúdo |
|---|---|
| Identificador | RN-014, estável ao longo de todo o ciclo de vida da regra. |
| Enunciado | Frase única, na modalidade adequada, com vocabulário controlado. |
| Categoria | Definição, derivação, restrição ou regra de ação. |
| Origem | Política, cláusula contratual, exigência legal ou decisão de gestão, com referência. |
| Responsável | Área proprietária e papel autorizado a alterar a regra. |
| Processo afetado | Processo e atividade em que a regra é aplicada. |
| Implementação | Objeto de configuração, fluxo de aprovação ou extensão que a materializa. |
| Vigência | Data de início, data de término e versão anterior substituída. |
Regra sem identificador não pode ser referenciada em teste, em mudança ou em evidência de auditoria. A numeração é condição de rastreabilidade, não formalidade documental.
9. Processo e decisão
Um processo de negócio contém atividades e decisões. A prática consolidada, refletida na relação entre as notações BPMN e DMN, consiste em manter a decisão fora da estrutura do fluxo: o processo possui uma atividade de decisão que consulta um modelo declarativo e prossegue conforme o resultado obtido.
A alternativa — representar cada critério como um desvio condicional no fluxo — produz processos que precisam ser redesenhados sempre que um limite muda, ainda que a sequência de trabalho permaneça idêntica.
Diagrama de requisitos de decisão
A notação DMN (Decision Model and Notation, OMG) organiza o modelo em duas camadas. A primeira, o diagrama de requisitos de decisão, declara quais decisões existem e de que dados de entrada e de que fontes de conhecimento — políticas, normas, contratos — cada uma depende. A segunda camada é a lógica de decisão propriamente dita, usualmente expressa em tabelas.
10. Tabelas de decisão
A tabela de decisão expressa a lógica de uma decisão de forma completa e verificável. Cada coluna de entrada corresponde a um dado avaliado; cada coluna de saída, a um resultado produzido; cada linha é uma regra, com a condição aplicável em cada entrada.
Política de acionamento
A política de acionamento declara o que ocorre quando mais de uma linha é satisfeita. As quatro de uso mais frequente são: única, em que as linhas não podem se sobrepor; primeira, em que vale a primeira linha satisfeita na ordem declarada; prioridade, em que vale a linha de maior precedência de saída; e coleta, em que os resultados de todas as linhas satisfeitas são acumulados.
Passo a passo de construção
Uma tabela de decisão não nasce pronta a partir da lógica que se tem na cabeça. Ela é construída em etapas verificáveis, cada uma apoiada nas regras já enunciadas no catálogo — nunca em comportamento decidido no momento de preencher a tabela.
| # | Etapa | O que fazer |
|---|---|---|
| 1 | Nomear a decisão | Escreva a pergunta que a tabela responde. Para o caso da aula: Determinar nível de aprovação do desconto — dado um pedido de venda, qual é o nível de aprovação exigido? |
| 2 | Listar os dados de entrada | Extraia as entradas do vocabulário controlado e das regras já enunciadas — não introduza uma entrada que não decorra de regra alguma. No caso: desconto solicitado, segmento do cliente, título vencido há mais de 30 dias. |
| 3 | Ordenar as colunas | Coloque primeiro a entrada de maior poder de corte — a que, sozinha, já decide o maior número de casos. A restrição sobre inadimplência vale para qualquer desconto e qualquer segmento: título vencido vai na primeira coluna. |
| 4 | Declarar os valores de cada entrada, com extremos explícitos | Desconto solicitado: menor que 5%; de 5% a 15%, incluindo os dois extremos; maior que 15%. Segmento: novo ou regular; estratégico. Título vencido: sim; não. |
| 5 | Escrever uma linha por combinação com resultado distinto | Não é uma linha por regra enunciada — é uma linha por resultado. Quando título vencido é "sim", o resultado é o mesmo qualquer que seja o desconto ou o segmento: uma única linha basta. |
| 6 | Preencher a saída a partir de uma regra do catálogo | Se a saída de uma linha não decorre de nenhum RN já enunciado, falta escrever a regra antes de preencher a tabela. |
| 7 | Verificar completude | Enumere todas as combinações de entrada e confirme que cada uma cai em exatamente uma linha, sem sobra. |
| 8 | Verificar os valores de fronteira | Para cada limite numérico, teste o valor exato do limite. Um pedido com desconto de exatamente 5% ou de exatamente 15% precisa cair em uma linha declarada, sem ambiguidade. |
Resultado: nível de aprovação do desconto
Tabela sob política única, decisão Determinar nível de aprovação do desconto, construída pelas oito etapas acima.
| # | Título vencido | Desconto solicitado | Segmento | Nível de aprovação |
|---|---|---|---|---|
| 1 | sim | qualquer | qualquer | Bloqueado — desconto não pode ser concedido (RN-015) |
| 2 | não | menor que 5% | qualquer | Aprovação automática (RN-016) |
| 3 | não | de 5% a 15% | novo ou regular | Gerência comercial (RN-017) |
| 4 | não | de 5% a 15% | estratégico | Aprovação automática (RN-018) |
| 5 | não | maior que 15% | qualquer | Diretoria comercial (RN-014) |
Duas verificações fecham as etapas 7 e 8 sobre esta tabela específica. Completude: título vencido tem dois valores; para "sim", uma única linha cobre todos os casos; para "não", as três faixas de desconto — com o segmento desdobrando a faixa intermediária — esgotam as combinações restantes. Nenhuma combinação fica sem linha. Ausência de conflito: como título vencido é avaliado primeiro e nenhuma outra coluna se repete com o mesmo valor de título vencido em duas linhas com saída diferente, nenhuma combinação satisfaz duas linhas ao mesmo tempo. Os extremos das faixas de desconto — exatamente 5% e exatamente 15% — pertencem à faixa "de 5% a 15%", nunca à faixa vizinha, conforme declarado na etapa 4.
Colocar primeiro a entrada de maior poder de corte não é estética: reduz o número de linhas necessárias — sem essa ordenação, a condição "sem título vencido" precisaria ser repetida nas quatro linhas seguintes — e explicita que a restrição de inadimplência tem precedência sobre qualquer cálculo de desconto, exatamente como a regra de restrição estabelece.
11. Implementação no ERP
Definida a regra, resta decidir onde implementá-la. Em um sistema de gestão empresarial existem quatro alternativas, ordenadas por acoplamento e por custo de manutenção crescentes.
| Alternativa | Descrição | Quando é adequada |
|---|---|---|
| Parametrização | Configuração do produto padrão: tabelas de parâmetros, domínios, limites de alçada. | Alternativa preferencial. A alteração da regra não exige desenvolvimento nem novo ciclo completo de testes. |
| Fluxo de aprovação | Recurso de workflow do próprio ERP, com papéis, níveis e prazos configuráveis. | Regras de ação e roteiros de aprovação com múltiplos níveis. |
| Motor de regras | Serviço de decisão externo consultado pelo processo. | Regra que muda com frequência elevada ou que é compartilhada por vários sistemas. |
| Extensão em código | Desenvolvimento sobre o produto padrão. | Último recurso. Eleva o custo de atualização de versão e exige teste de regressão a cada ciclo. |
O critério de escolha é a alternativa de menor acoplamento capaz de satisfazer a regra. A decisão, a alternativa descartada e a consequência assumida devem constar da ficha da regra: esse registro é o que permite reavaliar a escolha quando o comportamento do negócio muda.
Cada extensão em código adiciona um item ao escopo de teste de regressão de toda atualização do produto. Regras implementadas por parametrização acompanham a evolução do produto sem custo adicional de verificação.
12. Governança das regras
A regra tem ciclo de vida: é elicitada junto ao proprietário, formalizada no catálogo, validada pela área de negócio, publicada e implementada, revisada periodicamente e, eventualmente, revogada. Cada transição é registrada com data e responsável.
Propriedade
Cada regra possui uma única área proprietária e um papel autorizado a alterá-la. A área de tecnologia implementa e não decide o conteúdo. Regras sem proprietário declarado permanecem em vigor sem que ninguém responda por sua atualização.
Evidência
A governança exige duas formas de registro. O versionamento do catálogo, com data de vigência, demonstra qual enunciado estava em vigor em determinado momento. O rastro de execução demonstra qual decisão o sistema tomou em cada instância e com base em quais entradas.
Exigências de controle interno, de proteção de dados pessoais e de obrigações setoriais recaem sobre a decisão efetivamente executada. Sem catálogo versionado e sem rastro de execução, a organização não demonstra qual regra vigorava no momento do fato, e a ausência de demonstração equivale, para fins de auditoria, à ausência de controle.
13. Antipadrões
Quatro situações devem ser identificadas no diagnóstico do processo do parceiro.
- Regra enterrada no código. O critério existe apenas na implementação, sem enunciado correspondente. A alteração depende de desenvolvimento e o comportamento não é auditável.
- Regra duplicada. O mesmo critério é implementado em pontos distintos do sistema ou em sistemas diferentes. As cópias divergem na primeira alteração.
- Regra contraditória. Dois enunciados vigentes produzem resultados incompatíveis para a mesma entrada. Ocorre com frequência quando áreas mantêm catálogos separados.
- Regra órfã. O enunciado existe, mas sem área proprietária declarada. Não há quem autorize a alteração nem quem responda pela vigência.
O diagnóstico é conduzido sobre o processo em operação: para cada desvio condicional observado no fluxo ou no sistema, verifica-se a existência do enunciado correspondente, do proprietário e da data de vigência. A ausência de qualquer um dos três caracteriza um dos antipadrões acima.
14. BABOK e a prática de análise de negócios
O BABOK Guide (A Guide to the Business Analysis Body of Knowledge), publicado pelo IIBA (International Institute of Business Analysis), define análise de negócios como a prática de possibilitar mudança em um contexto organizacional, definindo necessidades e recomendando soluções que entreguem valor às partes interessadas. As técnicas percorridas nesta aula — elicitação de regras, tabela de decisão, ficha de catálogo — não são exercício isolado: têm nome dentro dessa disciplina.
Seis áreas de conhecimento
| Área de conhecimento | O que trata |
|---|---|
| Planejamento e monitoramento | Como a análise será conduzida: abordagem, partes interessadas, governança do próprio trabalho de análise. |
| Elicitação e colaboração | Como obter informação de quem a possui e confirmar o entendimento com quem forneceu. É o que o grupo faz ao levantar vocabulário e regras junto ao parceiro. |
| Gestão do ciclo de vida de requisitos | Rastrear, manter, priorizar e aprovar requisitos ao longo do tempo — o mesmo papel que a ficha de catálogo cumpre para a regra. |
| Análise de estratégia | Conectar a mudança proposta ao estado futuro desejado pela organização. |
| Análise de requisitos e definição de design | Business Rules Analysis e Decision Modeling — os dois assuntos centrais desta aula — são técnicas catalogadas nesta área. |
| Avaliação de solução | Medir se a solução implementada entrega o valor esperado e identificar limitações. |
Os seis termos centrais (BACCM)
O Business Analysis Core Concept Model define seis termos aplicáveis a qualquer iniciativa de análise. Aplicados ao caso da distribuidora:
| Termo | No caso da distribuidora |
|---|---|
| Necessidade | Descontos concedidos sem critério auditável, com aprovações inconsistentes entre vendedores. |
| Solução | Regras catalogadas e tabela de decisão publicada e parametrizada no ERP. |
| Parte interessada | Diretoria comercial, gerência de crédito, vendedor, cliente. |
| Valor | Redução de retrabalho, decisão auditável, tempo de aprovação previsível. |
| Contexto | Política comercial vigente, perfil dos clientes, restrição de inadimplência. |
| Mudança | Passar de critério informal do vendedor para regra publicada e parametrizada. |
Nomear a técnica pelo termo usado na prática profissional — elicitação, requisito, regra de negócio, decision modeling — permite que o grupo comunique o trabalho do projeto integrador em vocabulário reconhecido por quem já atua como analista de negócios, e localizar rapidamente onde aprofundar quando faltar técnica.
15. Atividade e aplicação
A atividade conduzida em aula produz o insumo das aulas seguintes: o catálogo inicial de regras alimenta a configuração do escopo na plataforma e os cenários de teste da implantação.
O caso da distribuidora, apresentado nas seções 2 e 10, percorre esse roteiro por completo e serve de modelo: se o processo do parceiro ainda não estiver mapeado em detalhe suficiente, o grupo aplica o roteiro ao caso da distribuidora antes de migrar para o processo real.
- Selecionar, no caso do parceiro, um processo que envolva aprovação, classificação ou cálculo.
- Registrar o vocabulário: os termos empregados no processo e a definição acordada de cada um.
- Enunciar no mínimo cinco regras, atômicas, na modalidade adequada e com identificador estável.
- Classificar cada regra segundo a taxonomia da seção 5.
- Modelar uma das decisões em tabela, declarando a política de acionamento e verificando completude e ausência de conflito.
- Indicar, para cada regra, onde deve ser implementada no ERP, com a justificativa e a alternativa descartada.
Critérios de aceitação do produto
- Nenhum enunciado emprega termo ausente do vocabulário registrado.
- Nenhum enunciado contém duas obrigações.
- A tabela de decisão é completa e sem conflito sob a política declarada, incluídos os valores de fronteira.
- Cada regra possui origem, área proprietária e ponto de implementação declarados.
Entre as regras levantadas, quantas estavam efetivamente escritas em algum documento da organização antes desta atividade? Para as demais, onde residia o critério até este momento?
16. Referências
- Business Rules Group — Defining Business Rules: What Are They Really? Relatório final, 2000.
- Business Rules Group — The Business Rules Manifesto, 2003.
- OMG — Semantics of Business Vocabulary and Business Rules (SBVR).
- OMG — Decision Model and Notation (DMN).
- OMG — Business Process Model and Notation (BPMN 2.0).
- IIBA — A Guide to the Business Analysis Body of Knowledge (BABOK Guide), análise de regras de negócio.
- von Halle, B. — Business Rules Applied. Wiley, 2001.
- Ross, R. — Business Rule Concepts. Business Rule Solutions.
- Taylor, J. — Real-World Decision Modeling with DMN. Meghan-Kiffer Press, 2016.