09 — Requisitos não funcionais
Requisitos que valem para todos os módulos. A stack e o desenho técnico detalhado ficam para a spec técnica; aqui está o que precisa ser garantido.
1. Trilha de auditoria
- #RNF-01 Registro de toda criação, alteração, inativação, assinatura, login, exportação e download de documento controlado: quem (usuário e colaborador), o quê, quando (relógio do servidor, exibido no fuso do cliente), valores antes/depois, motivo, origem (tela, planilha, API)
- #RNF-02 Trilha somente de acréscimo: a aplicação não tem permissão de alterar nem apagar; o banco bloqueia UPDATE, DELETE e TRUNCATE
- #RNF-03 Criação de registro também grava todos os valores (na v1 a criação ficava sem valores)
- #RNF-04 Nenhum caminho de escrita fora da trilha (operações em massa e SQL direto proibidos no domínio)
- #RNF-05 Opcional: encadear hash entre registros da trilha para evidenciar adulteração
2. Assinatura eletrônica
- #RNF-10 Reautenticação (senha ou PIN) no ato de assinar
- #RNF-11 Grava: signatário, significado (elaborei, revisei, aprovei, li/compreendi/fui aprovado, liberei), data/hora, hash da versão ou registro assinado, IP/dispositivo, funções e permissões vigentes
- #RNF-12 A assinatura aparece no documento/registro exibido (nome, data/hora, significado)
- #RNF-13 Verificação de integridade: recalcular o hash e confirmar que o arquivo é o mesmo assinado
- #RNF-14 Linguagem cuidadosa no material comercial: "projetado para atender requisitos de registros e assinaturas eletrônicas", nunca "100% conforme", porque conformidade depende também da validação e dos procedimentos do cliente
3. Acesso e segurança
- #RNF-20 Senha com política mínima, bloqueio por tentativas, expiração de sessão por inatividade; MFA opcional por cliente
- #RNF-21 Isolamento total entre clientes; testes automatizados que provem o isolamento
- #RNF-22 Acesso do suporte do fornecedor só com autorização e registro (Doc 01 ACE-42)
4. Validação do próprio sistema
O cliente regulado precisa demonstrar que o QAS é adequado ao uso. Entregar isso pronto é diferencial.
- #RNF-30 Cada requisito destes documentos tem ID; cada ID tem teste automatizado; a matriz requisito → teste → resultado é gerada a cada versão
- #RNF-31 Notas de versão por release, com os requisitos afetados
- #RNF-32 Aviso prévio de atualização e ambiente de homologação para o cliente
- #RNF-33 Pacote de validação para o cliente: descrição do sistema, análise de risco por funcionalidade, matriz de rastreabilidade, evidências de teste
- #RNF-34 Funções de IA são assistivas e sempre revisadas por pessoa; documentar isso na análise de risco
5. Dados, continuidade e privacidade
- #RNF-40 Backup com restauração testada periodicamente (com registro do teste)
- #RNF-41 Exportação completa dos dados do cliente em formato aberto (PDF dos registros + planilhas/JSON + arquivos originais com hash), a qualquer momento e ao encerrar o contrato. Registros precisam sobreviver por anos ao contrato
- #RNF-42 Plano de continuidade (o que acontece com os dados se o fornecedor deixar de operar)
- #RNF-43 Dados pessoais mínimos; contrato de tratamento de dados com o cliente; retenção conforme Doc 00 PRI-09/10
- #RNF-44 Conteúdo enviado para IA: só fornecedor/plano que não retenha nem use os dados para treinamento; opção por cliente de desligar a IA
6. Usabilidade
- #RNF-50 Funciona em computador e tablet (quiosque)
- #RNF-51 Toda lista exporta PDF e Excel
- #RNF-52 Datas e horas no fuso do cliente; vigência vira à 00:00 local
7. Correções técnicas herdadas da v1
Ao escrever a spec técnica, não repetir:
- Interceptor de auditoria que não grava valores na criação e registra soft delete como alteração comum
- Entidade sem soft delete sendo apagada fisicamente
- Schema por cliente definido em
OnModelCreating(o EF guarda o modelo em cache e todos os clientes passam a usar o schema do primeiro) - Carimbo de status gravado dentro do PDF assinado (muda o hash; Doc 02 GED-81)