Documento de Requisitos do Produto

Neemias

1. Propósito

O Neemias é uma aplicação de chamada e presença para equipes pequenas e ambientes semelhantes a escolas que precisam de registro de presença rápido e confiável para 3 a 5 usuários simultâneos. O produto é concebido como um progressive web app que funciona em navegadores móveis e de desktop, pode operar offline e sincroniza as alterações quando a conectividade retorna.

Este documento é a fonte de verdade no nível de produto. Ele define o problema, os usuários pretendidos, os limites do produto e as regras de negócio que não podem ser violadas por decisões de implementação.

2. Visão do Produto

O produto deve tornar o registro de presença extremamente simples para usuários não técnicos, permanecendo ao mesmo tempo seguro, auditável e fácil de estender.

O sistema deve:

• Adotar o português do Brasil como padrão para todos os usuários.
• Permitir que idiomas adicionais sejam adicionados depois sem redesenhar a aplicação.
• Permanecer modular, para que funcionalidades futuras como relatórios, fluxos de trabalho e gestão de alunos possam ser adicionadas de forma limpa.
• Suportar uso offline sem perder as ações do usuário.
• Priorizar acessibilidade e feedback visual imediato.
• Aplicar o princípio do menor privilégio e os requisitos da LGPD.

3. Definição do Problema

Os fluxos atuais de chamada costumam ser lentos, sujeitos a erro e difíceis para usuários não técnicos. O produto deve reduzir o atrito no ponto de captura da presença, protegendo ao mesmo tempo os dados pessoais e preservando um histórico confiável de alterações.

4. Usuários-Alvo

Papel	Necessidade Primária	Acesso Típico
Admin (ADMIN)	Gerenciar alunos, presenças, relatórios, usuários e configurações	Acesso operacional completo
Chamador (CHAMADOR)	Marcar presente e ausente rapidamente	Somente chamada
Relatórios (RELATORIOS)	Consultar relatórios de presença	Somente relatórios
Cadastro (CADASTRO)	Adicionar alunos e manter os cadastros	Criação de alunos, turmas, núcleos
Responsável (RESPONSAVEL)	Ver os registros dos próprios filhos	Leitura apenas dos próprios alunos
Voluntário (VOLUNTARIO)	Apoiar as atividades de sala	Leitura limitada de aluno, visão de aula
Coordenação Kids (COORDENACAO_KIDS)	Gerenciar as operações do ministério infantil	Relatórios, leitura de aluno, aulas
Administrativo Kids (ADMINISTRATIVO_KIDS)	Apoio administrativo ao ministério infantil	Relatórios, leitura de aluno

5. Objetivos do Produto

Objetivo	Descrição
Captura rápida de presença	O usuário deve conseguir identificar um aluno e registrar a presença com o mínimo de passos.
Reconhecimento imediato	As fotos dos alunos devem aparecer imediatamente durante a busca para apoiar a identificação visual.
Continuidade offline	Os usuários devem continuar trabalhando quando a internet estiver indisponível.
Sincronização confiável	As alterações feitas offline devem sincronizar com segurança quando a conectividade retornar.
Simplicidade	A interface deve ser fácil para usuários com pouca experiência em software.
Acessibilidade	A experiência deve atender ao nível AA das WCAG.
Conformidade	O produto deve estar em conformidade com a LGPD onde aplicável.
Extensibilidade	A arquitetura deve suportar funcionalidades futuras sem grandes redesenhos.

6. Escopo

No escopo

• Marcação de presença nos estados presente e ausente.
• Criação e manutenção de alunos.
• Navegação pelo diretório de alunos com ordenação alfabética e visão de perfil/detalhes.
• Acesso a relatórios para usuários autorizados (13 tipos de relatório: taxa de presença, auditorias, engajamento de turma, risco de evasão, sociodemográfico, tendências etc.).
• Busca com visibilidade imediata da foto.
• Operação offline e sincronização posterior via banco de dados local SQLite/WASM.
• Histórico de auditoria para ações sobre alunos e presenças.
• Controle de acesso baseado em papéis com 8 papéis de sistema e 25 permissões granulares.
• Criação e gestão dinâmica de papéis personalizados (API CRUD).
• Arquitetura de localização com português do Brasil como padrão.
• Justificativa de exclusão para remoção de aluno restrita ao admin.
• Feedback visual para ações bem-sucedidas e malsucedidas.
• Gestão do ciclo de vida de usuários restrita ao admin (criar, atualizar, redefinir senha, desativar).
• Importação e exportação de dados de alunos e turmas.
• Inscrição pública em eventos para alunos e responsáveis.
• Auto-cadastro de alunos por meio de links de convite.
• Painel de capacidade ao vivo para a ocupação das turmas.
• Sobreposição para TV/tela com notificações e avisos.
• Sistema de plugins para módulos extensíveis (núcleos, voluntários).

