Requisitos e Backlog

Baseline vigente — 28/09/2026 (versão 0.4): o MVP técnico veicular está integrado na main, incluindo autenticação renovável, contas, fluxos geral e institucional, eventos, resumo diário, auditoria, correção descritiva e encerramento excepcional. Documento pessoal e detalhes do veículo permanecem opcionais por minimização. O backlog vivo e suas decisões posteriores estão nas Issues; a homologação formal permanece na Issue #162. Consulte Status do Projeto para a evidência canônica.

1. Objetivo

Este documento reúne os requisitos, histórias de usuário, critérios de aceite, prioridades, pendências e itens do backlog relacionados ao sistema de Controle de Acesso de Veículos do IFPE Campus Belo Jardim.

Os requisitos foram elaborados a partir de:

• Conversas com porteiros da portaria.
• Conversa com uma porteira em início de atividade.
• Reunião com Eurico Lopes, do Setor de Transporte.
• Análise dos sete formulários disponibilizados pelo Setor de Transporte.
• Observações sobre troca de turno, horários de pico e arquivamento.
• Problemas identificados no processo manual.
• Feedback recebido após a apresentação da evolução do projeto.
• Documento preliminar de MVP e Fluxo Digital.
• Regras de Negócio.
• Modelo de Dados preliminar.

O foco inicial é digitalizar e melhorar o processo de controle de veículos, principalmente os fluxos representados pelos Formulários nº 01 e nº 02.

O sistema não deverá copiar automaticamente todas as planilhas existentes. Cada campo e etapa deverá ser avaliado conforme sua finalidade, necessidade operacional, impacto no atendimento, proteção de dados e utilidade para consultas futuras.

2. Feedback do cliente

Após a apresentação da evolução do projeto, o levantamento foi compreendido e recebeu retorno positivo.

Foi informado ou percebido que:

• O funcionamento atual da portaria foi compreendido.
• O processo manual baseado em formulários foi considerado relevante.
• A equipe pode continuar o projeto.
• O sistema deve começar pelo fluxo atual de veículos.
• As outras planilhas poderão ser incorporadas futuramente.
• Nem todas as informações existentes no papel precisam ser transferidas para o sistema.
• A equipe deve avaliar o que realmente faz sentido digitalizar.
• O sistema deve melhorar o processo atual, e não apenas reproduzir a burocracia dos formulários.
• O primeiro incremento deve possuir escopo controlado.

3. Princípios dos requisitos

Os requisitos devem seguir os seguintes princípios:

PR-01 — Digitalização com finalidade

Cada campo implementado deve possuir uma finalidade operacional, administrativa, de segurança, auditoria ou consulta.

PR-02 — Não copiar burocracia

A existência de um campo no formulário físico não torna esse campo automaticamente obrigatório no sistema.

PR-03 — Preservar o controle necessário

O sistema deve manter os dados necessários para identificar veículos, condutores, motoristas, acessos, viagens, horários e responsabilidades.

PR-04 — Simplificar o atendimento

O sistema deve reduzir digitação repetida, consultas manuais, retrabalho e preenchimento desnecessário.

PR-05 — Manter rastreabilidade

Correções e operações relevantes devem preservar o histórico da ação.

PR-06 — Desenvolver por etapas

O primeiro incremento deve resolver o fluxo principal de veículos. Funcionalidades complementares deverão ser adicionadas depois de avaliadas e priorizadas.

4. Escopo dos requisitos

O projeto está direcionado ao controle de acesso e movimentação de veículos.

O sistema deverá considerar pessoas quando elas estiverem relacionadas a um veículo, como:

• Condutor.
• Motorista institucional.
• Responsável pelo veículo.
• Passageiro, quando necessário.
• Responsável por uma autorização veicular.
• Responsável por veículo de evento.

O sistema não terá como foco principal:

• Controle geral de visitantes que entram a pé.
• Cadastro geral de pedestres.
• Cadastro geral de participantes de caminhadas sem veículo.
• Controle geral de pessoas que entram para jogar bola sem veículo.
• Controle independente de servidores sem relação com veículos.
• Controle independente de terceirizados sem relação com veículos.
• Gestão geral de crachás.
• Controle completo da circulação de pessoas no campus.

5. Formulários analisados

Foram recebidos e analisados sete formulários:

Número	Formulário	Relação com o projeto
01	Controle de saída e entrada dos veículos do campus	Núcleo inicial
02	Controle geral de entrada e saída de veículos	Núcleo inicial
03	Controle de entrada e saída de pedestres	Contexto ou expansão futura
04	Controle de entrada e saída de pedestres para caminhada ou atividade física	Contexto ou expansão futura
05	Controle de entrada e saída de visitantes	Contexto ou expansão futura
06	Controle de entrada e saída de servidores	Contexto ou expansão futura
07	Controle de entrada e saída de terceirizados	Contexto ou expansão futura

5.1. Formulário nº 01

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.

Esse formulário é a principal referência para veículos institucionais.

5.2. Formulário nº 02

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.

Esse formulário é a principal referência para o fluxo geral de entrada e saída de veículos.

6. Definição preliminar do MVP

O MVP será a primeira versão funcional capaz de resolver o problema principal da portaria: registrar e consultar entradas e saídas de veículos, controlar veículos institucionais e manter histórico das operações.

6.1. Funcionalidades incluídas

O MVP deverá contemplar preliminarmente:

• Autenticação básica de usuários.
• Perfis básicos de acesso.
• Cadastro de veículos.
• Cadastro de pessoas relacionadas a veículos.
• Associação entre pessoas e veículos.
• Registro de entrada.
• Registro de saída.
• Registro de placa, quando aplicável.
• Registro de condutor.
• Registro de motorista institucional.
• Registro de objetivo.
• 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 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 pela operação.

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

A solução deverá:

• Reduzir a dependência de formulários físicos.
• Reduzir o retrabalho causado por rasuras.
• Facilitar a localização de registros.
• Mostrar veículos que ainda não registraram saída.
• Facilitar a identificação de motoristas.
• Apoiar a conferência do Setor de Transporte.
• Manter histórico das alterações.

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

7. Funcionalidades parcialmente previstas

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

• 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.
• Registro de ocorrência associada a um acesso.

Caso esses fluxos exijam regras complexas, deverão ser transferidos para uma versão posterior.

8. Fora do MVP

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 Formulários nº 03 a nº 07.

9. Classificação dos requisitos

Classificação	Significado
Confirmado em documento	Informação identificada diretamente nos formulários analisados.
Confirmado em reunião	Informação validada verbalmente por responsável pelo processo.
Informado	Informação relatada por participante, ainda sujeita a confirmação.
Preliminar	Necessidade ou decisão inicial utilizada para orientar o projeto.
Proposta	Solução sugerida, ainda não pertencente ao processo atual.
Pendente	Informação que precisa ser esclarecida antes da implementação definitiva.
Futuro	Possível evolução posterior.
Fora do escopo	Item que não pertence ao primeiro incremento.

10. Prioridades

Prioridade	Significado
Alta	Necessário para o fluxo principal do MVP.
Média	Importante, mas pode ser implementado após o fluxo principal.
Baixa	Útil, mas não essencial para a primeira versão.
Futuro	Evolução posterior ou dependente de infraestrutura e validações.

11. Requisitos funcionais do MVP

RF-MVP-01 — Cadastrar veículo

Prioridade: Alta.

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

O sistema deve permitir cadastrar um veículo ou localizar um veículo já existente.

Dados preliminares:

• Placa.
• Tipo ou classificação.
• Identificação do veículo.
• Indicação de veículo institucional.
• Situação do cadastro.

O significado exato do campo “veículo” ainda precisa ser confirmado.

RF-MVP-02 — Cadastrar pessoa relacionada

Prioridade: Alta.

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

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

Possíveis relações:

• Condutor.
• Motorista institucional.
• Responsável.
• Passageiro.
• Usuário autorizado.

O sistema não deverá exigir o cadastro geral de todas as pessoas que entram a pé no campus.

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

Prioridade: Alta.

O sistema deve permitir associar uma pessoa a um veículo, indicando o tipo de relação.

RF-MVP-04 — Registrar entrada de veículo

Prioridade: Alta.

O sistema deve permitir registrar a entrada de um veículo.

Dados preliminares:

• Veículo.
• Placa.
• Condutor.
• Data.
• Horário de entrada.
• Objetivo.
• Categoria do acesso.
• Usuário responsável.

RF-MVP-05 — Registrar saída de veículo

Prioridade: Alta.

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

O sistema deverá localizar o acesso por critérios como:

• Placa.
• Veículo.
• Condutor.
• Registro aberto.

RF-MVP-06 — Consultar registros

