MVP e Fluxo Digital - ifpebj-ti/controle-acesso-veiculos GitHub Wiki

MVP e Fluxo Digital — Controle de Acesso de Veículos

1. Identificação

Projeto: Controle de Acesso de Veículos
Instituição: Instituto Federal de Pernambuco — Campus Belo Jardim
Disciplina: Projeto Integrador — Práticas Reais de Software e Segurança
Equipe: José Ernandes Gonçalves Costa; Raíssa Beatriz Marinho dos Santos
Cliente inicial: Eurico Lopes — Setor de Transporte
Versão: 0.1
Status: Preliminar — pendente de validação
Data de referência: Agosto de 2026

Baseline de implementação — 29/08/2026: os primeiros recortes dos Formulários nº 01 e nº 02 estão implementados na API: autenticação, entrada, consulta e saída do fluxo geral, além de saída, consulta e retorno do fluxo institucional, além dos catálogos de frota e motoristas. Nome do condutor, placa, objetivo e categoria são obrigatórios no fluxo geral; documento e detalhes do veículo permanecem opcionais. Categorias, perfis e campos continuam hipóteses sujeitas à validação. A autorização explícita de motoristas reduz o cadastro ao necessário para o MVP. Transporte e Administração podem atualizar, desativar e reativar veículos sem exclusão física. Os históricos geral e institucional já podem ser consultados com período e filtros adequados a cada finalidade; telas operacionais ainda não foram implementadas.

2. Objetivo

Este documento define o escopo preliminar do MVP e o fluxo digital inicial para o sistema de Controle de Acesso de Veículos do IFPE Campus Belo Jardim.

O objetivo é transformar o processo atual baseado em formulários físicos em um fluxo digital mais simples, rastreável e útil, sem copiar automaticamente todos os campos e etapas existentes no papel.

O MVP deve preservar os controles necessários para a operação da portaria e do Setor de Transporte, reduzir retrabalho, facilitar consultas e permitir melhorias futuras.

3. Feedback do cliente

A equipe apresentou a evolução do projeto e recebeu retorno positivo sobre o levantamento de requisitos e a compreensão do funcionamento da portaria.

O cliente e os participantes compreenderam que:

O processo atual é baseado em formulários e controles manuais.
A situação da portaria foi levantada de forma suficiente para prosseguir.
A equipe possui liberdade para propor uma solução.
O sistema deve começar pelo fluxo atual de veículos.
As outras planilhas poderão ser incorporadas no futuro.
Nem tudo que existe no papel precisa ser levado para o sistema.
Os campos devem ser avaliados antes de se transformarem em telas ou tabelas.
O sistema deve melhorar o fluxo atual, e não apenas reproduzir a burocracia existente.

4. Princípios da digitalização

PD-01 — Digitalizar com finalidade

Cada campo ou etapa deve existir no sistema porque possui uma finalidade operacional, administrativa, de segurança, auditoria ou consulta.

PD-02 — Não copiar burocracia automaticamente

A existência de um campo no formulário físico não significa que ele deva ser obrigatório no sistema.

Antes da implementação, cada campo deverá ser avaliado quanto a:

Necessidade.
Finalidade.
Frequência de uso.
Impacto no atendimento.
Sensibilidade do dado.
Necessidade de consulta posterior.

PD-03 — Preservar o controle necessário

O sistema não deve remover informações necessárias para identificar veículos, condutores, motoristas, acessos, viagens ou responsabilidades.

PD-04 — Simplificar o atendimento

O fluxo digital deve reduzir digitação repetida, buscas manuais, retrabalho e preenchimento desnecessário.

PD-05 — Manter rastreabilidade

Alterações, correções, recusas e operações relevantes devem permanecer identificáveis.

PD-06 — Desenvolver por etapas

O primeiro incremento deve resolver o fluxo principal de veículos. Funcionalidades adicionais devem ser incorporadas somente após validação e priorização.

5. Escopo do MVP

5.1. Funcionalidades incluídas

O MVP deverá contemplar preliminarmente:

Autenticação básica de usuários.
Perfis de acesso básicos.
Cadastro de veículos.
Cadastro de pessoas relacionadas a veículos.
Associação entre pessoas e veículos.
Registro de entrada de veículo.
Registro de saída de veículo.
Registro de placa, quando aplicável.
Registro de condutor.
Registro de objetivo do acesso.
Classificação da situação do acesso.
Consulta de registros.
Consulta por placa.
Consulta por veículo.
Consulta por condutor ou motorista.
Consulta por data ou período.
Consulta de veículos sem saída registrada.
Registro de veículos institucionais.
Registro de motorista institucional.
Registro de quilometragem de saída e entrada.
Registro de itinerário institucional.
Conferência pelo Setor de Transporte.
Correção controlada de registros.
Histórico de alterações.
Registro do usuário responsável por cada operação.

