Capítulo 74 — Requisitos Não Funcionais

74.1 Objetivo do Capítulo

Este capítulo consolida os requisitos não funcionais da Plataforma de Relacionamento Digital com o Cidadão em um único catálogo de referência, organizados por domínio de qualidade, com critérios de aceitação precisos, rastreabilidade para os capítulos onde cada requisito é implementado e as decisões arquiteturais que o sustentam.

Requisitos não funcionais — também denominados atributos de qualidade ou requisitos de qualidade de serviço — não descrevem o que o sistema faz, mas como o sistema se comporta ao fazer o que faz. Em plataformas de missão crítica para serviços públicos, esses requisitos determinam se a solução é operacionalmente viável: uma plataforma que atende funcionalmente mas falha em disponibilidade, segurança ou desempenho não cumpre sua função social.

O catálogo é estruturado em dez domínios: disponibilidade e resiliência, desempenho e escalabilidade, segurança da informação, conformidade legal e regulatória, usabilidade e acessibilidade, manutenibilidade e evolução, portabilidade e interoperabilidade, observabilidade e auditabilidade, capacidade e dimensionamento, e privacidade e proteção de dados. Para cada domínio, são especificados os requisitos com seus critérios de aceitação mensuráveis, os mecanismos de implementação e as referências cruzadas correspondentes.

Este capítulo serve como contrato de qualidade interno do Documento Mestre: toda afirmação de atributo de qualidade feita em capítulos anteriores pode ser rastreada até um requisito específico neste catálogo, e todo requisito aqui especificado encontra implementação documentada em pelo menos um capítulo técnico anterior.

74.2 Contexto

A natureza multi-tenant da plataforma — operando simultaneamente para múltiplos órgãos da Administração Pública de Minas Gerais — impõe que os requisitos não funcionais sejam atendidos de forma independente por tenant, sem que a degradação de desempenho ou incidente de segurança em um tenant comprometa os demais. Essa premissa de isolamento é o fio condutor que atravessa todos os domínios de qualidade aqui definidos.

Os requisitos não funcionais desta plataforma atendem simultaneamente a quatro conjuntos de restrições: as restrições técnicas da arquitetura de microsserviços e Kubernetes (que favorecem escalabilidade mas exigem cuidado com consistência); as restrições operacionais dos serviços públicos (disponibilidade durante horário de pico de atendimento, conformidade legal, acessibilidade universal); as restrições de segurança do setor governamental (proteção de dados de cidadãos, auditabilidade plena, conformidade com LGPD); e as restrições contratuais da parceria com a PRODEMGE (SLAs formalizados, metas mensuráveis, apuração objetiva).

Os critérios de aceitação definidos neste capítulo têm precedência interpretativa sobre afirmações qualitativas feitas em outros capítulos. Quando um capítulo afirma que um serviço tem "alta disponibilidade", o significado preciso é aquele definido na seção 74.3 deste capítulo.

74.3 Escopo

O catálogo abrange todos os componentes da plataforma expostos a usuários externos (cidadãos, servidores, gestores) e a sistemas externos (integrações com o ecossistema PRODEMGE). Componentes exclusivamente internos — ferramentas de desenvolvimento, ambientes de homologação, sistemas de CI/CD — são cobertos parcialmente, apenas onde sua qualidade afeta diretamente a qualidade do ambiente de produção.

O catálogo não é exaustivo quanto a cada microsserviço individualmente: especifica os requisitos por categoria de serviço (Crítico, Alto, Médio, Baixo), conforme a taxonomia estabelecida no Capítulo 53. A aplicação por serviço individual é responsabilidade do processo de arquitetura de cada componente, documentada nos ADRs correspondentes.

74.4 Descrição Técnica

74.4.1 Domínio RNF-01 — Disponibilidade e Resiliência

A disponibilidade é o requisito não funcional de maior impacto em plataformas de serviços públicos. Indisponibilidade implica impossibilidade de acesso do cidadão a serviços essenciais, impacto na operação dos órgãos e dano à reputação institucional da PRODEMGE.

RNF-01.1 — Disponibilidade de Serviços Críticos

Critério: disponibilidade mensal mínima de 99,5% para serviços classificados como Críticos, medida como proporção de minutos disponíveis sobre o total de minutos no mês. A medição utiliza o critério conservador: um minuto é considerado indisponível se o probe sintético externo falhar OU se a taxa de erros HTTP 5xx superar 5% em janela de 5 minutos. A apuração exclui janelas de manutenção programada (máximo de 4 horas mensais, com comunicação prévia de 72 horas).

Mecanismo de implementação: múltiplas réplicas de cada serviço crítico no cluster Kubernetes; rolling update como estratégia padrão de deploy, preservando disponibilidade durante atualizações; circuit breakers em todas as dependências externas; health checks ativos por componente com restart automático em caso de falha; cluster de banco de dados PostgreSQL com replicação síncrona e failover automático; cluster Redis em modo Sentinel para o cache distribuído; cluster RabbitMQ com espelhamento de filas.

Referência de implementação: Capítulos 38, 47, 53.

RNF-01.2 — Disponibilidade de Serviços de Alto Impacto

Critério: disponibilidade mensal mínima de 99,0% para serviços classificados como Alto Impacto, com os mesmos critérios de medição do RNF-01.1.

RNF-01.3 — Disponibilidade de Serviços de Médio e Baixo Impacto

Critério: disponibilidade mensal mínima de 98,0% para serviços classificados como Médio Impacto e 95,0% para Baixo Impacto.

RNF-01.4 — RTO (Recovery Time Objective)

Critério: o tempo máximo de restauração do serviço após um incidente de nível S1 (indisponibilidade total de serviço crítico) é de 4 horas. Para incidentes S2 (degradação significativa de serviço crítico), o RTO é de 8 horas. A contagem inicia no momento de detecção do incidente pelo sistema de monitoramento, não no momento de reporte pela equipe de operação.

RNF-01.5 — RPO (Recovery Point Objective)

Critério: o RPO máximo para dados transacionais (solicitações, interações CRM, documentos) é de 1 hora, garantido por backups incrementais contínuos e replicação de banco de dados. Para dados de configuração e parâmetros de tenant, o RPO é de 15 minutos.

RNF-01.6 — Resiliência a Falhas de Dependências Externas

Critério: a falha de qualquer integração com sistema externo (Gov.br, SEI!MG, MG API, provedores de IA) não pode causar indisponibilidade dos módulos core da plataforma. A plataforma opera em modo degradado quando dependências externas estão indisponíveis, com funcionalidade local preservada e indicação transparente ao usuário das capacidades temporariamente reduzidas.

Mecanismo: circuit breakers com timeout configurado por integração; fallback local para dados cacheados quando a integração está indisponível; filas de mensageria RabbitMQ para processamento assíncrono de operações que não requerem resposta imediata.

RNF-01.7 — Isolamento de Falhas entre Tenants

Critério: a falha de qualquer componente específico de um tenant (configuração inválida, processo com consumo anormal de recursos, volume extraordinário de requisições) não pode causar degradação de disponibilidade em outros tenants. O isolamento é estrutural, não apenas por controle de tráfego.

Mecanismo: tenant context propagado em ThreadLocal no backend, com discriminador de tenant em todas as queries de banco de dados; resource quotas por namespace Kubernetes por tenant de alta criticidade; rate limiting por tenant no API Gateway.

