Requisitos Não Funcionais

Objetivo

Definir os requisitos não funcionais estritamente alinhados ao recorte da v1.0 do SSDOi.

Na v1.0, os requisitos de qualidade devem ser lidos à luz de cinco premissas:

• a solução é um núcleo de avaliação automática;
• não há interface gráfica de operação;
• o consumo principal ocorre por serviço ou integração;
• os parâmetros matemáticos e operacionais são fixos no código da versão;
• o resultado precisa ser rastreável e reproduzível.

Convenções adotadas

• Obrigatório: requisito necessário para aceite da v1.0.
• Importante: requisito relevante para operação confiável da v1.0, mas não definidor isolado da entrega.

RNF-V1-001 Arquitetura orientada a serviço

• Prioridade: Obrigatório
• Diretriz: a v1.0 deve ser implementada como componente de backend consumível por serviço, API ou mecanismo equivalente de integração.
• Implicações:
  • a solução não deve depender de interface gráfica para executar o fluxo principal;
  • a entrada e a saída da avaliação devem ser estruturadas por contrato;
  • o motor de cálculo deve poder ser acionado por outros componentes do ecossistema.

RNF-V1-002 Ausência de dependência de interface

• Prioridade: Obrigatório
• Diretriz: nenhuma funcionalidade essencial da v1.0 pode depender de telas de cadastro, consulta, parametrização ou operação manual.
• Implicações:
  • o processamento completo deve ser executável por serviço;
  • erros e resultados devem ser retornados em formato estruturado;
  • a ausência de interface gráfica não pode impedir homologação da versão.

RNF-V1-003 Contratos estáveis de entrada e saída

• Prioridade: Obrigatório
• Diretriz: a v1.0 deve expor contratos de entrada e saída estáveis para interoperabilidade.
• Implicações:
  • a solicitação de avaliação deve seguir estrutura validável;
  • o resultado técnico deve ser serializável em formato padronizado;
  • códigos de erro e rejeição devem seguir convenção consistente;
  • mudanças incompatíveis de contrato devem ser evitadas dentro da mesma versão.

RNF-V1-004 Reprodutibilidade do cálculo

• Prioridade: Obrigatório
• Diretriz: a mesma entrada, processada na mesma versão da aplicação e com a mesma base de dados de referência, deve produzir o mesmo resultado.
• Implicações:
  • os parâmetros usados na execução devem ser identificáveis;
  • a versão do código e das bases de referência deve ser rastreável;
  • o cálculo não deve depender de configuração manual variável em tempo de execução.

RNF-V1-005 Parametrização fixa em código

• Prioridade: Obrigatório
• Diretriz: os parâmetros matemáticos e operacionais da v1.0 devem estar definidos diretamente no código da versão.
• Implicações:
  • não deve haver painel funcional de parametrização;
  • não deve haver edição operacional de variáveis, fatores e regras por usuário;
  • toda alteração de parâmetro relevante deve ocorrer por nova versão de software.

RNF-V1-006 Desempenho operacional compatível com análise automática

• Prioridade: Importante
• Diretriz: a v1.0 deve responder em tempo compatível com uso automatizado de análise técnica.
• Implicações:
  • solicitações unitárias não devem depender de processamento manual intermediário;
  • a solução deve suportar processamento síncrono quando o volume e a complexidade permitirem;
  • a arquitetura pode prever processamento assíncrono para cargas mais pesadas ou integrações lentas.

RNF-V1-007 Tolerância a falhas de integração

• Prioridade: Obrigatório
• Diretriz: falhas de comunicação com CNARH e SNISB devem ser tratadas de forma explícita e auditável.
• Implicações:
  • erros de integração devem ser registrados;
  • a resposta da avaliação deve indicar quando a falha externa impedir a conclusão do processamento;
  • timeouts, indisponibilidade e retorno inválido devem ser diferenciáveis para diagnóstico.

RNF-V1-008 Rastreabilidade mínima da execução

• Prioridade: Obrigatório
• Diretriz: cada avaliação executada deve possuir trilha mínima de rastreabilidade técnica.
• Implicações:
  • a trilha deve registrar identificador da execução;
  • deve registrar horário de início e fim;
  • deve registrar situação final da execução;
  • deve registrar as principais bases e parâmetros utilizados.

RNF-V1-009 Observabilidade técnica

• Prioridade: Importante
• Diretriz: a v1 deve produzir informações suficientes para monitoramento técnico e diagnóstico operacional.
• Implicações:
  • logs devem permitir correlacionar requisição, execução e resultado;
  • erros devem conter contexto suficiente para suporte técnico;
  • eventos críticos de integração e cálculo devem ser observáveis.

RNF-V1-010 Segurança de acesso ao serviço

• Prioridade: Obrigatório
• Diretriz: o acesso aos serviços da v1.0 deve ser protegido por mecanismo de autenticação compatível com o ambiente do Serpro e da ANA.
• Implicações:
  • somente consumidores autorizados devem invocar o motor;
  • chamadas devem ser associáveis ao sistema ou identidade cliente que as realizou;
  • o requisito não implica, nesta versão, gestão completa de perfis de usuário final por interface.

RNF-V1-011 Integridade dos dados de referência

• Prioridade: Obrigatório
• Diretriz: o processamento da v1.0 deve ocorrer apenas com bases de referência íntegras e identificadas.
• Implicações:
  • a base BHO v6 utilizada deve estar identificada;
  • as zonas subterrâneas e dados de reservatório usados no cálculo devem ser versionáveis ao menos por referência de carga;
  • o sistema deve rejeitar ou sinalizar execução quando as bases mínimas não estiverem disponíveis.

RNF-V1-012 Portabilidade de implantação

• Prioridade: Importante
• Diretriz: a solução deve poder ser implantada em ambiente controlado pelo Serpro, sem dependência estrutural do ambiente de desenvolvimento do legado.
• Implicações:
  • o motor não deve depender de componentes desktop;
  • a implantação deve ser compatível com execução em servidor;
  • dependências externas devem ser explícitas e documentadas.

RNF-V1-013 Compatibilidade com evolução futura

• Prioridade: Importante
• Diretriz: a arquitetura da v1.0 não deve impedir a evolução posterior para interface gráfica, parametrização externa e novos métodos de análise.
• Implicações:
  • o desenho deve separar contrato, cálculo e integração;
  • regras específicas da v1.0 não devem ser codificadas de forma a inviabilizar extração futura para configuração;
  • o modelo deve permitir expansão para efluentes, Theis, Hunt, DRDH e demais etapas do roadmap.

Restrições explícitas da v1.0

As seguintes características não são obrigatórias para a v1.0 e não devem ser usadas como critério de reprovação desta versão:

• interface gráfica para operação;
• painel administrativo de parametrização;
• gestão completa de perfis funcionais de usuário final;
• alta flexibilidade de configuração em tempo de execução;
• escalabilidade já otimizada para o cenário final de cobertura nacional plena.

Pendências a tratar nas próximas versões

• metas quantitativas formais de tempo de resposta;
• metas quantitativas de disponibilidade e recuperação;
• política completa de observabilidade institucional;
• política detalhada de retenção de logs e trilhas;
• critérios finais de hardening e segurança operacional em produção.