Deduzo que antes do lançamento do microcomputador o termo regra de negócio era algo interpretado totalmente isolado dos softwares empresariais, ou talvez nem fosse um termo conhecido pelas pessoas.
Nos tempos atuais é difícil encontrar alguém que entende regra de negócio como algo isolado do software. Quando se fala “regra de negócio”, praticamente “sempre” é no contexto de um sistema.
É possível uma empresa mais arcaica viver sem software, mas não consegue viver sem regras de negócio.
Uma RN (Regra de Negócio), no contexto da Engenharia de Software, é tratada como um Requisito de Software, por ser algo que sem ela, o software não existe.
Para ilustrar isso, imaginemos uma empresa que possui um departamento de expedição de materiais.
Este departamento que não possui software para automatizar as atividades deste departamento.
Vejamos a seguir, um pouco sobre este cenário.
Sempre que uma pessoa se dirigir ao departamento de expedição para solicitar uma mercadoria esta pessoa deve se identificar com seu documento de identidade. O profissional do departamento de expedição deve certificar-se que o documento é válido.
Após checar que o documento é válido, o profissional deverá pegar o documento de protocolo de entrega com a pessoa, e neste documento conterá a seção e caixa onde se encontra a mercadoria.
| Deverá então dirigir-se à seção, na caixa identificada, pegar o material e levar ao guichê para entrega à pessoa que o solicitou. Antes de realizar a entrega, deverá solicitar que a pessoa assine o livro de entregas, incluindo seu documento e dados de endereço. No livro também devem ser escritos os dados da mercadoria (nome, categoria, marca e modelo), nome do profissional que fez a entrega, e data e hora da entrega.
Se a mercadoria solicitada não estiver na seção e caixa onde deveria estar, o profissional do departamento deverá entrar em contato com a gerência para reportar o problema. O mesmo deve ser feito caso identifique-se que o documento da pessoa que está buscando o material não é válido. |
No cenário acima percebemos que a operação do departamento de expedição é viável sem um software, e que existem uma série de critérios e restrições para que o material seja entregue ao seu solicitante. Os critérios e restrições informados são regras, e regras da empresa (negócio) que faz as entregas. Logo, são regras de negócio.
Regras de negócio são premissas e restrições aplicadas a uma operação comercial de uma empresa, que precisam ser atendidas para que o negócio funcione da maneira esperada.
Um software tem como objetivo automatizar atividades de uma empresa. Isso se dará através da criação de funcionalidades, que realizarão requisitos funcionais.
Mas os requisitos funcionais, como citado anteriormente, definem quais são as necessidades/exigências da empresa em termos funcionais (que funcionarão através de um sistema), ou seja, o que o sistema deverá fazer.
As regras de negócio definem como o sistema fará o atendimento às necessidades/exigências definidas; uma RN pode ser compreendida quanto a como um requisito funcional se realizará.
Importância das Regras de Negócio
E raro, muito raro mesmo, encontrar um requisito funcional que não possua dependência com uma ou mais regras de negócio.
Em função disso, RNs são tão importantes quanto RFs. Um RF não identificado ou não realizado pode gerar um débito técnico sério de escopo, mas uma RN mal especificada pode gerar mais ônus ainda, pois o sistema poderá contrair bugs em função disso.
Ou seja, a funcionalidade existirá, mas estará processando o que tem que processar de maneira errada, e detectar isso após a construção do sistema se a regra de negócio estiver especificada incorretamente é algo praticamente impossível, só quando o sistema for para produção e parar na mão do cliente. Isso é o pior cenário possível.
Requisitos e Agilidade
Agilidade não é produzir software com pressa, é produzir software com velocidade, entregando valor no menor espaço de tempo possível, e melhorando isso continuamente.
Para ser ágil, é fundamental ser eficiente.
Não é plausível falar em agilidade sem eficiência, com desperdício.
Em projetos de software, um dos maiores desafios é a boa comunicação.
Deixar claro o que se quer, o que será entregue, como será produzido etc. Isso não é simples quando produzimos software, devido à complexidade inerente a esta atividade.
Quando se entende um requisito do jeito errado, sempre há o custo de fazer errado, desfazer, e fazer certo. Obviamente, este tipo de desperdício custa 3 vezes mais que se tivéssemos feito certo da primeira vez.
E neste contexto, fica claro que o uso racional da modelagem de requisitos com o objetivo de transmitir ideias entre membros de um mesmo time, é uma ferramenta que favorece muito uma cultura ágil.
Atributos de uma boa Regra de Negócio
Uma RN com qualidade precisa atender a alguns atributos específicos. Na literatura, tanto nacional quanto estrangeira, não há material (ao menos que eu conheça) que especifique estes atributos para RN.
Entretanto, devido à estrutura sintática de uma RN ser muito semelhante à de um RF, eu elenquei alguns atributos (alguns comuns aos RFs) a serem considerados na especificação de uma RN.
A seguir a lista dos atributos que considero relevantes.
| Atributo | Referente a |
| Unidade | A RN deve propor/viabilizar uma única coisa apenas. Não deve atender a mais de uma restrição. A RN “Cálculo de salário” não é unitária, pois se refere implicitamente a cálculo de qualquer tipo de salário, e em qualquer empresa existem formas diferentes de calcular salário (para profissional ativo, aposentado, estagiário, efetivo, licenciado etc.). Esta RN assume assim várias responsabilidades, quando deveria assumir apenas uma. |
| Completude | A RN deve ser autocontida, deve ter “início/meio/fim”, ser completa. A RN “Cálculo de salário” não é completa, só conta “parte da estória”. Para ser completo deveria ser algo como “Cálculo de salário para profissionais afastados há mais de 15 dias”. |
| Consistência | Não deve contradizer outra RN do mesmo escopo do projeto. É como termos duas RNs se propondo a fazer uma mesma coisa, mas cada RN se propondo a fazer esta coisa de formas diferentes. |
| Atomicidade | Uma RN para ser atômico precisa também ter unidade, pois atomicidade remete a assumir apenas uma responsabilidade. Mas também, deve ser indivisível, não podendo ser decomposta. Muitos RNs possuem conjunção, dependem de outras para se realizar. Onde temos duas RNs “Calcular juros para pagamento atrasado” e “Incluir juros para pagamentos de financiamento imobiliário atrasados” na realidade, se pensarmos em atomicidade, temos uma única RN que é “Calcular juros para pagamentos atrasados de financiamento imobiliário”. |
| Não-Ambiguidade | Não pode ser ambígua, definir algo que não fica claro o que é. A RN “Critérios para processamento de faturas” é ambígua. Fatura de que, critérios para processar o que? “Critérios para processamento de fatura de mensalidade” já é melhor, mas ainda é ruim. Mensalidade de que? Seria não ambíguo se não deixasse dúvidas, algo como “Critérios para processamento de faturas de mensalidades de alunos do segundo grau” ou “Critérios para processamento de faturas de mensalidades de qualquer aluno impendente de série”. |
| Verificável | Não adianta ter uma RN se ele não é palpável, possível de associar com um RF que será construído, testado etc. Uma RN tem que ser testável, tem que ser possível atestar que a RN foi atendida através de algum RF. Para isso tem que ser também rastreável. |
| Rastreável | Deve ser possível achar a RN no sistema pronto. Como saber se uma RN foi atendida? Para isso é necessário ter rastreabilidade, e isso só é possível ligando as pontas (associar a RN ao RF, associar o RF à interface gráfica, que será associada a um caso de uso, que será associado a funcionalidades, que serão implementadas etc.). |
| Exemplificável | Muitas RNs tratam de cálculos, fórmulas, algoritmos etc. Uma RN deve poder ser exemplificada fora do contexto do sistema, para assim facilitar o entendimento de seu escopo pelos profissionais que a implementarão/validarão. |
Um detalhe importante é que uma RN não possui prioridade. Como uma RN, no contexto de um sistema, somente existe se associada a um ou mais Requisitos Funcionais, a prioridade aplicada à RN será a prioridade aplicada ao requisito que depende dela.
Estrutura de uma Regra de Negócio
Não há um padrão estabelecido sobre a estrutura de um RN. Mas a maioria das empresas utiliza um formato semelhante, contendo campos específicos. O modelo a seguir contempla os campos mais relevantes, com posterior descrição de cada um.
| Identificador | |||
| Nome | |||
| Data de criação | Autor | ||
| Data da última alteração | Autor | ||
| Versão | Dependências | ||
| Descrição | |||
Explicando cada campo
| Campo | Descrição |
| Identificador | Sufixo seguido de um identificador único. O sufixo geralmente utilizado é RN (Regra de Negócio) e o identificador único geralmente é composto de quatro dígitos (podendo ser mais, conforme a o tamanho do sistema que está sendo especificado). |
| Nome | Nome curto da RN, mas que possibilite entender bem o que RN faz apenas pelo nome. |
| Módulo | Módulo ao qual o RF pertence. Se for um sistema pequeno que não possua nenhum módulo, somente o próprio sistema, deve ser preenchido com N/A (não se aplica). |
| Data de criação | Data da criação da RN, ou a data em que ela foi especificada. |
| Autor | Profissional que especificou a RN pela primeira vez, quem a criou. |
| Data da última alteração | Data em que houve a última alteração no RN. |
| Autor | Profissional que alterou a especificação da RN pela última vez. |
| Versão | Número da versão do RN. Geralmente utiliza-se algo simples, como 1, 2 etc. A versão inicial sempre é a 1, e a cada alteração incrementa-se a versão (na criação versão 1, na primeira alteração versão 2 etc.). |
| Dependências | Quais RFs (Requisitos Funcionais) são dependentes da RN para serem realizados. Coloca-se apenas o identificador dos RFs. |
| Descrição | Descrição detalhada (a mais detalhada possível) da RN. |
Exemplo de uma Regra de Negócio especificada
| Identificador | RN0001 | ||
| Nome | Validação da identificação da pessoa que solicita a retirada/entrega do material | ||
| Módulo | Gestão de Armazéns | ||
| Data de criação | 31/01/2016 | Autor | Nagarjuna |
| Data da última alteração | N/A | Autor | N/A |
| Versão | 1 | Dependência | RF0099 |
| Descrição | Sempre que uma pessoa se dirigir ao departamento de expedição para solicitar uma mercadoria esta pessoa deve se identificar com seu documento de identidade. O profissional do departamento de expedição deve certificar-se que o documento é válido.
Para validar o documento fornecido pela pessoa o número do documento deverá ser validado no sistema da Secretaria de Segurança Pública do Estado de São Paulo, através de funcionalidade correspondente no módulo de controle de expedição. Se o documento não tiver como órgão emissor SSP-SP, não precisará ser validado, mas deverá ser microfilmado e ter uma cópia armazenada no sistema, através de funcionalidade específica. |
||
Obrigado pela leitura, espero que possa ter sido útil.
Fonte de informação: https://www.ateomomento.com.br/o-que-e-regra-de-negocio/