Referência: Capítulos 30, 38, 53.

74.4.2 Domínio RNF-02 — Desempenho e Escalabilidade

O desempenho é percebido pelo cidadão como a qualidade da experiência digital. Uma plataforma lenta é, na prática, uma plataforma inacessível para parcelas da população com conexões mais lentas ou dispositivos menos potentes.

RNF-02.1 — Latência de APIs de Autenticação

Critério: tempo de resposta de APIs de autenticação (login, refresh de token) ≤ 200ms no percentil P50, ≤ 500ms no P95 e ≤ 1.000ms no P99, medidos em condições de carga normal (até 70% da capacidade máxima). A medição é sobre a requisição completa, incluindo serialização, processamento e serialização de resposta, excluindo latência de rede entre cliente e servidor.

RNF-02.2 — Latência de APIs Transacionais

Critério: APIs de criação e atualização de dados (CRM, BPM, solicitações) ≤ 300ms no P50, ≤ 800ms no P95 e ≤ 1.500ms no P99.

RNF-02.3 — Latência de APIs de Consulta

Critério: APIs de leitura e consulta de dados ≤ 200ms no P50, ≤ 600ms no P95 e ≤ 1.200ms no P99.

RNF-02.4 — Latência de Upload de Documentos

Critério: upload de documentos de até 10MB ≤ 1.000ms no P50, ≤ 3.000ms no P95 e ≤ 5.000ms no P99. Para documentos maiores (até 50MB, quando permitido pela configuração do tenant), o limite P95 é de 10.000ms.

RNF-02.5 — Latência de Respostas do Copiloto de IA

Critério: tempo até primeira resposta do copiloto de IA ≤ 1.500ms no P50, ≤ 3.500ms no P95 e ≤ 6.000ms no P99. O critério se aplica à primeira resposta (streaming habilitado); o tempo de geração completa de respostas longas não está no escopo deste critério de latência.

RNF-02.6 — Performance do Portal Web (Core Web Vitals)

Critério: o Portal Web deve manter, em condições de rede 4G e dispositivo de referência (smartphone mid-range):

• LCP (Largest Contentful Paint): ≤ 2,5 segundos;
• INP (Interaction to Next Paint): ≤ 200ms;
• CLS (Cumulative Layout Shift): ≤ 0,1.

Esses valores correspondem à classificação "Bom" conforme as métricas Core Web Vitals do Google, que refletem a experiência real do usuário.

RNF-02.7 — Throughput Sustentado

Critério: a plataforma suporta 500 requisições por segundo (RPS) no agregado de todos os tenants, distribuídas entre serviços de nível Crítico, sem degradação dos indicadores de latência dos requisitos RNF-02.1 a RNF-02.3. O patamar de 500 RPS é o dimensionamento base; o sistema expande automaticamente quando o volume observado supera 80% desse limite.

RNF-02.8 — Escalabilidade Horizontal

Critério: todos os microsserviços da plataforma são stateless por design, permitindo escalabilidade horizontal por adição de réplicas sem coordenação adicional. O estado de sessão é externalizado no Redis; o estado de processo é persistido no banco de dados; mensagens pendentes residem no RabbitMQ. A adição de réplicas de qualquer serviço é transparente para os demais serviços e para os clientes.

RNF-02.9 — Autoscaling

Critério: o Kubernetes implementa Horizontal Pod Autoscaler (HPA) para todos os serviços críticos, com base em métricas de CPU, memória e comprimento de filas de mensageria. O tempo de provisionamento de novas réplicas (desde o disparo da condição de escalonamento até a réplica estar aceitando tráfego) é inferior a 90 segundos para 90% dos eventos de escalonamento.

RNF-02.10 — Taxa de Erro de Aplicação

Critério: a taxa de erros de aplicação (respostas HTTP 5xx divididas pelo total de requisições) deve ser inferior a 0,1% em janela de 5 minutos para serviços Críticos e inferior a 0,5% para demais serviços. Superação desses limiares por mais de 2 minutos consecutivos aciona alerta de incidente e inicia protocolo de resposta.

Referência: Capítulos 35, 37, 38, 41, 53.

74.4.3 Domínio RNF-03 — Segurança da Informação

A segurança é requisito transversal — não há componente da plataforma que seja excluído do escopo de segurança.

RNF-03.1 — Autenticação Multifator

Critério: autenticação multifator (MFA) é obrigatória para todos os usuários com perfil administrativo (Administrador Tenant, Administrador Global, Gestor de Processos) e para cidadãos em operações de alto risco (alteração de cadastro, acesso a documentos sensíveis, solicitações que impliquem obrigações financeiras). A autenticação MFA é suportada via TOTP (Time-based One-Time Password) e via integração com Gov.br para cidadãos.

RNF-03.2 — Criptografia em Trânsito

Critério: toda comunicação de rede é criptografada. TLS 1.3 é o protocolo mínimo obrigatório para comunicações externas (entre clientes e a plataforma, e entre a plataforma e sistemas externos). mTLS (mutual TLS) é o protocolo obrigatório para comunicações internas entre microsserviços. TLS 1.2 e versões anteriores são desabilitados na configuração dos servidores. Certificados TLS têm validade máxima de 90 dias com renovação automática.

RNF-03.3 — Criptografia em Repouso

Critério: dados classificados como Sensível, Restrito ou Crítico (conforme taxonomia do Capítulo 44) são armazenados com criptografia AES-256-GCM em repouso. Backups são criptografados com a mesma política. Chaves de criptografia são gerenciadas pelo serviço de gestão de segredos, com rotação mínima anual e sem armazenamento de chaves em código-fonte ou variáveis de ambiente não criptografadas.

RNF-03.4 — Controle de Acesso Baseado em Perfis e Contexto

Critério: o sistema de autorização implementa RBAC (Role-Based Access Control) para permissões estruturais e ABAC (Attribute-Based Access Control) para permissões contextuais (baseadas em tenant, unidade organizacional, estado do processo, classificação do dado). Nenhuma operação sobre dado de um tenant é acessível a usuários autenticados em contexto de tenant diferente, mesmo com perfil administrativo elevado.

RNF-03.5 — Gestão de Segredos

Critério: nenhum segredo (senha, token, chave de API, certificado, string de conexão) é armazenado em código-fonte, arquivos de configuração não criptografados ou variáveis de ambiente sem proteção. Todos os segredos são gerenciados pelo cofre de segredos (Secrets Manager) com rotação automática. Scanning automático de segredos é executado em cada commit no pipeline de CI/CD.

RNF-03.6 — Proteção contra Ataques Comuns (OWASP Top 10)

Critério: a plataforma implementa controles preventivos para todos os itens da OWASP Top 10. SAST (Static Application Security Testing) e DAST (Dynamic Application Security Testing) são executados no pipeline de CI/CD, com bloqueio de deploy se vulnerabilidades críticas forem detectadas. Testes de penetração são realizados semestralmente por equipe independente.

RNF-03.7 — Rate Limiting e Proteção contra Abuso

Critério: rate limiting é aplicado por IP, por usuário autenticado e por tenant no API Gateway. Os limites padrão são: 100 requisições por minuto por IP não autenticado; 1.000 requisições por minuto por usuário autenticado; configurável por tenant para necessidades específicas. Excedimento do limite retorna HTTP 429 com cabeçalho Retry-After. DDoS protection está habilitada na camada de borda.

