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

Precisamos conversar sobre requisito de software

Se você já trabalhou com desenvolvimento, pelo menos uma vez na vida precisou escrever ou interpretar um documento de requisitos. E se você tem sorte, também já viu um projeto inteiro desmoronar porque alguém escreveu "sistema deve ser rápido" e ninguém definiu o que isso significava na prática. É exatamente aqui que a distinção entre requisitos funcionais e não funcionais deixa de ser teoria de livro didático e vira a diferença entre entregar um produto funcionando e entregar algo que ninguém consegue usar. A pergunta básica é: o que são requisitos funcionais e não funcionais, afinal? Requisito funcional descreve o que o sistema deve fazer. É uma ação, um comportamento, uma funcionalidade que o software precisa executar. "O sistema deve permitir que o usuário cadastre um novo pedido." Pronto. Isso é funcional. Requisito não funcional descreve como o sistema deve fazer aquilo. Descreve qualidade, restrição, característica transverse. "O cadastro de pedido deve ser completado em até 2 segundos, considerando uma carga de até 500 usuários simultâneos." Aí é não funcional.

O que são requisitos funcionais e não funcionais na prática

Na prática, a divisão é útil mas sempre imperfeita. Um requisito pode começar como funcional e carregar implicações não funcionais que você só percebe quando vai desenvolver. Eu lembro de um projeto em 2019 onde o cliente pediu um módulo de exportação de relatórios em PDF. Parecia simples. Era funcional, certo? O sistema gera um arquivo PDF com os dados da tela. Só que quando fomos implementar, a equipe de QA descobriu que o servidor de produção tinha 512 MB de RAM e, ao processar relatórios com mais de 10 mil registros, o processo de geração de PDF consumia toda a memória e derrubava o serviço. O requisito funcional não dizia nada sobre volume de dados. O requisito não funcional de uso de memória estava ausente. A solução foi adicionar um parâmetro de paginação no código e documentar uma restrição clara: o módulo só suportaria exportações de até 5 mil registros por solicitação, com fallback para geração em lote. Sem esse documento, a discussão teria sido meses de debugging e culpa mútua. O que muitas pessoas não entendem é que requisitos não funcionais não são opcionais. Eles são restrições que, se ignoradas, viram dívida técnica disfarçada. A maioria dos erros que eu vejo em revisões de projeto acontece porque alguém anotou trinta requisitos funcionais e dois não funcionais, sendo que um deles era "interface amigável" — que é praticamente inútil como especificação. Não dá para testar "interface amigável". Dá para testar "o usuário deve completar o fluxo de checkout em três cliques ou menos, com taxa de erro inferior a 2%". Isso sim é especificável.

Requisitos não funcionais mais críticos em projetos reais caem em categorias como desempenho, segurança, escalabilidade, confiabilidade, portabilidade e usabilidade. Cada uma dessas categorias exige métricas. Desempenho sem métrica é opinião. Segurança sem métrica é esperança. Quando eu escrevo um requisito de desempenho, eu sempre incluo três coisas: a condição de carga (quantos usuários, qual tipo de operação), o tempo de resposta aceitável (latência, throughput) e o ambiente de teste (produção, staging, hardware específico). Sem essas três informações, o requisito é apenas uma promessa vaga. Um erro comum que eu vejo repetidamente é tratar requisito não funcional como algo que pode ser definido depois. Você não define segurança no meio do desenvolvimento. Você não adiciona escalabilidade na fase de testes. Requisitos não funcionais precisam ser identificados na mesma sessão em que você coleta os funcionais, porque eles influenciam diretamente a arquitetura. Se você sabe que o sistema precisa suportar 10 mil conexões concorrentes, isso muda a escolha do banco de dados, da fila de mensagens, do balanceador de carga. Se você descobre isso três meses depois, a reestruturação custa entre quatro e oito semanas de desenvolvimento, dependendo da complexidade.

Também vale mencionar que requisitos não funcionais frequentemente se contradizem. Segurança forte reduz desempenho. Alta disponibilidade aumenta custos de infraestrutura. Flexibilidade arquitetural pode comprometer a simplicidade operacional. O trabalho do analista não é eliminar essas tensões, mas documentá-las explicitamente e deixar claro quais trade-offs foram aceitos. Um documento de requisitos que esconde conflitos é um documento enganoso. Sobre requisitos funcionais, o problema mais frequente é ambiguidade linguística. "O sistema deve permitir busca avançada" não diz nada. O que é busca avançada? Filtros por data? Por categoria? Por campo personalizado? Regras de precedência? Eu costumo escrever requisitos funcionais no formato: agente, ação, objeto, condição. "O usuário administrador deve poder criar, editar e excluir categorias de produtos, desde que não existam produtos vinculados a essa categoria no momento da exclusão." Esse formato elimina metade dos mal-entendidos que aparecem depois.

Há uma armadilha que poucos mencionam: requisitos não funcionais também podem ser mal escritos como se fossem funcionais, usando verbos de ação quando deveriam usar verbos de estado. "O sistema deve ser seguro" é tão inútil quanto "o sistema deve funcionar bem". A versão útil seria: "Todos os dados sensíveis devem ser criptografados em repouso usando AES-256, e as credenciais de acesso devem ser armazenadas em segredos gerenciados, com rotação automática a cada 90 dias." Isso sim é verificável. Isso sim gera um teste de aceitação. Se você está começando agora a lidar com esses conceitos, o conselho mais prático que eu posso dar é: escreva primeiro os não funcionais antes de listar todos os funcionais. Isso soa contraintuitivo, mas funciona. Quando você define as restrições de desempenho, segurança e disponibilidade no início, os requisitos funcionais que você listar a seguir já nascem cientes desses limites. O resultado é um documento mais coeso e muito menos sujeito a retrabalho.

Não existe ferramenta mágica que resolva a escrita de requisitos. Ferramentas ajudam na organização, na rastreabilidade, na versionação. Mas a qualidade do requisito depende de clareza, especificação mensurável e consistência entre o que foi pedido e o que foi entregue. Se você terminar um sprint e o produto entregue não puder ser validado contra os requisitos documentados, o problema não é da implementação. É da especificação. Documentos de requisitos que eu considero bons são aqueles em que qualquer pessoa — desenvolvedor, tester, product owner — consegue ler um requisito e dizer, sem ambiguidade, se ele foi atendido ou não. Se precisar de uma reunião de duas horas para esclarecer o que um requisito significa, o requisito está mal escrito. Não blame o leitor. Corrija o documento.

Eu já vi times inteiros gastarem semanas refazendo um módulo inteiro porque o requisito funcional original permitia duas interpretações válidas e diferentes. Uma delas foi implementada. A outra era a que o cliente queria. O custo dessa ambiguidade foi de aproximadamente seis semanas de desenvolvimento descartado. Nada disso aconteceria se o requisito tivesse sido escrito com critérios de aceite explícitos desde o início. O que são requisitos funcionais e não funcionais, no fim das contas, é uma forma de comunicação estruturada entre quem pede e quem constrói. A estrutura não protege contra más decisões. Mas protege contra mal-entendidos. E em projeto de software, mal-entendido é o item mais caro que existe.