5.2. Resultado esperado do MVP

O MVP deverá permitir que a equipe substitua ou apoie os principais registros dos Formulários nº 01 e nº 02, mantendo o controle de veículos e melhorando a consulta e a rastreabilidade.

O MVP não precisa representar todos os fluxos do campus nem todas as planilhas existentes.

6. Fora do escopo inicial

Não fazem parte do primeiro incremento:

Controle geral de pedestres.
Controle geral de visitantes sem veículo.
Controle de caminhadas sem veículo.
Controle de pessoas que entram para jogar bola sem veículo.
Controle geral de servidores sem relação com veículos.
Controle geral de terceirizados sem relação com veículos.
Gestão geral de crachás.
Reconhecimento facial.
Reconhecimento automático de placas.
Integração com câmeras.
Integração com sensores.
Integração com catraca ou cancela.
Liberação automática da portaria.
Controle de vagas.
Sistema completo de eventos.
Sistema completo de ocorrências.
Relatórios gerenciais avançados.
Integração com outros sistemas institucionais.
Migração completa dos cinco formulários não veiculares.

7. Funcionalidades parcialmente previstas

As funcionalidades abaixo podem ser incluídas de forma simples se forem validadas e não aumentarem excessivamente o MVP:

Registro de recusa de acesso.
Registro de permanência excepcional.
Registro básico de mototáxi.
Registro básico de eventos com veículos.
Registro básico de veículos de discentes residentes.
Ocorrência associada a um acesso.

Caso essas funcionalidades exijam fluxos complexos, deverão ser transferidas para uma versão posterior.

8. Formulários utilizados como referência

8.1. Formulário nº 01

O Formulário nº 01 controla a saída e a entrada de veículos do campus.

Campos identificados:

Data.
Porteiro.
Assinatura do porteiro.
Veículo.
Placa.
Quilometragem de saída.
Horário de saída.
Quilometragem de entrada.
Horário de entrada.
Motorista.
Itinerário.

Ele é a principal referência do fluxo de veículos institucionais.

8.2. Formulário nº 02

O Formulário nº 02 controla a entrada e a saída geral de veículos no campus.

Campos identificados:

Data.
Porteiro.
Assinatura do porteiro.
Nome completo do condutor.
Número de RG ou CPF.
Veículo.
Placa.
Horário de entrada.
Horário de saída.
Objetivo.

Ele é a principal referência do fluxo geral de veículos.

8.3. Formulários nº 03 a nº 07

Os Formulários nº 03 a nº 07 são relacionados a:

Pedestres.
Caminhada ou atividade física.
Visitantes.
Servidores.
Terceirizados.

Esses formulários ficam fora do MVP, mas poderão ser avaliados em futuras versões.

9. Campos do MVP

9.1. Campos que devem ser mantidos preliminarmente

Campo	Fluxo	Justificativa
Data	Geral e institucional	Identificar o dia da operação
Veículo	Geral e institucional	Identificar o veículo utilizado
Placa	Geral e institucional	Permitir identificação e consulta
Condutor	Geral	Identificar quem entrou com o veículo
Motorista	Institucional	Relacionar pessoa à viagem institucional
Horário de entrada	Geral	Registrar início do acesso
Horário de saída	Geral	Registrar encerramento do acesso
Objetivo	Geral	Registrar a finalidade do acesso
Quilometragem de saída	Institucional	Registrar a saída do veículo
Quilometragem de entrada	Institucional	Registrar o retorno do veículo
Itinerário	Institucional	Registrar o deslocamento informado
Usuário responsável	Todos	Rastrear quem realizou a operação
Status	Todos	Indicar situação do registro

9.2. Campos que dependem de confirmação

Campo	Motivo da pendência
RG ou CPF	Ainda precisa ser confirmada a necessidade e obrigatoriedade
Assinatura do porteiro	Pode ser substituída pelo usuário autenticado e auditoria
Tipo oficial do veículo	Os formulários utilizam descrição livre
Identificação patrimonial	Necessidade ainda não confirmada
Número de frota	Necessidade ainda não confirmada
Marca	Não aparece como campo confirmado nos formulários veiculares
Modelo	Não aparece como campo confirmado nos formulários veiculares
Cor	Não aparece como campo confirmado nos formulários veiculares
Telefone	Não possui finalidade confirmada no MVP
E-mail	Não possui finalidade confirmada no MVP
Tipo de vínculo	Necessidade ainda não definida

9.3. Campos possivelmente eliminados ou substituídos

A equipe poderá eliminar ou substituir:

Assinatura manual repetida, se o login autenticado fornecer rastreabilidade suficiente.
Campos duplicados entre formulários.
Descrições livres que possam ser padronizadas.
Informações sem uso posterior identificado.
Dados pessoais coletados apenas por hábito, sem finalidade validada.