RNF-03.8 — Resposta a Incidentes de Segurança

Critério: a equipe de segurança é notificada em até 15 minutos após a detecção automática de evento de segurança relevante (tentativa de acesso não autorizado, anomalia de comportamento, violação de política). Incidentes de segurança que afetam dados pessoais são notificados à PRODEMGE em até 2 horas da confirmação, e à ANPD nos prazos legais (72 horas após ciência, conforme art. 48 da LGPD).

Referência: Capítulos 17, 42, 43, 46.

74.4.4 Domínio RNF-04 — Conformidade Legal e Regulatória

RNF-04.1 — Conformidade com a LGPD

Critério: a plataforma opera em conformidade integral com a Lei nº 13.709/2018 (LGPD). Os mecanismos de conformidade incluem: base legal declarada e documentada para cada tipo de tratamento de dado pessoal; consentimento granular por finalidade, revogável a qualquer tempo pelo titular; atendimento de direitos do titular (acesso, correção, portabilidade, exclusão) em até 15 dias úteis; encarregado de dados (DPO) designado; relatório de impacto à proteção de dados (RIPD) para tratamentos de alto risco; processo de notificação de incidentes à ANPD.

RNF-04.2 — Conformidade com eMAG

Critério: o Portal Web e o Aplicativo Mobile atendem ao eMAG (Modelo de Acessibilidade em Governo Eletrônico), padrão estabelecido pelo Governo Federal para soluções digitais de serviço público, em complemento às diretrizes WCAG 2.1 nível AA.

RNF-04.3 — Conformidade com Padrões de Segurança

Critério: a arquitetura de segurança é alinhada ao NIST Cybersecurity Framework (CSF) e às diretrizes OWASP. O programa de segurança inclui avaliações periódicas de conformidade com esses padrões, com registro de desvios e planos de remediação.

RNF-04.4 — Rastreabilidade para Fins de Fiscalização

Critério: a plataforma mantém trilha de auditoria imutável de todas as ações com impacto em dados de cidadãos ou em decisões de processo, com retenção mínima de 5 anos. Consultas à trilha de auditoria são restritas a perfis autorizados e são elas próprias registradas. A trilha é armazenada em store segregado, inacessível à aplicação principal para escrita após o registro inicial.

Referência: Capítulos 44, 45.

74.4.5 Domínio RNF-05 — Usabilidade e Acessibilidade

RNF-05.1 — Conformidade WCAG 2.1 Nível AA

Critério: o Portal Web e o Aplicativo Mobile atendem ao nível AA das Diretrizes de Acessibilidade para Conteúdo Web (WCAG) 2.1 do W3C. Verificação automatizada (ferramentas WAVE e axe) e manual (testes com leitores de tela NVDA, JAWS e VoiceOver) são executadas no pipeline de CI/CD e por ciclo de release. Violações de nível AA bloqueiam o deploy de produção.

RNF-05.2 — Navegação por Teclado

Critério: toda funcionalidade da plataforma é acessível exclusivamente por teclado, sem dependência de mouse ou toque. A ordem de foco segue a sequência lógica de leitura. Nenhuma armadilha de foco: o usuário pode navegar para fora de qualquer componente interativo usando apenas o teclado.

RNF-05.3 — Contraste de Cores

Critério: a relação de contraste entre texto e background é mínima de 4,5:1 para texto normal e 3,0:1 para texto grande (≥ 18pt ou ≥ 14pt negrito), conforme WCAG 2.1 critério 1.4.3. Ícones interativos mantêm contraste mínimo de 3,0:1 com o background adjacente.

RNF-05.4 — Responsividade

Critério: o Portal Web é responsivo para as dimensões de tela de smartphones (320px a 480px), tablets (768px a 1024px) e desktops (1280px e acima), sem perda de funcionalidade em nenhuma dimensão suportada. A interface se adapta ao espaço disponível sem necessidade de scroll horizontal.

RNF-05.5 — Suporte a Redimensionamento

Critério: o Portal Web é funcional com zoom do navegador de até 200%, sem perda de conteúdo ou funcionalidade, conforme WCAG 2.1 critério 1.4.4. Usuários que necessitam de tamanho de fonte aumentado podem usar o recurso de zoom sem consequência funcional.

RNF-05.6 — Compatibilidade com Leitores de Tela

Critério: a plataforma é compatível com NVDA (Windows), JAWS (Windows) e VoiceOver (macOS e iOS) nas versões recentes, e com TalkBack (Android). Toda informação visual é acompanhada de equivalente textual acessível via ARIA labels ou texto alternativo. Atualizações dinâmicas de conteúdo são comunicadas ao leitor de tela via aria-live.

RNF-05.7 — Mensagens de Erro Claras

Critério: mensagens de erro identificam com precisão o campo ou ação que gerou o erro, descrevem o problema em linguagem compreensível e indicam como corrigi-lo. Mensagens de erro não expõem informações técnicas (stack traces, identificadores internos de banco de dados, detalhes de implementação) ao usuário final.

Referência: Capítulos 25, 26, 32, 33.

74.4.6 Domínio RNF-06 — Manutenibilidade e Evolução

RNF-06.1 — Cobertura de Testes Automatizados

Critério: cobertura mínima de testes unitários de 80% nas classes de domínio e serviço de aplicação (camadas de negócio); cobertura mínima de 60% nas classes de infraestrutura; testes de integração cobrindo todos os contratos de API expostos por cada microsserviço; testes end-to-end cobrindo os fluxos críticos do cidadão (autenticação, submissão de solicitação, acompanhamento de protocolo, upload de documento). A cobertura é verificada automaticamente no pipeline de CI/CD, com bloqueio de merge se o limite não for atingido.

RNF-06.2 — Arquitetura Modular com Baixo Acoplamento

Critério: microsserviços se comunicam exclusivamente por contratos estáveis (APIs REST documentadas em OpenAPI ou eventos tipados em RabbitMQ). Nenhum microsserviço acessa diretamente o banco de dados de outro microsserviço. Alterações internas em um microsserviço não requerem mudanças em microsserviços consumidores, desde que o contrato da API permaneça compatível.

RNF-06.3 — Versionamento de APIs

Critério: todas as APIs públicas da plataforma são versionadas semanticamente. Alterações incompatíveis (breaking changes) são introduzidas apenas em nova versão principal de API (v2, v3), mantendo a versão anterior ativa por período mínimo de 6 meses. A depreciação de versão é comunicada formalmente à PRODEMGE e aos integradores com antecedência mínima de 90 dias.

RNF-06.4 — Documentação de Decisões Arquiteturais

Critério: toda decisão arquitetural relevante é registrada como Architecture Decision Record (ADR), com contexto, alternativas consideradas, decisão tomada, justificativa e consequências. ADRs são armazenados no repositório de código junto à base de código que implementa a decisão.

RNF-06.5 — Tempo de Deploy

Critério: o pipeline de CI/CD completo (desde o commit no repositório até a disponibilidade em produção) tem duração máxima de 30 minutos para alterações em um microsserviço isolado, incluindo execução de testes automatizados, análise de segurança, build da imagem e deploy com rolling update. Em caso de falha de smoke tests após o deploy, o rollback automático ocorre em menos de 5 minutos.

RNF-06.6 — Retrocompatibilidade de Banco de Dados