Prioridade: Alta.

O sistema deve permitir consultar registros por:

• Placa.
• Veículo.
• Condutor.
• Motorista.
• Data.
• Período.
• Objetivo.
• Categoria.
• Status.
• Itinerário.

RF-MVP-07 — Consultar veículos sem saída

Prioridade: Alta.

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

RF-MVP-08 — Registrar objetivo

Prioridade: Alta.

O sistema deve permitir registrar a finalidade do acesso.

O formato do campo ainda deverá ser definido:

• Texto livre.
• Opções predefinidas.
• Combinação entre categoria e observação.

RF-MVP-09 — Classificar acesso

Prioridade: Alta.

O sistema deverá permitir classificar a situação do acesso.

Categorias preliminares:

• Visitante com veículo.
• Terceirizado com veículo.
• Veículo institucional.
• Discente residente.
• Evento.
• Treino ou jogo.
• Caminhada com veículo relacionado.
• Mototáxi.
• Permanência excepcional.
• Outro acesso autorizado.

A lista final precisa ser validada.

RF-MVP-10 — Registrar veículo institucional

Prioridade: Alta.

O sistema deve permitir registrar a utilização de um veículo institucional.

Dados:

• Veículo.
• Placa, se aplicável.
• Motorista.
• Data de saída.
• Horário de saída.
• Quilometragem de saída.
• Itinerário.
• Data de retorno, se aplicável.
• Horário de entrada.
• Quilometragem de entrada.
• Status da viagem.

RF-MVP-11 — Registrar quilometragem

Prioridade: Alta.

O sistema deve permitir registrar:

• Quilometragem de saída.
• Quilometragem de entrada.

O sistema deverá alertar quando a quilometragem de entrada for inferior à quilometragem de saída, salvo correção autorizada.

RF-MVP-12 — Registrar itinerário

Prioridade: Alta.

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

Ainda precisa ser definido se o itinerário representa:

• Destino.
• Trajeto.
• Lista de locais.
• Outra informação administrativa.

RF-MVP-13 — Consultar motorista relacionado a viagem

Prioridade: Alta.

O sistema deve permitir localizar o motorista relacionado a um veículo em determinada data ou período.

Esse requisito responde à dificuldade relatada na localização do motorista relacionado a uma multa antiga.

RF-MVP-14 — Conferir registros

Prioridade: Alta.

O Setor de Transporte deve conseguir consultar e conferir registros realizados pela portaria.

O primeiro incremento desse requisito oferece um resumo agregado por dia local institucional, com entradas, saídas, usos institucionais, acessos associados a eventos e registros já abertos no começo ou ainda abertos no fim do dia. A data é opcional, a consulta não expõe dados pessoais ou de veículos e não transforma jornada de 12 horas ou fechamento por volta das 23h em bloqueios automáticos.

Implementação: Issue #86 e PR #87; validação com o cliente pendente.

RF-MVP-15 — Controlar permissões

Prioridade: Alta.

O sistema deve diferenciar as permissões dos usuários.

Perfis preliminares:

• Porteiro.
• Vigilante.
• Setor de Transporte.
• Administrador.

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

RF-MVP-16 — Registrar usuário responsável

Prioridade: Alta.

O sistema deve registrar o usuário responsável por:

• Criar um registro.
• Alterar um registro.
• Registrar uma entrada.
• Registrar uma saída.
• Conferir um registro.
• Corrigir uma informação.
• Registrar uma recusa, caso essa função esteja no MVP.

RF-MVP-17 — Corrigir registro

Prioridade: Alta.

O sistema deve permitir corrigir registros conforme as permissões do usuário.

A correção deve preservar:

• Usuário.
• Data.
• Horário.
• Campo alterado.
• Valor anterior.
• Novo valor.
• Motivo.

RF-MVP-18 — Validar campos

Prioridade: Alta.

O sistema deve validar os campos necessários antes de confirmar uma operação.

12. Requisitos funcionais posteriores

RF-FUT-01 — Registrar permanência excepcional

Prioridade: Média ou futuro.

Permitir registrar veículos que permanecem no campus por motivo excepcional.

RF-FUT-02 — Registrar evento com veículos

Prioridade: Média ou futuro.

O catálogo básico de autorização foi implementado na Issue #83, com período, responsável, área, pernoite, cota por tipo e placa opcional. A Issue #82 vinculou a entrada real ao evento, aplicou precedência de placa, validade, cancelamento e consumo concorrente de cotas. Um sistema completo de participantes, credenciamento e programação continua fora do MVP.

