O Que São Requisitos Funcionais E Não Funcionais

Documentar requisitos é uma das coisas mais chatas e importantes do desenvolvimento

Você provavelmente já viu um projeto andar por meses com uma ideia vaga na cabeça da pessoa que contratou e, no final, entregar algo que não era o que todos estavam esperando. A culpa quase sempre cai na comunicação. O problema é que a maioria das pessoas não sabe exatamente como transformar o que está na mente de alguém em texto que desenvolvedores possam construir. Requisito funcional é o que o sistema precisa fazer. É uma ação, um comportamento, uma obrigação direta. "O usuário deve conseguir logar com CPF e senha." "O sistema deve gerar um relatório em PDF." "O botão de finalizar compra deve validar se o carrinho tem itens." São afirmações verificáveis. Se eu abrir um formulário e não tiver o campo de CPF, o requisito não está atendido. Pronto, ponto. Requisito não funcional é como o sistema precisa fazer aquilo. É qualidade, restrição, característica transversal. "O sistema deve responder em menos de 2 segundos para 95% das requisições." "O aplicativo deve suportar 10 mil usuários concorrentes sem degrade significativa." "A interface deve seguir o padrão WCAG 2.1 AA." Isso não descreve uma ação direta. Descreve um patamar que o comportamento funcional precisa atingir.

Na prática eu costumo explicar assim: funcional é o que o sistema faz. Não funcional é quão bem ele faz.

Como escrever isso sem perder tempo

O método que eu uso e recomendo é bem simples, apesar de muita gente complicar. Você lista os funcionais primeiro. Depois pega cada um e pergunta: sob que condições isso precisa funcionar? Aí entram os não funcionais. Eu sigo essa ordem porque funciona. Se você começar pelos não funcionais, fica difícil saber para qual funcionalidade aquela exigência se aplica. Para os funcionais, use o formato "O sistema deve [ação] quando [condição] para que [resultado]". Assim você evita ambiguidade. "O sistema deve calcular o frete quando o endereço de entrega for informado para que o cliente veja o valor antes de finalizar." Isso é claro. Diferente de "o sistema precisa ter cálculo de frete", que é vago demais e gera discussões intermináveis depois. Para os não funcionais, eu me baseio no modelo FURPS. Funcionalidade, Usabilidade, Runtime performance, Suporte, Parâmetros técnicos. Não é obrigatório usar todas as categorias, mas é um roteiro que evita que você esqueça algo importante. Performance, segurança, confiabilidade, escalabilidade, manutenção. Tudo isso entra nos não funcionais.

Um problema real que eu tive

Em um projeto de plataforma de agendamento, eu tinha definido um requisito funcional bem óbvio: "O sistema deve permitir agendar consultas de 30 minutos." O não funcional também parecia tranquilo: "O sistema deve atender até 500 agendamentos simultâneos." Achei que estava tudo resolvido. O frontend foi feito em React, o backend em Node.js com PostgreSQL, e pronto. Chegou o dia do teste de carga e a coisa quebrou de um jeito que eu não tinha previsto. O problema não era o número de conexões. Era o locks na tabela de agenda. Quando dois usuários tentavam agendar o mesmo horário ao mesmo tempo, o PostgreSQL travava a linha inteira e esperava. A latência disparava. O tempo de resposta passava de 2 segundos para 45 segundos em picos. Os 500 usuários simultâneos eram um problema teórico. O problema real era a estratégia de isolation level e a falta de um mecanismo de fila de espera para horários disputados. A solução que eu apliquei foi trocar a abordagem de bloqueio direto por uma tabela de slots com verificação otimista usando. Cada slot de horário vira um registro com um campo de versão. Na hora de confirmar o agendamento, o sistema compara a versão. Se mudou entre a leitura e a gravação, ele rejeita e pede para o usuário escolher outro horário. Isso elimina o lock de longa duração e resolve o gargalo. O tempo de resposta voltou para a casa dos 200 milissegundos. Ajustei também o índice da tabela de slots para incluir horário, profissional e status, o que reduziu o custo das queries de verificação em cerca de 80 por cento.

Esse tipo de detalhe não aparece na maioria dos guias. É o tipo de coisa que você só descobre quando o sistema está em pé e começando a receber tráfego de verdade.

O que iniciantes costumam errar