Critério: migrações de banco de dados são aplicadas de forma retrocompatível (expand-contract pattern): as alterações de schema são introduzidas em fases que permitem ao código antigo e ao novo coexistir com o mesmo banco de dados. Nenhuma migração pode tornar o banco incompatível com a versão anterior do código antes que a nova versão esteja em produção e estável.

Referência: Capítulos 31, 34, 40, 55.

74.4.7 Domínio RNF-07 — Portabilidade e Interoperabilidade

RNF-07.1 — Portabilidade de Infraestrutura

Critério: a plataforma opera em qualquer provedor de nuvem pública (AWS, Azure, GCP e equivalentes), em nuvem privada e em ambiente on-premise, sem alterações de código-fonte. A portabilidade é assegurada pela abstração de infraestrutura via Kubernetes e Helm charts, com parametrização de endpoints e configurações de ambiente via variáveis de ambiente injetadas pelo cluster.

RNF-07.2 — Adoção de Padrões Abertos

Critério: todas as APIs da plataforma utilizam protocolos e formatos abertos e padronizados: REST com JSON sobre HTTP/1.1 e HTTP/2, com especificações OpenAPI 3.0; OAuth 2.0 com PKCE para autorização delegada; OpenID Connect 1.0 para autenticação federada; BPMN 2.0 para modelagem de processos; MIME types padronizados para documentos. Nenhuma API utiliza protocolo proprietário que crie dependência de fornecedor.

RNF-07.3 — Interoperabilidade com Ecossistema PRODEMGE

Critério: a plataforma integra-se com os sistemas do ecossistema PRODEMGE (SEI!MG, Portal de Municípios, PROBPMS, Agenda Minas, MG API, DATALAKE MG, MG-Ouv, PRO SMTP, SEG.ID) pelos contratos de integração publicados por cada sistema, sem exigir modificações nesses sistemas. A integração é gerenciada pelo API Gateway e pelo módulo de integrações da plataforma.

RNF-07.4 — Exportabilidade de Dados

Critério: dados de um tenant são exportáveis em formatos abertos (JSON, CSV, XML) mediante solicitação à PRODEMGE, sem dependência de ferramentas proprietárias para leitura e processamento. O formato de exportação preserva a estrutura e os relacionamentos dos dados, permitindo importação em sistemas alternativos. Esse requisito suporta tanto o direito à portabilidade de dados pessoais (LGPD, art. 18, V) quanto os requisitos de reversibilidade previstos na Minuta de Contrato.

Referência: Capítulos 14, 37, 38.

74.4.8 Domínio RNF-08 — Observabilidade e Auditabilidade

RNF-08.1 — Cobertura de Instrumentação

Critério: todos os microsserviços e componentes de infraestrutura emitem os três pilares de observabilidade — logs estruturados, métricas dimensionais e traces distribuídos — via OpenTelemetry. Nenhum componente em produção opera sem instrumentação ativa. A instrumentação é verificada como parte dos critérios de prontidão para deploy (readiness gate do pipeline).

RNF-08.2 — Correlação de Eventos

Critério: todas as operações iniciadas por uma requisição de usuário são rastreáveis de ponta a ponta por meio de um identificador de correlação (correlationId) único, gerado na borda (API Gateway) e propagado por todo o grafo de chamadas entre microsserviços, incluindo chamadas assíncronas via RabbitMQ. O correlationId é incluído em todos os logs, métricas e spans relacionados à operação.

RNF-08.3 — Retenção de Logs

Critério: logs são retidos conforme a classificação:

• Logs de auditoria: retenção mínima de 5 anos;
• Logs de erro (ERROR): retenção de 90 dias;
• Logs de aviso (WARN): retenção de 30 dias;
• Logs de informação (INFO): retenção de 14 dias;
• Logs de depuração (DEBUG): desabilitados em produção por padrão; quando habilitados temporariamente para diagnóstico, retenção de 3 dias.

RNF-08.4 — Tempo de Detecção de Anomalia

Critério: anomalias operacionais relevantes (degradação de disponibilidade, aumento de latência acima do P95 definido, taxa de erro superando o limiar) são detectadas e o alerta é disparado em até 2 minutos após o início da condição anômala, medido com probes sintéticos executados a cada 60 segundos.

RNF-08.5 — Auditabilidade de Ações Administrativas

Critério: toda ação realizada por usuários com perfil administrativo (criação de usuário, alteração de permissão, configuração de tenant, exclusão de dado) é registrada na trilha de auditoria com: timestamp UTC, identificador do usuário, perfil no momento da ação, tenant contexto, operação realizada, estado anterior e estado posterior dos dados afetados. Registros de auditoria são imutáveis após a criação.

RNF-08.6 — Dashboard de SLA em Tempo Real

Critério: a PRODEMGE e os administradores dos órgãos têm acesso a painel de disponibilidade em tempo real, atualizado a cada 60 segundos para indicadores de disponibilidade e em tempo real para status de incidentes ativos. O painel não exige autenticação para visualização da disponibilidade agregada; dados de incidentes com detalhe técnico exigem autenticação com perfil de administrador.

Referência: Capítulos 41, 45, 53.

74.4.9 Domínio RNF-09 — Capacidade e Dimensionamento

RNF-09.1 — Volume de Uploads Simultâneos

Critério: a plataforma suporta 100 uploads simultâneos de documentos de até 10MB cada sem degradação dos indicadores de latência dos requisitos RNF-02.1 a RNF-02.3 para os demais serviços.

RNF-09.2 — Sessões de IA Simultâneas

Critério: a plataforma suporta 200 sessões simultâneas de copiloto de IA (conversas ativas com geração de resposta em andamento) sem degradação de latência além dos limiares definidos em RNF-02.5.

RNF-09.3 — Volume de Tenants

Critério: a arquitetura multi-tenant suporta até 200 tenants ativos simultaneamente sem degradação de desempenho, cada um com sua configuração, dados, usuários e processos completamente isolados.

RNF-09.4 — Volume de Usuários por Tenant

Critério: cada tenant suporta até 10.000 usuários cadastrados, com até 1.000 usuários ativos simultaneamente, sem degradação de desempenho.

RNF-09.5 — Retenção e Volume de Dados

Critério: a plataforma suporta o crescimento de volume de dados por 5 anos sem degradação de desempenho de consulta, assegurado por estratégias de particionamento de banco de dados por tenant, indexação otimizada por padrão de acesso, arquivamento de dados históricos e cache de resultados frequentes.

RNF-09.6 — Notificação de Proximidade de Limite

Critério: quando o volume observado de qualquer indicador de capacidade (RPS, uploads simultâneos, sessões de IA, usuários ativos) superar 80% do limite provisionado, a plataforma notifica a PRODEMGE automaticamente e inicia o processo de expansão de capacidade. A expansão automática via Kubernetes HPA ocorre em menos de 90 segundos; expansão de infraestrutura base (quando HPA não for suficiente) é planejada em conjunto com a PRODEMGE com antecedência mínima de 5 dias úteis.

Referência: Capítulos 35, 37, 38, 53.

74.4.10 Domínio RNF-10 — Privacidade e Proteção de Dados

RNF-10.1 — Privacy by Design