RF-FUT-03 — Registrar mototáxi

Prioridade: Média ou futuro.

Permitir registrar acessos temporários de mototáxi.

RF-FUT-04 — Registrar recusa

Prioridade: Média ou futuro.

Permitir registrar tentativas de acesso recusadas.

RF-FUT-05 — Registrar ocorrência

Prioridade: Futuro.

Permitir registrar ocorrências associadas a veículos, condutores ou acessos.

13. Requisitos não funcionais

RNF-01 — Usabilidade

A interface deve ser simples para porteiros e vigilantes com diferentes níveis de familiaridade com sistemas digitais.

RNF-02 — Validação

O sistema deve validar os campos antes de confirmar o registro.

RNF-03 — Padronização

O sistema deverá utilizar opções padronizadas para tipos de veículos e categorias, depois que forem definidas.

RNF-04 — Rastreabilidade

O sistema deve manter histórico das operações importantes e correções.

RNF-05 — Controle de acesso

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

RNF-06 — Segurança

O sistema deve proteger credenciais e dados contra acesso não autorizado.

RNF-07 — Disponibilidade operacional

O projeto deverá considerar contingência para indisponibilidade da rede ou sistema.

RNF-08 — Desempenho

O sistema deve responder em tempo adequado nos horários de pico.

RNF-09 — Manutenibilidade

O sistema deve ser desenvolvido com organização, testes, documentação e separação de responsabilidades.

RNF-10 — Privacidade

O sistema deverá coletar e armazenar apenas os dados necessários para o controle veicular.

RNF-11 — Integridade

O sistema deve impedir alterações não autorizadas e exclusões indevidas.

RNF-12 — Auditoria

O sistema deve registrar ações relevantes de criação, alteração, correção, conferência e encerramento.

14. Regras de negócio relacionadas

RN-01 — Registro inicial

O porteiro realiza o registro inicial na portaria.

RN-02 — Troca de turno

O vigilante assume a continuidade do processo durante a troca de turno.

RN-03 — Conferência

O Setor de Transporte recebe e confere os registros.

RN-04 — Veículos institucionais

A utilização de veículo institucional deve estar relacionada a um motorista.

RN-05 — Quilometragem

Veículos institucionais devem possuir registro de quilometragem de saída e entrada, conforme o Formulário nº 01.

RN-06 — Itinerário

Veículos institucionais devem possuir itinerário registrado, conforme o Formulário nº 01.

RN-07 — Correção

Correções devem preservar histórico.

RN-08 — Dados não confirmados

RG ou CPF, tipos de veículos, assinatura digital, regras de recusa e permissões definitivas não devem ser tratados como decisões finais antes da validação.

RN-09 — Evolução

As outras planilhas poderão ser incorporadas futuramente após avaliação e priorização.

15. User stories do MVP

US-MVP-01 — Cadastrar veículo

Como usuário autorizado,
quero cadastrar um veículo,
para utilizá-lo em registros de acesso posteriores.

US-MVP-02 — Cadastrar pessoa relacionada

Como usuário autorizado,
quero cadastrar uma pessoa relacionada a um veículo,
para identificar condutores e responsáveis.

US-MVP-03 — Registrar entrada

Como porteiro,
quero registrar a entrada de um veículo,
para manter o acesso documentado digitalmente.

US-MVP-04 — Registrar saída

Como porteiro ou vigilante,
quero registrar a saída de um veículo,
para encerrar o acesso e saber quais veículos permanecem no campus.

US-MVP-05 — Consultar veículo

Como usuário autorizado,
quero pesquisar por placa ou veículo,
para localizar rapidamente os registros necessários.

US-MVP-06 — Identificar motorista

Como usuário do Setor de Transporte,
quero localizar o motorista associado a uma viagem,
para responder a solicitações relacionadas a multas ou ocorrências.

US-MVP-07 — Registrar veículo institucional

Como usuário autorizado,
quero registrar a utilização de um veículo institucional,
para controlar motorista, quilometragem, horários e itinerário.

US-MVP-08 — Corrigir registro

Como usuário autorizado,
quero corrigir um registro com justificativa,
para corrigir erros sem perder o histórico.

US-MVP-09 — Conferir registros

Como usuário do Setor de Transporte,
quero conferir os registros realizados,
para validar e consultar as informações do processo.

