Não confunda regra de negócio com função
Na preparação de um profissional para o exame CFPS, trocamos algumas ideias, cuja conclusão pode ser resumida em termos gerais como “Não confunda regra de negócio como função”. Tudo começou quando na análise de uma tela de entrada, identificam-se requisitos exigindo consultas.
Surgiram questões como:
- Quando uma consulta, para efeitos de validação ou para efeitos de recuperação de dados deve ser considerada uma CE dentro de uma EE?
- Por que não posso considerar como uma CE a consulta a base de CPF/CNPJ do SPC e SERASA ao validar uma entrada de dados para registro da venda de um imóvel? Afinal, se houver erro a encontrado a transação se conclui.
O objetivo do usuário na perspectiva de sua tarefa ou serviço
Inicialmente, cabe lembrar, nem todo requisito do usuário é mapeado para uma função na Análise de Pontos de Função. Afinal, requisitos tem diferentes granularidades. E a granularidade adequada para avaliar sua medição é a granularidade do Processo Elementar.
Não se deve considerar a consulta ao CPF/CNPJ nas Bases de Restrições do SPC e do SERASA como uma função se o objetivo do usuário é “Registrar a Venda de um Imóvel”. Para considerar a consulta como uma função, deveria haver um requisito funcional especificamente abordando o objetivo do usuário consultar os dados do SPC e do SERASA.
O que é uma Regra de Negócio
Em seguida, é válido revermos o que seja uma regra de negócio no contexto dos requisitos de software. Para esse fim, remetemos à norma ISO/IEC/IEEE 29.148, porque padroniza os processos de Engenharia de Requisitos. Em especial o item a seguir:
9.3.10 Regras e políticas operacionais de negócio
Descreve proposições lógicas aplicadas na condução de processos de negócio. As proposições serão condições para iniciar, desdobrar e terminar a sequência das atividades de negócio no processo de negócio; critérios para julgamento em processos de negócio; ou fórmula para avaliar uma quantidade, a qual provavelmente será abordada em requisitos funcionais na SyRS e SRS. As políticas e regras devem ser nomeadas de maneira única e numeradas, e devem ser referenciadas na descrição dos processos de negócio.
Ainda que nosso objetivo ao medir pontos de função não seja especificar requisitos conforme a ISO/IEC/IEEE 29.148, ela nos é útil. Sua utilidade é caracterizar o comportamento relativo à obtenção dos dados no SPC e SERASA como parte de uma Regra de Negócio. Afinal, trata-se de dotar a aplicação de critérios para julgamento em processos de negócio como descrito na norma.
Não devemos confundir uma regra de negócio com uma função
A consulta ao CPF/CNPJ em questão não atende à condição necessária para identificação de um processo elementar de ser AUTOCONTIDA. A norma ISO/IEC 20926, primeira parte do Manual de Práticas de Contagem (CPM), define autocontido como:
3.7
autocontido
nenhum passo anterior ou subsequente é necessário para iniciar ou concluir o(s) Requisito(s) Funcional(is) do Usuário
EXEMPLO O Requisito Funcional do Usuário estabelece que um empregado deve ser incluído e atualizado. Poderiam existir várias partes que comporiam o conjunto completo de informações do empregado. Isto pode ser representado por telas físicas, janelas ou abas distintas, tais como
— Identificação do empregado,
— Localização do empregado,
— Informações de dependentes,
— Informações de salário e
— Instrução.
Para incluir um empregado, uma ou mais abas devem ser preenchidas, dependendo das regras de negócio. O
processo de inclusão não estará autocontido até que todas as informações obrigatórias tenham sido digitadas e
recebidas pelo sistema.
Para atualizar um empregado, uma ou mais abas podem ser atualizadas a qualquer momento, mas todas elas
constituem passos do processo que satisfaz o Requisito Funcional do Usuário, de atualização do empregado.
Incluir, alterar ou excluir informações de cada aba individual não constituem processos elementares distintos, mas sim passos de processo envolvidos na atualização de um empregado. Embora seja possível entrar com informações adicionais no registro de empregado, o conjunto total de informações é considerado parte do único
processo elementar: atualizar empregado. Incluir Empregado e Atualizar Empregado seriam, cada um, um processo autocontido.
O comportamento relativo à “obtenção da situação com determinado CPF/CNPJ no SPC e SERASA” está inserido como parte do comportamento mais abrangente descrevendo a busca do usuário pelo seu objetivo de registrar a venda do imóvel.
Portanto, se requer passos anteriores e posteriores à recuperação dos dados para atingir o objetivo do usuário de Registrar a Venda do Imóvel. Ou seja, a consulta é uma lógica de processamento para forçar uma regra de negócio. Dentre o elenco de tipos de lógica de processamento previstos no CPM, ela corresponde à sétima:
7. Um ou mais ALIs ou AIEs são referenciados
EXEMPLO 7 Ao incluir um empregado, o AIE de moeda é referenciado para obter a taxa de conversão para o dólar norte-americano, a fim de determinar o salário-hora dos empregados.
Uma transação deve incluir como parte de seu comportamento todos os cenários possíveis
Sobre o argumento de que:
…se o CPF tem restrição o processo de venda termina. Afinal, se estiver com restrição, a venda do imóvel não poderá ser efetuada e a aplicação informa ao usuário o fato e bloqueia a venda para aquele cliente, que é marcado automaticamente a situação de bloqueado
A identificação de um processo elementar tem como condição necessário de seu comportamento constituir uma transação completa. Isso quer dizer, que a função correspondente contém todos os cenários; inclusive os cenários de erro, que impedem o progresso em direção ao objetivo do usuário.
Quanto à atualização do registro do cliente indicando sua situação como bloqueado, essa não corresponde ao objetivo no nível da tarefa do usuário. O evento externo, que motivou a transação, não foi o objetivo do usuário em atualizar a situação do cliente como bloqueado.
Talvez, até possa existir uma transação especificamente para esse fim. Mas não é a presença de processamento similar como uma regra de negócio em outra função, o que motive a medição de uma função especificamente para esse fim.
O objetivo do usuário não é o erro ou o bloqueio; o objetivo do usuário é registrar a venda. E trata-se de uma lógica de processamento para forçar uma regra de negócio do tipo:
5. Condições são analisadas para determinar as aplicáveis
EXEMPLO 5 A lógica de processamento utilizada pelo processo elementar na inclusão de um empregado depende do mesmo ser mensalista ou horista. A entrada dos DERs (e a lógica de processamento resultante) com base em uma escolha distinta (mensalista ou horista) é parte de um processo elementar neste exemplo.
Um contra exemplo
Um caso no qual podemos, sim, identificar em uma mesma tela de entrada consultas medidas como CE ou SE:
- Há uma lista de requisitos onde o cliente deseja informar um CPF e, em resposta, o sistema apresenta ao usuário a sua situação junto ao SERASA em uma relatório ou formulário.
- O projeto da interface com o usuário implementa o requisito acima como um diálogo modal. Algumas telas, nas quais se antecipa a necessidade do usuário obter a informação em questão, permite o acionamento do diálogo modal já aproveitando o CPF informado na tela de entrafda
Neste caso, haveria a inclusão de uma função de CE/SE para esse fim no escopo de medição.