Critério: privacidade é incorporada no design de toda nova funcionalidade antes de sua implementação. Toda funcionalidade que processa dados pessoais é submetida a uma avaliação de privacidade prévia (Privacy Impact Assessment simplificado), documentada e aprovada pelo DPO antes do desenvolvimento. Nenhuma funcionalidade que introduz novo tipo de coleta de dado pessoal pode ser implantada sem essa avaliação.

RNF-10.2 — Minimização de Dados

Critério: a plataforma coleta apenas os dados estritamente necessários para a finalidade declarada de cada interação. Campos opcionais não podem ser convertidos em obrigatórios por configuração de tenant. Logs não retêm dados pessoais identificáveis além do mínimo necessário para rastreabilidade de incidente (técnica de redaction aplicada antes do armazenamento).

RNF-10.3 — Exclusão e Portabilidade de Dados Pessoais

Critério: o exercício do direito de exclusão (LGPD, art. 18, VI) aciona processo de exclusão em cascata que percorre todas as camadas onde o dado pode residir: banco de dados transacional, cache Redis, índices de busca, Data Lake, backups (mediante marcação para exclusão na próxima rotação). A portabilidade (LGPD, art. 18, V) é atendida por exportação do perfil completo do titular em formato JSON aberto em até 15 dias úteis.

RNF-10.4 — Isolamento de Dados entre Tenants

Critério: dados de um tenant são completamente inacessíveis a usuários de outros tenants, a administradores da plataforma sem autorização explícita da PRODEMGE e à própria equipe de operação da parceira em atividades de rotina. Acesso a dados de tenant por equipe de operação para fins de diagnóstico requer autorização formal, é registrado na trilha de auditoria e é restrito ao mínimo necessário para resolução do incidente.

RNF-10.5 — Transferência Internacional de Dados Pessoais

Critério: transferência de dados pessoais para sistemas externos localizados fora do Brasil (provedores de IA, provedores de infraestrutura) é realizada somente com salvaguardas adequadas: cláusulas contratuais-padrão, anonimização ou pseudonimização dos dados antes da transferência, ou residência de dados em território nacional quando tecnicamente viável. A política de transferência é documentada e revisada anualmente.

Referência: Capítulos 17, 44.

74.5 Arquitetura

Os requisitos não funcionais não são implementados por um único componente — são propriedades emergentes da combinação de múltiplas decisões arquiteturais distribuídas pela plataforma. A organização abaixo ilustra como os domínios de requisito se mapeiam às camadas da arquitetura:

┌─────────────────────────────────────────────────────────────────┐
│                        BORDA / GATEWAY                          │
│  RNF-02 (Rate Limiting, Throughput)                             │
│  RNF-03 (TLS 1.3, DDoS, WAF, Autenticação)                     │
│  RNF-07 (Padrões abertos, Versionamento)                        │
└──────────────────────────┬──────────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────────┐
│                   CAMADA DE APLICAÇÃO                           │
│  RNF-01 (Réplicas, Health Checks, Circuit Breakers)             │
│  RNF-02 (Stateless, Autoscaling, Latência)                      │
│  RNF-03 (RBAC/ABAC, mTLS entre serviços, Secrets)              │
│  RNF-05 (Mensagens de erro, Acessibilidade no frontend)         │
│  RNF-06 (Testes, Modularidade, Versionamento de API)            │
│  RNF-08 (OpenTelemetry, CorrelationId, Logs estruturados)       │
│  RNF-10 (Privacy by Design, Minimização, Redaction)             │
└──────────────────────────┬──────────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────────┐
│                   CAMADA DE DADOS                               │
│  RNF-01 (Replicação BD, Cluster Redis, Backup/RTO/RPO)         │
│  RNF-03 (Criptografia em repouso AES-256-GCM)                  │
│  RNF-04 (Auditoria imutável, Rastreabilidade 5 anos)            │
│  RNF-09 (Particionamento, Volume, Indexação)                    │
│  RNF-10 (Exclusão em cascata, Isolamento multi-tenant)          │
└──────────────────────────┬──────────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────────┐
│                   CAMADA DE INFRAESTRUTURA                      │
│  RNF-01 (Kubernetes multi-réplica, Failover, RTO/RPO)          │
│  RNF-02 (HPA, VPA, Auto-scaling, Deploy sem downtime)           │
│  RNF-07 (Portabilidade Kubernetes, Helm, Cloud/On-premise)      │
│  RNF-08 (Prometheus, Loki, Jaeger, Alertas)                     │
│  RNF-09 (Dimensionamento, Expansão, Quotas)                     │
└─────────────────────────────────────────────────────────────────┘

Nenhum requisito não funcional é atendido por uma única camada. Disponibilidade, por exemplo, requer réplicas na camada de aplicação (RNF-01), replicação na camada de dados (RNF-01) e orquestração de failover na camada de infraestrutura (RNF-01). Essa redundância arquitetural — onde cada camada reforça a propriedade pretendida — é o que torna os requisitos alcançáveis em produção.

74.6 Fluxos

74.6.1 Fluxo de Verificação de Cumprimento de RNF em Deploy

Commit no repositório
    │
Pipeline CI/CD iniciado
    │
Análise de código (SAST, cobertura de testes, scanning de segredos)
    │
Build e testes automatizados (unitários, integração, contrato de API)
    │
Análise de segurança (DAST em ambiente de staging)
    │
Verificação de instrumentação (todos os serviços emitem telemetria?)
    │
Deploy em staging com tráfego sintético
    │
Verificação de métricas P50/P95/P99 (RNF-02) em staging
    │
Verificação de acessibilidade automatizada (RNF-05) em staging
    │
Aprovação humana (se alteração em serviço Crítico)
    │
Deploy em produção via rolling update (RNF-06)
    │
Smoke tests pós-deploy
    │
Monitoramento de anomalia nas primeiras 2 horas (RNF-08)
    │
Conclusão do deploy ou rollback automático

74.6.2 Fluxo de Detecção e Resposta a Violação de RNF em Produção

Probe sintético detecta anomalia (latência > P95 ou taxa de erro > limiar)
    │
Alerta disparado em até 2 minutos (RNF-08.4)
    │
Classificação automática de severidade (S1 a S4)
    │
Notificação do engenheiro on-call
    │
Diagnóstico via traces (correlationId) e logs estruturados
    │
Identificação do componente afetado
    │
Remediação: rollback automático OU escalonamento OU intervenção manual
    │
Confirmação de retorno aos parâmetros dos RNFs
    │
Registro de postmortem (incidentes S1 e S2)
    │
Atualização do relatório de SLA mensal

74.7 Diagramas

74.7.1 Mapa de Domínios de RNF por Camada Arquitetural (Nível Contexto)

O diagrama de contexto mostra a plataforma no centro, com os dez domínios de RNF distribuídos como atributos de qualidade observáveis de fora: usuários e sistemas externos observam disponibilidade (RNF-01), desempenho (RNF-02), segurança (RNF-03) e usabilidade (RNF-05); auditores e reguladores observam conformidade (RNF-04) e privacidade (RNF-10); a equipe de operação observa observabilidade (RNF-08) e capacidade (RNF-09); a equipe de engenharia observa manutenibilidade (RNF-06) e portabilidade (RNF-07).

74.7.2 Hierarquia de Requisitos por Criticidade (Nível Contêiner)