16. Critérios de aceite

Cadastro de veículo

• O usuário autorizado consegue iniciar o cadastro.
• O sistema solicita os campos obrigatórios definidos.
• O sistema identifica duplicidade quando aplicável.
• O veículo pode ser consultado após o cadastro.
• O cadastro registra usuário e data da operação.

Cadastro de pessoa relacionada

• O usuário autorizado consegue cadastrar uma pessoa relacionada a veículo.
• O sistema permite indicar o tipo de relação.
• O sistema não exige cadastro geral de pessoas sem relação veicular.
• O cadastro pode ser consultado por usuário autorizado.

Registro de entrada

• O usuário autorizado consegue iniciar o registro.
• O sistema permite localizar ou cadastrar veículo.
• O sistema permite localizar ou cadastrar condutor.
• O sistema registra data e horário.
• O sistema registra o usuário responsável.
• O sistema valida os campos obrigatórios.
• O registro pode ser consultado posteriormente.

Registro de saída

• O usuário autorizado consegue localizar um registro aberto.
• O sistema registra o horário de saída.
• O sistema impede ou sinaliza encerramento duplicado.
• O status do registro é atualizado.
• O usuário responsável pela saída fica registrado.

Veículo institucional

• O usuário consegue informar o veículo.
• O usuário consegue informar o motorista.
• O usuário consegue registrar quilometragem de saída.
• O usuário consegue registrar horário de saída.
• O usuário consegue registrar itinerário.
• O usuário consegue registrar quilometragem de entrada.
• O usuário consegue registrar horário de entrada.
• O sistema alerta sobre quilometragem inconsistente.
• O registro pode ser consultado posteriormente.

Consulta

• O usuário autorizado consegue pesquisar por placa.
• O usuário autorizado consegue pesquisar por veículo.
• O usuário autorizado consegue pesquisar por motorista.
• O usuário autorizado consegue pesquisar por período.
• O sistema exibe apenas dados permitidos ao perfil.
• O sistema permite visualizar veículos sem saída ou retorno.

Correção

• Apenas usuários autorizados conseguem corrigir.
• O motivo da correção é obrigatório.
• O valor anterior é preservado.
• O novo valor é armazenado.
• A data, o horário e o usuário são registrados.
• A correção pode ser consultada na auditoria.

17. Backlog atualizado

17.1. Prioridade alta — Consolidação

• Registrar o feedback da apresentação.
• Criar e revisar o documento MVP e Fluxo Digital.
• Confirmar o MVP com o cliente.
• Definir os campos mantidos.
• Definir os campos que não serão utilizados.
• Confirmar os campos obrigatórios.
• Atualizar a Visão do Projeto.
• Atualizar Requisitos e Backlog.
• Atualizar Regras de Negócio.
• Revisar Modelo de Dados.
• Definir perfis e permissões preliminares.
• Definir critérios de aceite definitivos.

17.2. Prioridade alta — Primeiro incremento

• Cadastrar veículos.
• Cadastrar pessoas relacionadas.
• Associar pessoas e veículos.
• Registrar entrada.
• Registrar saída.
• Registrar placa.
• Registrar condutor.
• Registrar motorista institucional.
• Registrar objetivo.
• Registrar quilometragem de saída e entrada.
• Registrar itinerário.
• Consultar registros.
• Consultar por placa.
• Consultar por motorista.
• Consultar por período.
• Consultar veículos sem saída ou retorno.
• Conferir registros.
• Controlar permissões.
• Registrar correções.
• Registrar auditoria.

17.3. Prioridade média

• Registrar veículos que permanecem no campus.
• Registrar eventos com veículos.
• Registrar mototáxis.
• Registrar recusas.
• Registrar ocorrências.
• Gerar relatórios simples.
• Atualizar situação de pessoas e veículos.
• Criar filtros avançados.
• Criar exportação autorizada.

17.4. Prioridade futura

• Reconhecimento automático de placas.
• Integração com câmeras.
• Integração com sensores.
• Integração com catraca ou cancela.
• Liberação automática.
• Controle de vagas.
• Aplicação para solicitação de autorização.
• Integração com outros sistemas institucionais.
• Expansão para os Formulários nº 03 a nº 07.

18. Questões pendentes

Campos

