Ir para o conteúdo principal

Cadastro de Pessoas Físicas sem CPF

Necessidade

Avaliar o impacto da implementação de cadastro de pessoas físicas com CPF opcional usando o Pentagono.

Problemática

O Pentagono surgiu da necessidade de centralizar os dados de pessoas físicas e jurídicas visando maximizar o uso recursos na implementação de formulários de captação desses dados (aumento de eficiência produtiva), bem como possibilitar a gestão desses dados à luz da LGPD (eficácia).

Nesse cenário, CPF e CPNJ foram definidos como dados obrigatórios, além do nome. Enquanto os demais dados teria seu uso, de forma obrigatório ou opcional, tratados individualmente em cada aplicação.

No mundo de volatilidade, incerteza, complexidade e ambiguidade foi lançado um MPV que proporcionou validar se as regras de negócio implementadas na aplicação atenderiam ao máximos de cenários possíveis, senão todos, sob o escopo inicial do projeto. E a resposta foi um esperado NÃO.

A exemplo do programa Regulariza Já!, onde é preciso informar apenas o nome de indivíduos que coabitam no imóvel a regularizar, ou, a exemplo de diversos outros sistemas, onde é preciso informar a filiação (nomes do pai e da mãe), o CPF deixa de ser um dado obrigátorio.

Isto é, nesses contextos não poderia ser requerido esse dado pessoal, o CPF, pois ele não teria nenhuma utilidade naquele negócio.

Por outro lado, não possibilitar o cadastro de pessoas sem informar o CPF, as aplicações teriam que implantar em base de dados própria a partir de formulários especializados a coleta, armazenamento e todo o tratamento de dados dessas pessoas contrariando as premissas do projeto do Pentágono: aumento de eficiência produtiva e eficácia na gestão de dados pessoais.

Sobre possibilidades do Pentágono contemplar esses cadastros sem CPF e CPNJ, é o que segue.

 

Solução

Atualmente, para cadastrar um parente, o usuário deve pesquisar uma pessoa já existente na base de dados e definir como parente.

Se não encontrar, o parente deve ser cadastrado como um nova pessoa e só então que o fluxo acima poderá ser refeito. Veja no fluxograma abaixo.

untitled@2x.png

No banco de dados, as entidades se apresentam como no diagrama abaixo.

image-1621364707169.png

A solução proposta implica em um novo fluxo, ou seja, caso não encontre o parente na base de dados, o usuário deverá informar o nome e, opcionalmente o CPF, que o sistema irá registrar em sua base de dados e o definirá como parente. Veja o fluxograma proposto:

untitled@2x (1).png

No banco de dados, as entidades se apresentariam, para solução proposta, como no diagrama abaixo.

image-1621364715533.png

 

User Stories

Eu, como Desenvolvedor, preciso refatorar a tabela de parentes. Para salvar registros de pessoas sem CPF.

  • Produto: e-Estado;
  • Complexidade: 2 pts;
  • Regra: Refatorar a tabela de parentes para registrar nome de pessoas sem CPF e fazer o relacionamente, se for o caso, com pessoas físicas.
  • Cenário: Sem cenário.

Eu, como Desenvolvedor, preciso criar uma pessoa sem CPF na minha aplicação. Para atender à regra de negócio do sistema.

  • Produto: API PentágonoPessoas;
  • Complexidade: 5 pts;
  • Regra: Quando não encontrar a pessoa desejado, o usuário deverá informar o nome e, opcionalmente, o CPF para que seja criada uma nova pessoa na base de dados. O relacionamente de pessoas com pessoa permanece.
  • Cenário: API atualizada e publicada na Central do Desenvolvedor.

Eu, como Desenvolvedor, preciso da documentação da API Pentágono atualizada. Para entender como se implementa cadastro de pessoas sem CPF.

  • Produto: API PentágonoPessoas;
  • Complexidade: 1 pt;
  • Regra: Atualizar as rotas referentes a parentesco, ou quais outros endpoints que fazem relacionamento de pessoa com pessoa, na documentação da API.
  • Cenário: Documentação da API atualizada e publicada na Central do Desenvolvedor.

Eu, como usuário, preciso cadastrar o nome do meu parente quando não o econtrar na base de dados. Pois não sei do CPF dele.

  • Produto: e-Estado;
  • Complexidade: 3 pts;
  • Regra: Quando não encontrar a pessoa desejado, o usuário deverá informar o nome e, opcionalmente, o CPF para que seja criada uma nova pessoa na base de dados. O relacionamente de pessoas com pessoa permanece.
  • Cenário: Dado que João não sabe o CPF de seus pais, quando for informá-lo no seu cadastro, então ele vai preencher somente com o nome e pronto!

 

    Eu, como usuário, preciso me cadastrar como parente no cadastro dele. Pois eu o vinculei como meu parente.

    • Produto: e-Estado;
    • Complexidade: 3 pts;
    • Regra: Quando uma Pessoa Física A for vinculada no cadastro da Pessoa Física B, então vincular automaticamente a Pessoa Física B ao cadastro da Pessoa Física A.
    • Cenário: Dado que João é filho de José, então Jóse será pai de João.

     

      Eu, como usuário, preciso definir os relacionamentos entre parentes. Para que possa fazer vínculos automáticos entre pessoas físicas.

      • Produto: e-Estado;
      • Complexidade: 3 pts;
      • Regra: Na edição do Parente, relacionar ele com outro parente. Ex.: Pai <-> filho(a); Irmã/Irmão <-> Irmã/Irmão. No caso de relacionamentos envolvendo filho(a):
        • 1) Verificar o sexo da pessoa mãe/pai do filho(a);
        • 2) Se o sexo = Masculino, adicionar a pessoa como pai do filho;
        • 3) Se o sexo = Feminino, adicionar a pessoa como mãe do filho.
      • Cenário:
        • Dado que João é filho de Darci (sexo masculino), então Darci será pai de João.
        • Dado que João é filho de Darci (sexo feminino), então Darci será mãe de João.

       

        Eu, como RH, preciso ver os dependentes do servidor. Pois eu o vinculei-os como seus parentes.

        • Produto: e-RH;
        • Complexidade: 3 pts;
        • Regra: Listar todos os dependentes do servidor na sua ficha funcional. 
        • Cenário: Dado que João é filho de Darci, então o RH consegue ver João na ficha funcional de Darci.

         

        Impactos

        A implementação que altera o escopo do projeto Pentágono paralizará qualquer projeto em andamento tendo em vista sua complexidade e esforço estimado.

        • Total de User Stories: 4;
        • Total de Pontos de Complexidade: 11 pts.

        No mais, concluímos que a implementação é possível e viável.

         

        Envolvidos

        • Diego Barros de Oliveira (Software Developer)
        • Diego Gonçalves de Almeida (Software Developer)
        • Edson Masami Hiraçaka (Scrum Master)
        • Jônatas Justiniano Lima (Product Owner)