Diagrama de contêineres mostrando quatro faixas de criticidade (Crítico, Alto, Médio, Baixo) com os serviços da plataforma posicionados em cada faixa, e os requisitos RNF-01 e RNF-02 aplicados por faixa com seus critérios numéricos correspondentes. O diagrama ilustra que os requisitos são diferenciados — não se aplica o mesmo SLA a todos os serviços — o que permite equilíbrio entre custo operacional e nível de serviço.

74.8 Exemplos

74.8.1 Exemplo: Verificação de RNF-02.1 em Produção

O sistema de monitoramento coleta continuamente a latência de autenticação. Em um período de pico às 10h de uma segunda-feira, o P95 de latência de login atinge 480ms — dentro do limite de 500ms. O sistema registra a métrica normalmente. Se o P95 atingisse 520ms por mais de 2 minutos, um alerta seria disparado, classificado como S3 (degradação de serviço crítico sem indisponibilidade completa), notificando o engenheiro de plantão para investigação.

{
  "timestamp": "2026-07-17T10:12:00Z",
  "metric": "http_request_duration_seconds",
  "endpoint": "/auth/login",
  "tenant": "aggregate",
  "p50_ms": 185,
  "p95_ms": 480,
  "p99_ms": 890,
  "rps": 87,
  "rnf_status": {
    "RNF-02.1_p50": "OK (185ms ≤ 200ms)",
    "RNF-02.1_p95": "OK (480ms ≤ 500ms)",
    "RNF-02.1_p99": "OK (890ms ≤ 1000ms)"
  }
}

74.8.2 Exemplo: Verificação de RNF-05.1 no Pipeline

A cada pull request que modifica componentes de interface, o pipeline executa o axe em modo headless sobre o portal renderizado:

# Execução automatizada de acessibilidade no CI
npx axe http://staging.portal:3000 \
  --include main \
  --rules wcag2aa \
  --reporter json \
  --stdout > accessibility-report.json

# Verificação de violações críticas
VIOLATIONS=$(jq '[.violations[] | select(.impact == "critical" or .impact == "serious")] | length' accessibility-report.json)

if [ "$VIOLATIONS" -gt 0 ]; then
  echo "BLOQUEADO: $VIOLATIONS violações WCAG 2.1 AA detectadas"
  jq '.violations[] | select(.impact == "critical" or .impact == "serious") | {id, impact, description}' accessibility-report.json
  exit 1
fi

74.8.3 Exemplo: Trace de Requisição com CorrelationId (RNF-08.2)

correlationId: corr-8f4a-2b91-7c3e
tenantId: tenant-secretaria-fazenda
userId: user-servidor-0012

→ API Gateway (5ms): autenticação do token validada
→ Request Service (145ms): submissão de solicitação de habilitação
  → Document Service (78ms): validação do RG digitalizado
  → BPM Engine (12ms): criação de instância de processo de habilitação
  → RabbitMQ publish (3ms): evento SolicitacaoSubmetida publicado
← Resposta: 201 Created, protocolo NR-2026-047821

Total: 158ms (P95 RNF-02.2: 800ms — dentro do limite)

74.9 Boas Práticas

Requisitos não funcionais só têm valor quando são mensuráveis, verificados e monitorados continuamente. Algumas práticas estruturais que garantem a efetividade do catálogo definido neste capítulo:

Os critérios de aceitação são expressos em valores numéricos com percentil definido. "Rápido" não é um requisito. "P95 ≤ 500ms medido em carga de 70% da capacidade" é um requisito. A precisão do critério determina se o requisito pode ser verificado objetivamente.

Os testes de requisitos não funcionais são executados em cada ciclo de release, não apenas em testes de carga periódicos. Testes de performance em staging, verificações de acessibilidade no pipeline e análise de segurança no CI são o mecanismo de detecção precoce de regressão de atributos de qualidade.

O monitoramento de produção é a única fonte de verdade sobre o cumprimento de RNFs. Critérios verificados apenas em testes controlados não garantem comportamento em produção sob carga real e padrões reais de uso.

Quando há tensão entre dois requisitos (velocidade de deploy versus disponibilidade; funcionalidade versus acessibilidade; coleta de dados para melhoria versus minimização de PII), a tensão é registrada como trade-off explícito — não resolvida pela supressão de um dos requisitos sem decisão documentada.

74.10 Justificativas Técnicas das Decisões

Por que diferenciar RNFs por nível de criticidade em vez de aplicar o mesmo padrão a todos os serviços?

A aplicação do mesmo nível de SLA a todos os serviços resulta em dois problemas: ou o SLA é muito exigente para serviços de baixa criticidade (custo de infraestrutura desnecessariamente elevado), ou é permissivo demais para serviços críticos (risco inaceitável para a operação). A diferenciação por criticidade (Crítico, Alto, Médio, Baixo) reflete a realidade dos serviços: autenticação e submissão de solicitação têm impacto imediato ao cidadão; analytics e dashboards podem tolerar breves indisponibilidades sem impacto operacional.

Por que o critério de disponibilidade usa o operador "OU" entre probe e taxa de erro?

O critério conservador protege o órgão cliente. Um serviço pode ter todos os pods saudáveis internamente mas estar devolvendo erros para um subconjunto de usuários por problema de configuração de rede, bug em determinado fluxo ou indisponibilidade de uma dependência. Exigir que os dois indicadores confirmem degradação favoreceria a plataforma na apuração em detrimento da experiência do usuário.

Por que WCAG 2.1 nível AA e não apenas nível A?

O nível A cobre apenas as falhas de acessibilidade mais básicas. O nível AA corresponde ao padrão exigido por legislações de acessibilidade digital em múltiplos países e é o nível de referência do eMAG para soluções de governo eletrônico no Brasil. Exigir apenas o nível A resultaria em uma plataforma formalmente acessível mas praticamente inutilizável para usuários com deficiência visual ou motora.

Por que Privacy by Design como RNF e não apenas como diretriz?

Quando privacidade é apenas uma diretriz, é avaliada retrospectivamente — ao final do desenvolvimento, onde o custo de correção é máximo. Como RNF com critério verificável (toda funcionalidade que processa dados pessoais passa por avaliação de privacidade prévia), a conformidade com a LGPD é verificada antes que o código seja escrito, quando o custo de ajuste é mínimo.

74.11 Trade-offs

Disponibilidade versus custo de infraestrutura. Disponibilidade de 99,5% para serviços críticos exige múltiplas réplicas, cluster de banco de dados com replicação síncrona e monitoramento 24×7. O custo de infraestrutura é maior do que seria com instâncias únicas. O trade-off é deliberado: para uma plataforma de serviços públicos, indisponibilidade tem custo social e reputacional que excede o custo de infraestrutura redundante.

Latência versus consistência. Requisitos de latência rigorosos (P95 ≤ 500ms para autenticação) favorecem o uso intensivo de cache Redis — o que implica eventual consistency em alguns cenários. O trade-off é gerenciado por invalidação ativa de cache em operações de escrita e por TTLs conservadores para dados de alta criticidade (permissões, perfil de usuário).

Segurança versus usabilidade. MFA obrigatório para perfis administrativos adiciona fricção ao fluxo de autenticação. A decisão de manter o MFA obrigatório reflete o risco assimétrico: a consequência de uma conta administrativa comprometida (acesso a dados de todo o tenant) é muito mais grave que o inconveniente de um passo adicional de autenticação.