• O campo “veículo” representa tipo, modelo, identificação patrimonial ou outra informação?
• RG ou CPF será obrigatório?
• Qual documento será aceito?
• A placa será obrigatória em todas as categorias?
• 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?
• Identificação patrimonial será necessária?
• Número de frota será necessário?

Regras

• Quem pode criar autorizações?
• Quem pode aprovar autorizações?
• Quem pode corrigir registros?
• O vigilante terá as mesmas permissões do porteiro?
• Quais são os motivos oficiais de recusa?
• Como será tratado um veículo sem placa?
• Como será tratado um motociclista sem capacete?
• Como serão tratados veículos de discentes residentes?
• Quais são as regras oficiais para mototáxis?

Operação

• Como funciona o registro quando a entrada não é localizada?
• Como será tratado um veículo que permanece no campus?
• Haverá mais de uma portaria?
• Qual é o volume de acessos nos horários de pico?
• A portaria terá computador ou tablet?
• Existe rede disponível?
• Como funcionará o sistema sem rede?
• Será necessário manter formulários físicos como contingência?

Retenção e evolução

• Qual é o prazo oficial de retenção digital?
• O prazo atual de cinco anos é obrigatório?
• Será necessária impressão de relatórios?
• As outras planilhas serão incorporadas em qual fase?
• A catraca será reparada ou substituída?
• Existem câmeras adequadas para futura integração?

19. Rastreabilidade

Origem	Requisitos relacionados
Feedback do cliente	PR-01 a PR-06, RF-MVP-01 a RF-MVP-18
Formulário nº 01	RF-MVP-01, RF-MVP-03, RF-MVP-07, RF-MVP-10, RF-MVP-11, RF-MVP-12, RF-MVP-13
Formulário nº 02	RF-MVP-01, RF-MVP-02, RF-MVP-04, RF-MVP-05, RF-MVP-06, RF-MVP-08, RF-MVP-09
Formulários nº 03 a nº 07	Escopo futuro e fora do MVP
Setor de Transporte	RF-MVP-06, RF-MVP-13, RF-MVP-14, RF-MVP-15, RF-MVP-17
Troca de turno	RF-MVP-05, RF-MVP-07, RNF-07
Caso da multa	RF-MVP-06, RF-MVP-13
Erros nos formulários	RF-MVP-17, RF-MVP-18, RNF-04, RNF-12
Veículos institucionais	RF-MVP-10, RF-MVP-11, RF-MVP-12
Regras de negócio	RF-MVP-04 a RF-MVP-18

20. Definition of Ready

Uma tarefa poderá entrar em uma sprint quando possuir:

• Descrição clara.
• Objetivo compreensível.
• Origem identificada.
• Critérios de aceite.
• Prioridade.
• Responsável.
• Dependências conhecidas.
• Escopo definido.
• Dúvidas registradas.
• Forma de validação definida.
• Campos necessários identificados.
• Impacto no modelo de dados conhecido.

21. Definition of Done

Uma tarefa será considerada concluída quando:

• O trabalho estiver implementado ou documentado.
• O código tiver sido revisado por Pull Request, quando aplicável.
• Os testes tiverem sido executados.
• A pipeline tiver sido aprovada, quando aplicável.
• A documentação estiver atualizada.
• O trabalho tiver sido executado ou demonstrado localmente.
• A tarefa estiver vinculada à issue correspondente.
• O resultado puder ser apresentado na review ou weekly.
• Os critérios de aceite tiverem sido atendidos.
• As pendências conhecidas estiverem registradas.
• O resultado não contradizer os documentos do projeto.

22. Status do documento

Documento: Requisitos e Backlog.

Versão: 0.4.

Status: Requisitos sincronizados com o MVP técnico; decisões institucionais e incrementos posteriores permanecem no backlog.

Formulários analisados: 7 de 7.

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

MVP: Implementado tecnicamente; homologação observada pendente na Issue #162.

Feedback do cliente: Favorável à continuidade e à digitalização com melhoria do processo atual.

Validação formal dos requisitos: Parcial; feedback favorável registrado, com homologação detalhada pendente.

Arquitetura: Implementada e documentada em arc42.

Implementação: MVP técnico integrado na main; produção institucional não iniciada.

Este documento deverá ser atualizado após:

• Homologação observada dos quatro perfis.
• Decisões institucionais que alterem o MVP.
• Definição dos campos obrigatórios.
• Aprovação dos critérios de aceite que ainda carregam needs-validation.

Responsáveis pela documentação:

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