Nenhum campo deve ser removido definitivamente sem validação quando possuir exigência institucional ou administrativa.

10. Fluxo digital de entrada geral

10.1. Fluxo principal

1. Veículo chega à portaria.
2. Usuário autenticado inicia um registro.
3. Sistema localiza o veículo pela placa ou permite cadastro.
4. Sistema localiza o condutor ou permite cadastro relacionado.
5. Usuário seleciona a categoria do acesso.
6. Usuário informa o objetivo.
7. Sistema registra data e horário de entrada.
8. Sistema valida os campos necessários.
9. Sistema salva o registro.
10. Sistema registra o usuário responsável.
11. Sistema confirma o acesso registrado.

10.2. Validações preliminares

O sistema deverá:

Impedir o salvamento sem os campos obrigatórios.
Alertar sobre placa inválida, se o formato for definido.
Alertar sobre veículo já presente no campus, quando aplicável.
Impedir duplicação acidental do registro.
Permitir correção controlada por usuário autorizado.

As regras de recusa ainda dependem de validação.

11. Fluxo digital de saída geral

11.1. Fluxo principal

1. Veículo chega à saída.
2. Porteiro ou vigilante inicia o encerramento.
3. Sistema localiza o registro aberto pela placa, veículo ou condutor.
4. Usuário confere o registro.
5. Sistema registra data e horário de saída.
6. Sistema altera o status para encerrado.
7. Sistema registra o usuário responsável.
8. Sistema registra a operação na auditoria.

11.2. Situações excepcionais

O sistema deverá sinalizar ou permitir registrar:

Registro de entrada não localizado.
Veículo sem saída registrada anteriormente.
Saída duplicada.
Horário inconsistente.
Veículo que permanece no campus.

O procedimento definitivo para cada situação ainda deve ser validado.

12. Fluxo de veículo institucional

12.1. Saída

1. Usuário seleciona veículo institucional.
2. Usuário informa ou seleciona o motorista.
3. Registra data de saída.
4. Registra horário de saída.
5. Registra quilometragem de saída.
6. Registra itinerário.
7. Confirma a saída.
8. Sistema altera a viagem para “em uso”.

12.2. Retorno

1. Usuário localiza a viagem em uso.
2. Confere o veículo e o motorista.
3. Registra data de entrada ou retorno.
4. Registra horário de entrada.
5. Registra quilometragem de entrada.
6. Sistema verifica a consistência da quilometragem.
7. Sistema encerra a viagem.
8. Sistema registra a auditoria.

12.3. Validações

Quilometragem de entrada não deve ser menor que a de saída, salvo correção autorizada.
Uma viagem em uso não deve possuir outra saída aberta para o mesmo veículo, salvo regra validada.
Uma viagem concluída não deve ser encerrada novamente.
O motorista deve estar relacionado ao registro.
O itinerário deve ser informado conforme a regra definida.

13. Fluxo de correção

1. Usuário autorizado localiza um registro.
2. Usuário escolhe corrigir.
3. Sistema solicita o motivo.
4. Usuário informa o novo valor.
5. Sistema mantém o valor anterior.
6. Sistema salva o novo valor.
7. Sistema registra usuário, data, horário e motivo.
8. Registro permanece disponível para conferência.

14. Perfis iniciais

Perfil	Permissões preliminares
Porteiro	Registrar entradas e saídas e consultar informações operacionais
Vigilante	Registrar saídas, permanências e apoiar a continuidade do processo
Setor de Transporte	Consultar, conferir, corrigir e pesquisar históricos
Administrador	Gerenciar usuários, perfis e parâmetros técnicos

Os perfis do Setor de Segurança e do SEGAI poderão ser incluídos após definição das necessidades.

15. Requisitos derivados do MVP

RF-MVP-01 — Cadastrar veículo

O sistema deve permitir cadastrar um veículo ou localizá-lo por placa, quando aplicável.

RF-MVP-02 — Cadastrar pessoa relacionada

O sistema deve permitir cadastrar uma pessoa quando ela estiver relacionada a um veículo.

RF-MVP-03 — Relacionar pessoa e veículo

O sistema deve permitir definir a relação entre pessoa e veículo.

RF-MVP-04 — Registrar entrada

O sistema deve permitir registrar entrada de veículo com os dados necessários à categoria.

RF-MVP-05 — Registrar saída

O sistema deve permitir registrar a saída de um veículo com entrada aberta.

RF-MVP-06 — Consultar acessos

O sistema deve permitir pesquisar registros por placa, veículo, condutor, motorista e período.

RF-MVP-07 — Consultar veículos presentes

O sistema deve permitir visualizar veículos que ainda não possuem saída registrada.

RF-MVP-08 — Registrar uso institucional

