SAD - Software Architecture Document
(Documento de Arquitetura de Software)
Nome do Projeto: SafeSync (Sistema de Gestão Inteligente de Segurança do Trabalho)
Responsável Técnico (Tech Lead): [Seu Nome] Versão do Documento: 1.0 Última
Atualização: 29/01/2026
1. Visão Geral e Escopo
1.1. Resumo Executivo (Elevator Pitch)
O SafeSync é um aplicativo móvel e web (PWA) focado na digitalização de processos de
segurança do trabalho (EHS) em ambientes com ou sem conexão à internet ("Offline-First"). Ele
elimina o uso de papel em canteiros de obras e fábricas, permitindo que Técnicos de
Segurança realizem checklists, liberem Permissões de Trabalho (PT) e controlem a entrega de
EPIs digitalmente. O sistema garante a rastreabilidade jurídica através de geolocalização,
evidências fotográficas obrigatórias e assinaturas digitais, transformando dados de campo em
indicadores de risco em tempo real para os gestores.
1.2. Stakeholders (Atores do Sistema)
● Técnico de Segurança: Realiza inspeções, preenche checklists, entrega EPIs e libera
áreas. (Usuário principal do App).
● Colaborador (Operário): Assina (digitalmente) o recebimento de EPIs e a leitura das
instruções de segurança (APR/DDS).
● Engenheiro/Gestor de Obra: Acessa o painel web para ver gráficos de risco, não
conformidades e aprovar permissões críticas.
● Administrador do Sistema: Gerencia cadastros de obras, usuários e modelos de
documentos.
2. Requisitos do Sistema
2.1. Requisitos Funcionais (RF)
● [RF01] O sistema deve funcionar em modo offline, permitindo preencher formulários e
salvá-los localmente para sincronização posterior.
● [RF02] O sistema deve exigir uma foto como evidência obrigatória sempre que um item
de checklist for marcado como "Não Conforme".
● [RF03] O sistema deve coletar a assinatura digital (desenho na tela) do colaborador ao
receber um EPI ou participar de um treinamento.
● [RF04] O sistema deve capturar a geolocalização (GPS) automática no momento do
início e fim de cada inspeção.
● [RF05] O sistema deve gerar um PDF consolidado (Dossiê) contendo a APR, a PT e o
Checklist de um dia específico para fins de fiscalização.
● [RF06] O sistema deve permitir a leitura de QR Codes para identificar equipamentos
(extintores, máquinas) e funcionários (crachás).
2.2. Requisitos Não-Funcionais (RNF)
● [RNF01 - Disponibilidade] A sincronização de dados deve ocorrer automaticamente
assim que o dispositivo detectar conexão estável.
● [RNF02 - Integridade] As fotos tiradas dentro do app não podem ser editadas ou
substituídas por imagens da galeria (para evitar fraudes).
● [RNF03 - Usabilidade] A interface mobile deve ter botões grandes e alto contraste para
uso em ambientes externos e com luvas.
● [RNF04 - Performance] O tempo de abertura da câmera e salvamento da foto não deve
exceder 2 segundos.
2.3. Regras de Negócio (RN)
● [RN01] Uma Permissão de Trabalho (PT) não pode ser liberada se o treinamento do
funcionário para aquela atividade (ex: NR-35) estiver vencido no cadastro.
● [RN02] Não é possível encerrar um checklist se houver itens obrigatórios em branco.
● [RN03] Checklists marcados com "Risco Grave e Iminente" devem disparar um alerta
(e-mail/push) imediato para o Gestor da Obra.
3. Arquitetura da Solução (Tech Stack)
3.1. Tecnologias Escolhidas
● Frontend (App Campo): [Link] (PWA - Progressive Web App) com Vite. Uso de
Service Workers para funcionalidade Offline.
● Frontend (Dashboard Gestão): [Link] com biblioteca de gráficos (Recharts ou
[Link]).
● Backend (API): [Link] com Fastify ou NestJS (focado em performance).
● Banco de Dados: PostgreSQL (Relacional) hospedado no Supabase.
● Armazenamento Local (Offline): IndexedDB (via [Link] ou TanStack Query) para
guardar dados no celular antes de sincronizar.
● Armazenamento de Arquivos: Supabase Storage ou AWS S3 (para as fotos das
inspeções).
3.2. Diagrama de Contexto (Fluxo de Alto Nível)
1. Técnico (Offline): Abre o app, loga (com dados cacheados), preenche a inspeção e tira
fotos. Dados salvos no IndexedDB do celular.
2. Sincronização: Ao detectar internet, o Service Worker envia os dados locais para a API
(Backend).
3. API: Valida as regras de negócio, salva os dados no PostgreSQL e faz upload das fotos
para o Storage.
4. Gestor (Online): Acessa o Dashboard Web, que consome a API para exibir indicadores
em tempo real.
4. Modelagem de Dados (Database Schema)
4.1. Dicionário de Dados (Principais Tabelas)
Tabela: FUNCIONARIOS | Campo | Tipo | Obrigatório? | Descrição | | :--- | :--- | :--- | :--- | | id |
UUID | Sim (PK) | Identificador único. | | nome | Varchar(150) | Sim | Nome completo. | | cpf |
Varchar(11) | Sim (Unique)| Identificação legal. | | biometria_hash | Varchar | Não | Hash para
validação rápida. | | validade_aso | Date | Sim | Validade do Atestado de Saúde. |
Tabela: INSPECOES (Checklists/APRs) | Campo | Tipo | Obrigatório? | Descrição | | :--- | :--- |
:--- | :--- | | id | UUID | Sim (PK) | ID da inspeção. | | tecnico_id | UUID | Sim (FK) | Quem realizou
a inspeção. | | data_hora | DateTime | Sim | Momento do registro. | | gps_lat | Decimal | Sim |
Latitude. | | gps_long | Decimal | Sim | Longitude. | | sync_status | Enum | Sim | 'Pendente',
'Sincronizado'. |
Tabela: EVIDENCIAS (Fotos) | Campo | Tipo | Obrigatório? | Descrição | | :--- | :--- | :--- | :--- | |
id | UUID | Sim (PK) | ID da foto. | | inspecao_id | UUID | Sim (FK) | A qual inspeção pertence. | |
url_storage | Varchar | Sim | Link da foto na nuvem. | | comentario | Text | Não | Observação
sobre a foto. |
4.2. Relacionamentos
● Um Técnico realiza muitas Inspeções (1:N).
● Uma Inspeção possui muitas Evidências/Fotos (1:N).
● Uma Permissão de Trabalho envolve muitos Funcionários (N:N).
5. Interface do Usuário (UI/UX)
5.1. Mapa do Site (Sitemap)
1. Login (Com suporte a PIN rápido para acesso offline).
2. Home / Meus Projetos (Lista de obras atribuídas ao técnico).
3. Menu de Ação (Botões grandes: "Nova Inspeção", "Entregar EPI", "Abrir APR").
4. Formulário de Checklist (Perguntas com Sim/Não/Não se Aplica + Botão de Foto).
5. Tela de Assinatura (Canvas para dedo/caneta).
6. Painel Admin (Web - Acesso restrito a gestores para relatórios).
5.2. Componentes Globais
● Header de Status: Indica se o app está "Online" (Verde) ou "Offline" (Laranja).
● Card de Inspeção: Resumo com Local, Data e Status (Pendente/Enviado).
● Input de Foto: Componente customizado que abre a câmera e bloqueia upload da
galeria.
6. Segurança e Infraestrutura
6.1. Estratégia de Deploy
● Frontend (PWA): Build automático via GitHub Actions e deploy na Vercel.
● Backend & Banco: Hospedagem no Supabase (que já fornece Banco, Auth e API layer
básica) ou Render se precisar de backend customizado em [Link].
6.2. Controles de Acesso
● Role 'FIELD_TECH': Pode criar inspeções, mas não pode excluir histórico. Vê apenas as
obras que está alocado.
● Role 'MANAGER': Vê todas as obras, dashboards financeiros e de risco. Pode cadastrar
novos técnicos.
● Rota /api/sync: Protegida por Token JWT, com validação extra de integridade dos dados
enviados.
7. Definição de Pronto (Definition of Done - DoD)
● [ ] O código foi revisado (Code Review).
● [ ] A funcionalidade foi testada em Modo Avião (Offline) e sincronizou corretamente ao
reconectar.
● [ ] As fotos foram salvas com compressão adequada (para não gastar o 4G do usuário).
● [ ] O layout está responsivo e utilizável em telas pequenas (smartphones básicos).
● [ ] O código foi enviado para o repositório principal (Main Branch).