Fora do escopo por enquanto

• Distribuição em lojas de aplicativos móveis.
• Aplicações nativas.
• Integrações complexas de identidade corporativa, a menos que sejam adicionadas explicitamente depois.
• Matriz formal de rastreabilidade regulatória.
• Multi-inquilino entre organizações, a menos que introduzido depois.

7. Usuários Principais e Permissões

Ação	CHAMADOR	RELATORIOS	CADASTRO	RESPONSAVEL	VOLUNTARIO	COORDENACAO_KIDS	ADMINISTRATIVO_KIDS	ADMIN
Marcar presença	Sim	Não	Não	Não	Não	Não	Não	Sim
Ver relatórios	Não	Sim	Não	Não	Não	Sim (consolidado)	Sim (consolidado)	Sim
Adicionar alunos	Não	Não	Sim	Não	Não	Não	Não	Sim
Editar alunos	Não	Não	Não	Não	Não	Não	Não	Sim
Excluir alunos	Não	Não	Não	Não	Não	Não	Não	Sim, com justificativa
Ver usuários	Não	Não	Não	Não	Não	Não	Não	Sim
Criar usuários	Não	Não	Não	Não	Não	Não	Não	Sim
Editar usuários	Não	Não	Não	Não	Não	Não	Não	Sim
Redefinir senha de usuário	Não	Não	Não	Não	Não	Não	Não	Sim
Desativar usuários	Não	Não	Não	Não	Não	Não	Não	Sim, com salvaguardas
Buscar alunos	Sim	Sim	Sim	Não	Sim (básica)	Sim (completa)	Sim (completa)	Sim
Ver foto do aluno	Sim	Sim	Sim	Não	Sim	Sim	Sim	Sim
Ver os próprios alunos	Não	Não	Não	Sim	Não	Não	Não	Sim
Gerenciar turmas/núcleos	Não	Não	Sim	Não	Não	Não	Não	Sim
Gerenciar voluntários	Não	Não	Não	Não	Não	Não	Não	Sim
Importar/exportar dados	Não	Não	Não	Não	Não	Não	Não	Sim
Gerenciar configurações	Não	Não	Não	Não	Não	Não	Não	Sim
Criar/editar aulas	Não	Não	Sim	Não	Sim (ver)	Não	Não	Sim

8. Regras de Negócio

1. Ações de admin têm precedência sobre qualquer ação conflitante de menor privilégio.
2. A remoção de aluno é restrita ao admin e exige um campo de texto com justificativa.
3. O histórico do aluno e o histórico de presenças devem ser mantidos para fins de auditoria.
4. O produto deve aplicar o princípio do menor privilégio onde aplicável.
5. Qualquer alteração em dados visíveis ao usuário deve ser conferida duas vezes antes de ser efetivada.
6. O produto deve permanecer utilizável offline e preservar o trabalho não sincronizado até que a sincronização ocorra.
7. Os resultados de busca devem exibir as fotos dos alunos imediatamente para apoiar a identificação.
8. A navegação pelos alunos deve ser previsível, com ordenação alfabética e uma visão visível de perfil/detalhes para revisão pelas partes interessadas.
9. A desativação de usuário é apenas lógica e nunca exclui fisicamente o histórico do usuário.
10. A autodesativação é bloqueada.
11. A desativação do último usuário admin ativo é bloqueada.
12. As ações de gestão de usuários devem sempre produzir eventos de auditoria imutáveis.

9. Decisões Arquiteturais

Todas as decisões arquiteturais estão documentadas como Architecture Decision Records em docs/architecture/adr/. Os tópicos principais incluem estratégia de hospedagem, autenticação, criptografia, armazenamento de dados e internacionalização.

Consulte o índice de ADRs para a lista completa.

10. Critérios de Sucesso

• Um novo usuário consegue entender o propósito do app e os papéis apenas pela documentação.
• A presença pode ser registrada com o mínimo de passos e com feedback claro.
• Os usuários conseguem continuar trabalhando offline e sincronizar depois sem perder ações.
• O comportamento de exclusão restrita ao admin é óbvio e aplicável.
• O produto permanece pequeno, modular e amigável a contribuidores.