Minimização de dados versus capacidade analítica. O requisito de minimização (RNF-10.2) limita a coleta de dados pessoais ao estritamente necessário, o que restringe algumas capacidades analíticas que dependeriam de dados mais granulares. O trade-off é resolvido pela anonimização antes do uso analítico: dados pessoais são pseudonimizados ou agregados antes de alimentar o Data Lake de analytics, preservando utilidade analítica sem expor dados individuais.

Cobertura de testes versus velocidade de desenvolvimento. O requisito de 80% de cobertura em classes de domínio cria overhead no ciclo de desenvolvimento. O trade-off é aceito porque o custo de regressões em produção em uma plataforma de serviços públicos — falhas em fluxos críticos do cidadão, dados corrompidos — excede amplamente o custo de manutenção dos testes.

74.12 Alternativas Descartadas e Razões

SLA único de 99,9% para todos os serviços. Descartado por incompatibilidade com o modelo de custo-benefício da parceria na fase inicial. Um SLA único de 99,9% exigiria redundância total em todos os componentes, incluindo serviços de analytics e dashboards que toleram degradação. Adicionalmente, nivelamento único cria rigidez na gestão de incidentes: qualquer falha em qualquer serviço seria S1, o que geraria alert fatigue e dificultaria a priorização.

Conformidade WCAG nível A apenas. Descartado por insuficiência para o contexto de serviço público. O eMAG define nível AA como referência, e a legislação de acessibilidade digital brasileira (Decreto nº 5.296/2004 e portarias subsequentes) orienta para esse padrão. Uma plataforma de serviços públicos que não atinge nível AA não cumpre o princípio de universalidade de acesso.

Logs sem redaction de PII. Descartado por incompatibilidade com a LGPD. Logs que retêm dados pessoais identificáveis (CPF, nome completo, endereço) criam um ponto de exposição adicional em caso de breach do sistema de logs — que tipicamente tem controles de acesso menos rigorosos que o banco de dados principal. A técnica de redaction antes do armazenamento elimina esse risco sem perda de rastreabilidade técnica.

RNFs verificados apenas em auditorias periódicas. Descartado por ineficácia. RNFs verificados apenas por auditorias semestrais criam janelas longas de desvio sem detecção. A integração de verificações automáticas no pipeline de CI/CD e o monitoramento contínuo em produção garantem que desvios são detectados no momento em que ocorrem — com custo de correção muito inferior ao de uma regressão descoberta meses após sua introdução.

74.13 Riscos e Mitigações

74.14 Benefícios

O catálogo de requisitos não funcionais produz benefícios concretos para os três atores principais da parceria.

Para o cidadão, os requisitos de disponibilidade (RNF-01), desempenho (RNF-02) e acessibilidade (RNF-05) garantem que os serviços digitais sejam funcionalmente acessíveis independentemente do horário, do dispositivo ou da condição de conectividade. Uma plataforma que atende esses requisitos reduz a necessidade de atendimento presencial — que é o objetivo central da parceria.

Para a PRODEMGE, os requisitos de observabilidade (RNF-08), conformidade (RNF-04) e privacidade (RNF-10) garantem que a operação da plataforma seja auditável, defensável perante órgãos de controle e conforme com a legislação aplicável. A rastreabilidade completa das ações e a proteção de dados dos cidadãos são ativos institucionais que este catálogo compromete a preservar.

Para a parceria, os requisitos de manutenibilidade (RNF-06) e portabilidade (RNF-07) garantem que a plataforma pode evoluir sem acumulação de dívida técnica incontrolável e sem criação de dependência tecnológica de fornecedor único — condições que sustentam a viabilidade técnica e comercial da parceria ao longo dos cinco anos iniciais de vigência.

74.15 Impactos Arquiteturais

O catálogo de requisitos não funcionais impõe restrições arquiteturais concretas que moldam decisões em múltiplas camadas da plataforma.

A meta de disponibilidade de 99,5% para serviços críticos (RNF-01.1) torna inaceitável qualquer componente com ponto único de falha no caminho crítico — o que implica múltiplas réplicas de microsserviços, cluster de banco de dados, cluster Redis, cluster RabbitMQ e balanceador de carga redundante.

O requisito de latência P95 ≤ 500ms para autenticação (RNF-02.1) torna inaceitável a verificação de permissões com chamada síncrona ao banco de dados no caminho crítico — o que implica cache de tokens e permissões no Redis com invalidação ativa, e verificação de autorização local ao serviço sempre que possível.

O requisito de isolamento multi-tenant (RNF-01.7 e RNF-10.4) torna inaceitável qualquer query ao banco de dados sem filtro por tenant no predicado WHERE — o que implica que o discriminador de tenant seja verificado pelo middleware de contexto antes de qualquer operação de dados, não pela lógica de negócio individual de cada serviço.

O requisito de privacidade por design (RNF-10.1) torna inaceitável a adição de novos campos de coleta de dados pessoais sem avaliação prévia documentada — o que implica um processo formal de aprovação no fluxo de desenvolvimento, vinculado à revisão de pull request e ao critério de prontidão do pipeline.

74.16 Integrações com Outros Componentes

Cada domínio de RNF é sustentado por componentes específicos da plataforma:

RNF-01 (Disponibilidade): Kubernetes (Capítulo 38), continuidade de negócio (Capítulo 47), SLA (Capítulo 53).

RNF-02 (Desempenho): cache distribuído (Capítulo 35), infraestrutura em nuvem (Capítulo 37), Kubernetes/HPA (Capítulo 38), frontend React (Capítulo 32), mobile React Native (Capítulo 33).

RNF-03 (Segurança): arquitetura de segurança (Capítulo 42), IAM (Capítulo 43), criptografia (Capítulo 46), DevSecOps (Capítulo 40).

RNF-04 (Conformidade): LGPD (Capítulo 44), auditoria (Capítulo 45), arquitetura de segurança (Capítulo 42).

RNF-05 (Usabilidade/Acessibilidade): portal web (Capítulo 25), aplicativo mobile (Capítulo 26), frontend React (Capítulo 32), mobile React Native (Capítulo 33).

RNF-06 (Manutenibilidade): DevSecOps (Capítulo 40), gestão de configuração (Capítulo 58), gestão de mudanças (Capítulo 59), evolução da plataforma (Capítulo 55).

RNF-07 (Portabilidade): infraestrutura em nuvem (Capítulo 37), Kubernetes (Capítulo 38), APIs e integrações (Capítulo 14).

RNF-08 (Observabilidade): observabilidade e monitoramento (Capítulo 41), auditoria (Capítulo 45), operação e gestão de serviços (Capítulo 51).

RNF-09 (Capacidade): infraestrutura em nuvem (Capítulo 37), Kubernetes (Capítulo 38), banco de dados (Capítulo 34), cache distribuído (Capítulo 35), SLA (Capítulo 53).

RNF-10 (Privacidade): LGPD (Capítulo 44), arquitetura de segurança e identidade (Capítulo 17), gestão multi-tenant (Capítulo 30).

74.17 Relacionamento com Outros Capítulos

Este capítulo é o repositório centralizado dos atributos de qualidade que são implementados, detalhados e evidenciados nos capítulos técnicos do Documento Mestre. A relação é de referência bidirecional: os capítulos técnicos implementam os RNFs aqui definidos; este capítulo consolida e torna rastreável o que está distribuído pelos capítulos técnicos.