O sistema deve permitir registrar saída e retorno de veículo institucional.

RF-MVP-09 — Registrar quilometragem

O sistema deve permitir registrar quilometragem de saída e entrada no fluxo institucional.

RF-MVP-10 — Registrar itinerário

O sistema deve permitir registrar o itinerário do veículo institucional.

RF-MVP-11 — Controlar perfis

O sistema deve restringir operações conforme o perfil do usuário.

RF-MVP-12 — Registrar auditoria

O sistema deve registrar as operações relevantes e as correções realizadas.

16. Impactos no Modelo de Dados

O MVP utiliza preliminarmente as entidades:

Pessoa.
Veículo.
PessoaVeiculo.
CategoriaAcesso.
RegistroAcesso.
UsoVeiculoInstitucional.
Usuário.
Perfil.
Auditoria.

As entidades Evento, Mototáxi, PermanenciaVeiculo e Ocorrencia somente deverão ser adicionadas ao modelo principal se os respectivos fluxos forem aprovados para o MVP.

A revisão do modelo deverá avaliar:

Campos realmente obrigatórios.
Campos removidos do fluxo digital.
Necessidade de RG ou CPF.
Significado do campo “veículo”.
Uso de categoria de acesso.
Relação entre registro geral e viagem institucional.
Status dos registros.
Auditoria.

17. Melhorias em relação ao papel

O fluxo digital deverá buscar as seguintes melhorias:

Evitar repetição de dados já cadastrados.
Permitir localizar veículo pela placa.
Evitar rasuras e recópias de formulários.
Manter histórico de correções.
Mostrar veículos sem saída.
Facilitar a localização de motoristas.
Padronizar tipos de veículos, quando definidos.
Reduzir a dependência de planilhas desatualizadas.
Facilitar a conferência pelo Setor de Transporte.
Reduzir o tempo de busca de documentos antigos.
Identificar o usuário responsável por cada operação.

18. O que ainda não deve ser decidido

Ainda não devem ser definidos definitivamente:

Stack tecnológica.
Banco de dados específico.
Obrigatoriedade de RG ou CPF.
Lista definitiva de tipos de veículos.
Permissões finais de todos os setores.
Prazo de retenção digital.
Fluxo completo de eventos.
Fluxo completo de mototáxis.
Fluxo de discentes residentes.
Integração com equipamentos.

19. Pendências para validação

RG ou CPF será obrigatório?
A placa será obrigatória em todos os acessos?
O que significa exatamente o campo “veículo”?
Quais tipos oficiais de veículo serão utilizados?
O objetivo será texto livre ou lista?
O itinerário representa destino, trajeto ou ambos?
A assinatura manual será substituída pelo usuário autenticado?
Quais campos podem ser eliminados?
Quais campos são exigidos por norma?
O vigilante terá as mesmas permissões do porteiro?
Como tratar registro sem saída?
Como tratar veículo que permanece no campus?
Quais funções entram no primeiro incremento?
O Setor de Transporte precisa de relatórios ou apenas consultas?

20. Relação com os documentos existentes

Documento	Impacto
Processo Atual da Portaria	Mantém a descrição do processo existente e registra pontos de melhoria
Visão do Projeto	Deve incorporar o MVP consolidado
Requisitos e Backlog	Deve receber os requisitos RF-MVP
Regras de Negócio	Deve ser revisado conforme decisões aprovadas
Modelo de Dados	Deve ser ajustado aos campos realmente mantidos
Arquitetura	Deve ser criada com base neste fluxo digital
Segurança e Privacidade	Deve considerar somente os dados necessários
Estratégia de Testes	Deve testar os fluxos do MVP

21. Próximas etapas

Revisar este documento com a equipe.
Confirmar o MVP com o cliente.
Identificar campos que serão eliminados ou mantidos.
Atualizar Requisitos e Backlog.
Atualizar Regras de Negócio.
Revisar o Modelo de Dados.
Criar a Arquitetura Inicial.
Consolidar Segurança e Privacidade.
Criar critérios de aceite definitivos.
Transformar o MVP em issues técnicas.
Escolher a stack após discussão da equipe.
Planejar o primeiro incremento.

22. Status final

Documento: MVP e Fluxo Digital — Controle de Acesso de Veículos.

Versão: 0.1.

Status: Preliminar — pendente de validação.

Origem: Feedback da apresentação, análise dos sete formulários, Requisitos e Backlog, Regras de Negócio e Modelo de Dados.

Foco: Formulários nº 01 e nº 02.

Validação pelo cliente: Feedback positivo recebido; escopo detalhado ainda pendente de confirmação.

Arquitetura: Ainda não definida.

Implementação: Ainda não iniciada.

Responsáveis:

José Ernandes Gonçalves Costa.
Raíssa Beatriz Marinho dos Santos.