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á.
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.
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.
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.
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.
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.
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.