segunda-feira, 15 de novembro de 2010

Regra de Negócio Não é Requisito de Software

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Um dos problemas mais comuns que encontro no gerenciamento de requisitos é a dificuldade que os analistas de negócio (analistas de requisitos ou de sistemas) têm em diferenciar requisitos funcionais de regras de negócio.

Segundo Leffingwell, “requisito de software é uma condição ou capacidade que deve ser atendida pelo sistema”. O IEEE estende um pouco mais essa descrição: “É uma condição ou capacidade que deve ser atendida pelo software, necessária a um usuário para solucionar um problema ou atender a um objetivo”.

O RUP define Regra de Negócio como “declarações sobre políticas ou condições que devem ser satisfeitas”. Note que, ao contrário do requisito, a descrição de regra de negócio não afirma que deve ser satisfeita pelo sistema (software). Regra de negócio é uma restrição imposta pelo negócio que regulamenta o comportamento de um procedimento operacional do negócio. São políticas definidas pela administração da empresa. São originárias das leis, portarias e normas definidas por órgãos governamentais.

Regras de negócio têm vida totalmente independente de sistemas. Podem ser criadas e obedecidas sem uso de sistemas. Como exemplo, podemos citar uma microempresa totalmente desprovida de computadores ou qualquer tipo de automação de processos de negócio. A administração da empresa definiu como política, que a venda a prazo só poderá ser feita para clientes adimplentes. Note que essa política restringe as operações de venda da empresa e não precisa de sistema para ser atendida.

Como se vê, uma regra de negócio pertence somente ao domínio do negócio. Entretanto, nada impede que regras de negócio venham a ser automatizadas, isto é, seja realizada por um sistema. Neste caso deverá haver alguma funcionalidade, ou seja, algum requisito funcional que realizará a regra de negócio.

Vamos supor que a administração da empresa (do nosso exemplo) resolva automatizar o processo de vendas. Assim, o sistema deverá possuir uma funcionalidade que conterá uma condição (“IF THEN ESE”) a qual irá verificar se o cliente é adimplente. Se for adimplente, então o sistema permitirá a venda. Caso contrário o sistema irá bloquear a venda para o cliente em foco.

Portanto, uma regra de negócio pode ser expressa no formato “IF THEN ELSE”. Isso não quer dizer, também, que todo IF THEN ELSE implícito em um fluxo de eventos dentro de um caso de uso represente uma regra de negócio. Um caso de uso pode ter implicitamente um ou mais IF THEN ELSE que não corresponda a regras de negócio, mas que conduzam a variações de comportamento do caso de uso.

Como exemplo, podemos citar um caso de uso de cadastramento de cliente, onde um evento do fluxo básico verifica que o cliente já está cadastrado. O analista de requisitos define um fluxo alternativo para descrever o comportamento adequado que impeça o cadastramento redundante do cliente. Note que existe, implicitamente, um IF THEN ELSE, o qual não corresponde a uma regra de negócio. Corresponde a uma restrição de integridade de banco de dados que impede redundância de clientes. Como se vê, nem todo IF THEN ELSE corresponde a uma regra de negócio, Contudo, toda regra de negócio pode ser descrita na forma na forma de IF THEN ELSE.

Em resumo, podemos caracterizar uma regra de negócio da seguinte forma:
• A sentença que descreve uma regra de negócio não possui um caráter verbal. Sua abordagem é restritiva. Sempre possui termos tais como, “se”, “sempre que”, “somente”, “só” ou “quando”.
• Restringe o processo operacional da empresa.
• É percebida pela administração da empresa.
• Não descreve como a regra será verificada nem como as operações deverão ser realizadas. Descreve somente o que o processo irá executar em função da regra.
• Sua descrição não pode conter elementos de soluções de tecnologia. Se você estiver descrevendo uma regra de negócio e sentir a necessidade de referenciar uma solução de sistema, com certeza se trata de um requisito de software e não de uma regra de negócio.
• Tem vida própria. Poderia ser atendida sem uso de sistema.
• Pertence ao domínio do negócio e não do sistema.
• Pode ser descrito no formato “IF THEN ELSE”.

Para concluir gostaria de salientar que uma regra de negócio não é um requisito funcional, mas um requisito funcional pode realizar uma regra de negócio.

7 comentários:

Marcos PP disse...

Mais claro do que isso é impossível. Post muito bem escrito e muito bem explicado. Didático e fácil de entender.
É uma pena os analistas prestarem atenção somente em botões e telas.

Elcio Silva de Paula disse...

Não acredito que os analistas prestem atenção em botões e telas. Os que assim fizerem estão fora do mercado...

Joabe disse...

Muito Bacana o Post. Tirou minhas dúvidas para fazer uma prova de ES.
Já coloquei o blog no meus favoritos.

Patricia disse...

Também gostei muito. Tirou minhas dúvidas sobre o assunto. Coloquei no favoritos também!

Evandro Moreira Pinto disse...

Patrícia, muito obrigado.

Marcos Ohashi disse...

Sempre defendi esta tese de que regra independe de sistema. Na empresa que trabalho, costuma-se colocar os campos das telas dentro da regra. Tudo o que não é colocado em caso de uso colocam em regra. É triste! Mas o post é bem esclarecedor. Parabéns!

Evandro Moreira Pinto disse...

Marcos Ohashi.
Obrigado pelo comentário. Realmente, você tem razão. A grande maioria dos Analistas de Negócio nas empresas ainda não conseguiu separar Regras de Negócio de Requisitos. Que bom que você compreendeu.
Estou descontinuando meu blog neste endereço. Acesse o novo endereço: www.wm2info.com.br.
Abraço.