O erro mais comum é tratar requisito não funcional como meta motivacional. "O sistema deve ser rápido." Isso não é requisito. Não é testável. O que é rápido? 5 segundos? 500 milissegundos? 50 milissegundos? Você precisa poner número. Sem número não há como validar e não há como reclamar quando o entregável não atende. O segundo erro é confundir tecnologia com requisito. "O sistema deve ser feito em Java." Isso é uma decisão técnica, não um requisito funcional ou não funcional. A menos que haja uma restrição de compliance, licenciamento ou integração que justifique explicitamente a tecnologia, essa afirmação não pertence ao documento de requisitos. Ela pertence ao documento de arquitetura. Misturar os dois gera confusão e acaba gerando atrito entre quem solicita e quem desenvolve. Também é muito comum esquecimento total de requisitos de segurança e privacidade. Em um contexto brasileiro, a LGPD entra aqui naturalmente. "O sistema deve armazenar senhas com hash bcrypt no mínimo." "Dados sensíveis de saúde devem ser criptografados em repouso e em trânsito." Se você não colocar isso no papel, alguém vai implementar da forma mais barata possível e você vai descobrir o problema quando um incidente acontecer.

Como lidar com limitações reais

Requisitos não funcionais costumam depender de infraestrutura e orçamento. Performance é fácil de demandar no papel. É difícil de garantir se o servidor é uma máquina compartilhada em ambiente de homologação que não representa nada perto do production. Se você exigir 200 milissegundos de resposta e não tiver um ambiente de teste equivalente, sua validação será ilusória. Outra limitação prática: requisitos não funcionais muitas vezes se contradizem. Seguridad e usabilidade frequentemente puxam para lados opostos. Exigir autenticação multifator para todo acesso aumenta a segurança, mas reduz a usabilidade. A solução não é ignorar o problema. É priorizar. Você escolhe quais controles se aplicam a quais fluxos. Acesso de administrador pode exigir MFA. Acesso público de consulta de informações básicas não precisa. Se o projeto for pequeno ou for um MVP, eu recomendo focar nos três não funcionais mais críticos e deixar o resto para iterações futuras. Tentar especificar tudo com profundidade desde o início gera um documento enorme que ninguém lê e que envelhece mal. Performance, segurança e escalabilidade são os que mais causam dor no fim do caminho. Comece por eles.

Um exemplo prático de documento bem feito

Vamos imaginar um sistema de e-commerce simples. RF-001: O sistema deve permitir que o cliente adicione produtos ao carrinho quando clicar no botão "Comprar". RF-002: O sistema deve calcular o valor total do carrinho incluindo preço dos produtos, frete e impostos.

RF-003: O sistema deve permitir que o cliente finalize a compra usando cartão de crédito, PIX ou boleto bancário. RNF-001: O sistema deve processar o pagamento via cartão em até 3 segundos para 95 das requisições. RNF-002: O sistema deve manter o carrinho sincronizado entre dispositivos quando o usuário estiver logado.

RNF-003: Os dados de cartão não devem ser armazenados localmente. O sistema deve usar tokenização via gateway de pagamento. RNF-004: A API deve suportar pelo menos 1.000 requisições por minuto durante promoções sem gerar erro 5xx. Isso é um conjunto básico. Daria para alongar bastante, especialmente em RNF-003 e RNF-004, mas para um exemplo didático funciona bem.

Quando esse formato não funciona

Se o time trabalha com Agile puro e os requisitos estão sempre no backlog sendo refinados a cada sprint, um documento formal em PDF pode ser overkill. Nesse cenário, eu prefiro manter os requisitos como items do Jira ou Azure DevOps com critérios de aceitação bem escritos. A estrutura ainda vale. Cada item de funcionalidade precisa ter seus não funcionais vinculados ou referenciados. O problema é que, nessa abordagem, a visibilidade geral do que está sendo exigido se perde com mais facilidade. Recomendo pelo menos um documento mestre ou uma página no Confluence que liste os não funcionais críticos de forma centralizada, mesmo que os detalhes técnicos fiquem nos tickets. A outra situação em que o formato tradicional falha é em projetos onde o escopo é extremamente instável. Se você está construindo algo que ainda não sabe direito o que é, gastar duas semanas documentando requisitos com numbering pode ser tempo mal gasto. Nesse caso, prototipagem rápida e entrevistas com usuários reais geram mais valor do que um documento bem estruturado que será esquecido em um mês.

Dica direta que faz diferença

Antes de fechar o documento de requisitos, faça uma revisão cruzada. Pegue cada requisito não funcional e pergunte: para qual requisito funcional isso se aplica? Se você não conseguir responder, esse não funcional pode estar solto demais. Precisa ser vinculado a um fluxo específico. Do mesmo jeito, pegue cada requisito funcional e pergunte: quais não funcionais esse fluxo exige? Se a resposta for "nenhum", você provavelmente está deixando algo passar. Todo funcional tem implicação de segurança, performance, usabilidade ou conformidade em algum nível. Não ignore isso.