Pular para o conteúdo principal

Documento de Requisitos Funcionais - Horus HAB

Projeto: Horus Solicitação Municipal (SHAB Horus) Contratante: Secretaria de Desenvolvimento Urbano e Habitação (SDUH) — Governo do Estado de São Paulo Código: HORUS-REQ-FUN-001 Data: 2026-10-05 Versão: 1.4


1. Sumário Executivo​

O Horus Solicitação Municipal (SHAB Horus) é uma plataforma integrada voltada para o gerenciamento e análise do desenvolvimento habitacional e urbano. O objetivo do sistema é permitir que municípios solicitem suporte ou submetam projetos habitacionais à SDUH, acompanhando todo o ciclo de aprovação — da inserção de informações preliminares até a análise final de documentação —, amparado por dados territoriais e informações georreferenciadas unificadas a nível estadual.

2. Escopo do Projeto​

O escopo do projeto engloba uma plataforma web estruturada em módulos fundamentais:

  1. Autenticação e Segurança Híbrida
  2. Módulo de Solicitações Municipais
  3. Módulo de Informações Georreferenciadas
  4. Módulo de Gestão Documental
  5. APIs e Ingestão Analítica (BigQuery)

A plataforma abrange todos os municípios do estado e conecta equipes locais com as áreas técnicas da SDUH.

3. Perfis de Usuários​

PerfilFunções e Permissões
Usuários ExternosVisualizam informações públicas e georreferenciadas através de rotas desprotegidas.
Usuário do Município (municipio_user)Preenchem formulários de solicitação, inserem dados técnicos, enviam documentos. Acesso e visibilidade estritamente limitados ao seu próprio município (Tenant Isolation). Autenticação via Gov.br (IDP.SP).
Equipe SDUH (sduh_user / sduh_mgr / adm)Visão global sobre todos os municípios. Revisam projetos, analisam dados, gerenciam a situação das solicitações e avançam o fluxo de aprovação. Autenticação via CyberArk (Minha Área).
Maintainer (API/ETL)Perfil de máquina ou administrador de dados com privilégios para forçar refresh de cache no middleware e ingerir novos dados no pipeline de ETL.

4. Requisitos Funcionais (Por Módulo)​

Módulo 1 — Autenticação e Segurança​

IDRequisito
1.1Login Híbrido OIDC via Gov.br para municípios
1.2Login Híbrido OIDC via CyberArk para SDUH
1.3Login alternativo via Passkey (Biometria) para cenários de bypass de contingência
1.4Geração de Custom Token (Firebase) e gerenciamento de sessão frontend

Módulo 2 — Solicitações Municipais​

IDRequisito
2.1Preenchimento de informações preliminares pelo município
2.2Painel de controle de solicitações enviadas / rascunhos
2.3Análise técnica SDUH: aprovação (HOMOLOGADO), devolução com pendências (AGUARDANDO_DOCUMENTO) ou indeferimento (INDEFERIDO)
2.4Análise de projetos SDUH
2.5Histórico de tramitação e mudança de situação (aderente aos estados canônicos de máquina: RASCUNHO, EM_ANALISE, AGUARDANDO_DOCUMENTO, HOMOLOGADO, INDEFERIDO, SUSPENSO, CONCLUIDO, CANCELADO)

Módulo 3 — Informações Georreferenciadas​

IDRequisito
3.1Visualização do mapa base e renderização de camadas de Empreendimentos (via Looker Studio Pro iframe ou render nativo)
3.2Ferramentas de desenho em mapa (polígonos, marcações)
3.3Consulta à base analítica de dados (BigQuery) via API otimizada (Middleware)

Módulo 4 — Gestão Documental​

IDRequisito
4.1Upload de documentos técnicos e projetos (Upload Direto no Cloud Storage)
4.2Validação de extensões e tamanhos de arquivos
4.3Vinculação de documento a uma solicitação municipal específica
4.4Análise de documentação SDUH (Validação)

Módulo 5 — APIs e Middleware Analítico​

IDRequisito
5.1Acesso público / public docs (/public/docs) para leitura de métricas e empreendimentos
5.2Atualização e Ingestão forçada do cache (/empreendimentos/refresh-cache) para perfis administrativos e esteiras de ETL
5.3Autenticação M2M utilizando chaves estáticas (MACHINE_API_KEY) para rotinas batch, restritas aos endpoints /admin/

5. Requisitos Não Funcionais​

IDRequisito
RNF-01Usabilidade: aplicação Single Page Application (SPA) responsiva, com navegação rápida provida por React + Vite e Tailwind CSS.
RNF-02Segurança (Shift-Left): código formatado pelo Biome, checado pelo Husky e verificado quanto a vulnerabilidades estáticas (Semgrep) e de containers (Trivy) nos pipelines.
RNF-03Desempenho (cache): o Middleware (FastAPI) inicia o cache em memória na primeira requisição, com latência p95<200 msp95 < 200\text{ ms} para consultas analíticas cacheadas, TTL padrão de 15 minutos, expiração automática e endpoint de renovação forçada.
RNF-04Conformidade (Passkey / bypass): sessões por Passkey (partial_auth: true) são bloqueadas no Backend para qualquer mutação de dados, alteração de situação ou acesso a informações pessoais (LGPD), além da restrição na UI e do registro compulsório na trilha de auditoria (auditoria.log_operacao).
RNF-05Disponibilidade e recuperação: banco em instância regional de alta disponibilidade, com RTO < 1 minuto em falha de zona, backup diário e PITR de 7 dias (Doc 04, Seção 4).
RNF-06Proteção de dados (LGPD): colunas com dado pessoal classificadas e mascaradas fora de PROD; HOM não contém PII real (Doc 05, Seções 3.4 e 5.3).
RNF-07Auditoria: toda escrita em tabela crítica e todo evento de segurança são registrados em auditoria.log_operacao (Doc 04, Seção 7).
RNF-08Soberania: dados e serviços hospedados exclusivamente em southamerica-east1 (São Paulo).
RNF-09Dependência do cadastro mestre: a indisponibilidade da API de Cadastro Mestre não pode corromper dado nem impedir a leitura de dados já gravados; a gravação de vínculo com o mestre falha de forma explícita e pode ser repetida sem duplicar (Doc 01, Seção 6).

6. Rastreabilidade​

MóduloComponenteSchema / dataset (Doc 03)
1 — Autenticação e SegurançaExpress.js, Firebase Auth, Gov.br / CyberArkseguranca, auditoria
2 — Solicitações MunicipaisSHAB-HorusHab (Core Backend)solicitacao
3 — Informações GeorreferenciadasLooker Studio Pro, Middleware FastAPI*_gold (BigQuery)
4 — Gestão DocumentalCloud Storage, Core Backendmdm.arquivos
5 — APIs e Ingestão AnalíticaMiddleware FastAPI, BigQuery*_gold (BigQuery)