O Capítulo 53 (SLA) formaliza contratualmente os critérios de disponibilidade (RNF-01) e desempenho (RNF-02) definidos aqui, com os mecanismos de apuração, as exclusões documentadas e os planos de ação em caso de desvio. Os valores numéricos dos RNFs de disponibilidade e latência neste capítulo são os mesmos do Capítulo 53 — este catálogo é a especificação; o Capítulo 53 é o instrumento de formalização contratual.

O Capítulo 62 (Indicadores e Métricas de Desempenho) apresenta os indicadores de acompanhamento operacional que monitoram o cumprimento dos RNFs em produção. Os KPIs do Capítulo 62 são derivados dos critérios de aceitação deste catálogo.

O Capítulo 67 (Matriz de Aderência e Rastreabilidade) referencia este capítulo como evidência de atendimento aos requisitos dos Blocos 6 do Anexo III (Infraestrutura, Segurança e Governança) e às capacidades técnicas do Anexo IV relacionadas à maturidade operacional da plataforma.

74.18 Referências Internas

• Capítulo 11 — Arquitetura da Plataforma: princípios arquiteturais que fundamentam os RNFs de modularidade e escalabilidade
• Capítulo 12 — Arquitetura de Microsserviços: stateless design e isolamento de falhas (RNF-01.7, RNF-02.8)
• Capítulo 17 — Arquitetura de Segurança e Identidade: Zero Trust como fundamento dos RNFs de segurança
• Capítulo 25 — Portal Web: implementação dos RNFs de acessibilidade e usabilidade no canal web
• Capítulo 26 — Aplicativo Mobile: implementação dos RNFs de acessibilidade no canal mobile
• Capítulo 30 — Gestão Multi-Tenant: implementação do isolamento de tenant (RNF-01.7, RNF-10.4)
• Capítulo 34 — Banco de Dados e Persistência: replicação e backup (RNF-01.4, RNF-01.5)
• Capítulo 35 — Cache Distribuído: cluster Redis para disponibilidade e desempenho (RNF-01, RNF-02)
• Capítulo 37 — Infraestrutura e Computação em Nuvem: portabilidade (RNF-07.1)
• Capítulo 38 — Kubernetes e Orquestração: autoscaling e alta disponibilidade (RNF-01, RNF-02.9)
• Capítulo 40 — DevSecOps: testes automatizados e segurança no pipeline (RNF-03, RNF-06)
• Capítulo 41 — Observabilidade e Monitoramento: instrumentação e detecção (RNF-08)
• Capítulo 42 — Arquitetura de Segurança: Zero Trust, defesa em profundidade (RNF-03)
• Capítulo 43 — IAM: autenticação e autorização (RNF-03.1, RNF-03.4)
• Capítulo 44 — LGPD: conformidade e Privacy by Design (RNF-04.1, RNF-10)
• Capítulo 45 — Auditoria e Rastreabilidade: trilha imutável (RNF-04.4, RNF-08.5)
• Capítulo 46 — Criptografia: AES-256-GCM e TLS 1.3 (RNF-03.2, RNF-03.3)
• Capítulo 47 — Continuidade de Negócio: RTO e RPO (RNF-01.4, RNF-01.5)
• Capítulo 53 — SLA: formalização contratual dos critérios de RNF-01 e RNF-02
• Capítulo 62 — Indicadores e Métricas: KPIs derivados dos critérios deste catálogo

74.19 Rastreabilidade PRODEMGE

Edital CP 001/2026:

• Item 3.1 — Classificação das propostas: a plataforma deve demonstrar maturidade técnica operacional — os RNFs são a especificação mensurável dessa maturidade.

Plano de Negócio (Anexo I):

• Item 3.3.2 — Infraestrutura e Escalabilidade: disponibilidade, escalabilidade e monitoramento contínuo são atendidos pelos domínios RNF-01, RNF-02 e RNF-08.
• Item 3.3.5 — Segurança da Informação e Conformidade: autenticação, controle de acesso, logs, LGPD e governança de segurança são atendidos pelos domínios RNF-03 e RNF-04.
• Item 3.3.9 — Interfaces responsivas, acessibilidade: atendidos pelo domínio RNF-05.

Funcionalidades (Anexo III):

• Bloco 6 (Infraestrutura, Segurança e Governança): os itens 6.1 (cloud), 6.2 (escalabilidade), 6.3 (alta disponibilidade), 6.4 (segurança), 6.5 (LGPD), 6.6 (auditoria), 6.7 (monitoramento) têm cobertura direta nos domínios RNF-01, RNF-02, RNF-03, RNF-04 e RNF-08 deste catálogo.

Capacidades (Anexo IV):

• Capacidades técnicas de disponibilidade, performance, segurança, conformidade com LGPD e observabilidade: atendidas pelos dez domínios de RNF especificados neste capítulo.

Sustentabilidade (Anexo V):

• Item 2.2 — Acessibilidade digital: atendido pelo domínio RNF-05.
• Item 2.3 — Proteção do usuário: atendido pelos domínios RNF-03 e RNF-10.
• Item 3.3 — Segurança da informação: atendido pelo domínio RNF-03.

Esclarecimentos pertinentes:

• Montreal (02/07/2026), Bloco 1: confirmação de que a arquitetura deve suportar cloud pública, cloud híbrida PRODEMGE e on-premise — atendido pelo domínio RNF-07 (portabilidade de infraestrutura).
• Madrona Advogados (08/07/2026), item relacionado a LGPD e processamento de IA: os mecanismos de proteção de dados em transferências internacionais para provedores de IA são especificados no RNF-10.5.

74.20 Resumo

Este capítulo especificou o catálogo completo de requisitos não funcionais da Plataforma de Relacionamento Digital com o Cidadão, organizado em dez domínios: disponibilidade e resiliência (RNF-01), desempenho e escalabilidade (RNF-02), segurança da informação (RNF-03), conformidade legal (RNF-04), usabilidade e acessibilidade (RNF-05), manutenibilidade (RNF-06), portabilidade e interoperabilidade (RNF-07), observabilidade e auditabilidade (RNF-08), capacidade e dimensionamento (RNF-09) e privacidade e proteção de dados (RNF-10).

Cada requisito é especificado com critério de aceitação mensurável, mecanismo de implementação e referência ao capítulo técnico onde a implementação está documentada. O catálogo não é aspiracional — é a formalização do que foi especificado e implementado nos capítulos técnicos anteriores, consolidado em visão unificada para facilitar verificação pela PRODEMGE.

Os valores numéricos dos requisitos de disponibilidade e desempenho são consistentes com os SLAs formalizados no Capítulo 53. Os requisitos de conformidade são consistentes com a implementação da LGPD no Capítulo 44. Os requisitos de acessibilidade são consistentes com as implementações dos Capítulos 25, 26, 32 e 33. A coerência interna entre este catálogo e os capítulos técnicos é a característica mais importante desta seção: uma especificação de RNF que não encontra implementação documentada não é uma especificação — é uma declaração de intenção.

74.21 Decisões Arquiteturais

74.22 Próximo Capítulo

O Capítulo 75 apresenta as Referências Técnicas e Normativas — o repertório de padrões, normas, especificações e documentos que fundamentam as decisões arquiteturais e os critérios de qualidade estabelecidos ao longo do Documento Mestre.

74.23 Controle de Versão