Pare de focar só em features

Por que Requisitos Não-Funcionais (RNFs) são os verdadeiros drivers da sua arquitetura de software

​Quantas vezes você viu um projeto ser lançado com sucesso, apenas para falhar catastroficamente no primeiro pico de acesso? Ou um sistema que, após seis meses, se tornou tão lento e complexo que cada nova feature levava semanas para ser implementada?



​Esses cenários são dolorosamente comuns e quase sempre têm a mesma causa raiz: um foco desproporcional nos requisitos funcionais (o que o sistema faz) e uma negligência fatal dos requisitos não-funcionais (o como ele faz).

​Como arquitetos e líderes de tecnologia, é nosso dever mudar essa narrativa. Os requisitos funcionais dizem qual problema estamos resolvendo; os requisitos não-funcionais (RNFs) ditam a forma e a sustentabilidade da solução. Eles são os verdadeiros pilares da arquitetura de software.

​O Que vs. Como: A Diferença que Define o Jogo

​É simples entender a diferença:

  • ​Requisitos Funcionais (RFs): Descrevem o comportamento do sistema.
    • ​"O usuário deve poder fazer login com e-mail e senha."
    • ​"O sistema deve gerar um relatório de vendas mensal."
    • ​"O usuário deve adicionar um produto ao carrinho."
  • ​Requisitos Não-Funcionais (RNFs) / Atributos de Qualidade: Descrevem as qualidades e restrições do sistema.
    • ​Desempenho: "O login deve ser concluído em menos de 500ms."
    • ​Escalabilidade: "O sistema deve suportar 10.000 usuários simultâneos durante a Black Friday sem degradação do desempenho."
    • ​Disponibilidade: "O serviço de login deve ter 99,99% de uptime (o famoso 'quatro noves')."
    • ​Segurança: "As senhas dos usuários devem ser armazenadas usando um algoritmo de hash forte e salt."
    • ​Manutenibilidade: "Uma nova regra de relatório deve poder ser implementada por um novo desenvolvedor em menos de 3 dias."

​O problema é que equipes tendem a tratar RNFs como "desejáveis" ou "algo para otimizar depois". Isso é um erro fundamental. A escolha entre um Monolito e Microsserviços, ou entre um banco SQL e NoSQL, raramente é ditada por um requisito funcional; ela é quase inteiramente ditada pelos RNFs.

​Tornando o Abstrato em Concreto: 3 Passos para usar RNFs como Drivers

​Para que os RNFs deixem de ser apenas uma lista de desejos e se tornem drivers arquiteturais, precisamos de um processo.

​1. Quantifique, Não Apenas Qualifique

​O maior erro ao lidar com RNFs é mantê-los vagos. "O sistema deve ser rápido" não é um requisito; é um desejo.

  • ​Ruim: "O sistema precisa ser escalável."
  • ​Bom: "O sistema deve escalar horizontalmente para suportar um aumento de 50% no tráfego de usuários ano a ano, mantendo o tempo de resposta p95 abaixo de 300ms."
  • ​Ruim: "A API precisa ser segura."
  • ​Bom: "Todas as APIs expostas devem implementar autenticação via OAuth 2.0 (Client Credentials) e o rate limiting deve bloquear IPs com mais de 100 requisições/minuto."

​Ao quantificar, você cria um "cenário de atributo de qualidade" (Quality Attribute Scenario) que pode ser testado e validado.

​2. Use RNFs para Guiar os Trade-Offs

​Toda arquitetura é uma série de trade-offs. Não existe "melhor" arquitetura, existe a arquitetura "mais adequada" para um conjunto específico de RNFs.

  • ​Cenário A: O RNF mais crítico é o time-to-market (velocidade de entrega) e a equipe é pequena.
    • ​Driver: Manutenibilidade e simplicidade de deploy.
    • ​Escolha Provável: Um Monolito bem estruturado (talvez um Monolito Modular).
  • ​Cenário B: Os RNFs mais críticos são escalabilidade extrema e tolerância a falhas para partes específicas do sistema (ex: checkout de um e-commerce).
    • ​Driver: Escalabilidade independente e resiliência.
    • ​Escolha Provável: Arquitetura de Microsserviços, onde o serviço de checkout pode escalar independentemente dos outros.
  • ​Cenário C: O RNF mais crítico é o desacoplamento e a resiliência entre diferentes domínios de negócio.

​Os RNFs forçam a discussão sobre o que estamos otimizando para.

​3. Valide os Riscos Cedo (PoCs e Spikes Arquiteturais)

​Não espere seis meses de desenvolvimento para descobrir que sua escolha de banco de dados não aguenta a carga de escrita definida no RNF de desempenho.

​Use Spikes (investigações técnicas curtas) ou Provas de Conceito (PoCs) focadas nos RNFs de maior risco.

  • ​O RNF diz: "Devemos processar 1 milhão de eventos por dia."
  • ​O Risco: A tecnologia de message broker (Kafka, RabbitMQ) escolhida dará conta?
  • ​A Validação (Spike): Crie um pequeno produtor e um consumidor. Gere 1 milhão de eventos sintéticos e meça a latência, o throughput e o consumo de recursos.

​Isso move a descoberta de problemas arquiteturais do final do projeto (quando é caro mudar) para o início (quando é barato ajustar).

​Conclusão

​Os requisitos funcionais são o destino da sua viagem. Os requisitos não-funcionais são o tipo de veículo que você precisa construir, a velocidade que ele deve atingir, o terreno que ele deve aguentar e o combustível que ele pode consumir.

​Ao tratar os RNFs como os drivers primários da sua arquitetura, você para de construir sistemas que apenas "funcionam" e começa a construir sistemas que perduram, escalam e evoluem de forma saudável.