Requisitos funcionais e não funcionais: o guia do fundador que paga a conta

Meio-dia de segunda. Um fundador abriu as inscrições de um curso com 900 pessoas na lista de espera. A home carregou; o checkout, não. Ele assistiu a conversão do lançamento evaporar por quarenta minutos.

O estúdio respondeu o que era tecnicamente correto e comercialmente devastador: “isso não estava no escopo”. E não estava. O documento que ele aprovou descrevia muito bem o que o sistema fazia. Não dizia quantas pessoas podiam fazer ao mesmo tempo.

Requisitos funcionais dizem o que o software faz. Requisitos não funcionais dizem como ele se comporta enquanto faz: quão rápido, para quantos usuários simultâneos, com qual disponibilidade, sob quais regras de segurança. A diferença entre requisitos funcionais e não funcionais é a diferença entre um sistema que passa no teste e um sistema que sobrevive ao lançamento.

Todo fundador escreve os funcionais. Quase nenhum escreve os não funcionais. E são os não funcionais que decidem o preço da build, o comportamento no dia do lançamento e o tamanho do seu prejuízo quando algo quebra.

O que são requisitos funcionais e não funcionais

Requisito funcional é uma coisa que o sistema precisa fazer. Tem sujeito, verbo e objeto. “O cliente emite a segunda via do boleto.” Ou faz, ou não faz. É binário, e por isso é fácil de escrever, fácil de testar e fácil de cobrar.

Requisito não funcional é uma qualidade que o sistema precisa ter enquanto faz aquilo. Não é uma função nova; é uma restrição sobre todas as funções. “A segunda via do boleto aparece em menos de 2 segundos, para até 300 pessoas ao mesmo tempo, 99,5% do mês.” Não é binário. É uma faixa, um limite, um número.

A literatura acadêmica chama os não funcionais de “atributos de qualidade”, e existe uma norma internacional que os organiza: a ISO/IEC 25010, que define as características de qualidade de um software (desempenho, segurança, confiabilidade, manutenibilidade e outras). Você não precisa decorar a norma. Precisa saber que ela existe, porque é dela que sai a lista de perguntas que ninguém te fez.

A confusão mais comum é achar que “não funcional” significa “opcional”, ou “coisa técnica que o dev resolve”. É o contrário. O funcional é a parte que o dev resolve sozinho porque você já explicou. O não funcional é a parte que ele vai decidir por você, no silêncio, se você não disser nada.

Três exemplos de requisitos funcionais (a parte fácil)

Peguemos um sistema de agendamento para uma rede de clínicas:

1. “O paciente escolhe um horário disponível na agenda do profissional e confirma o agendamento.” Faz ou não faz.
2. “O sistema envia um lembrete por WhatsApp 24 horas antes da consulta.” Faz ou não faz.
3. “A recepcionista remarca uma consulta e o horário antigo volta a ficar disponível.” Faz ou não faz.

Isso é o que qualquer fundador consegue escrever num café, e é o que quase todo documento de requisitos contém. É bom. É necessário. E é insuficiente, porque nenhuma dessas três frases diz o que acontece quando 40 recepcionistas de 12 unidades usam o sistema às 8h de uma segunda-feira, que é exatamente quando ele precisa funcionar.

Requisitos não funcionais: as sete perguntas que ninguém te faz

Aqui está a lista que substitui a norma. Sete perguntas. Se o seu documento não responde a elas com números, você não tem requisitos não funcionais; tem esperança.

1. Desempenho. Quão rápido?
Não “rápido”. Quantos milissegundos, em qual tela, no pior caso. A busca de pacientes responde em menos de 500ms. A emissão do relatório mensal pode levar 30 segundos, e tudo bem, desde que avise o usuário.

2. Carga. Para quantos ao mesmo tempo?
O número que faltava no lançamento do curso. Quantos usuários simultâneos no pico? E qual é o pico: o dia da folha, a abertura das matrículas, a Black Friday? Sistemas não caem na média. Caem no pico.

3. Disponibilidade. Quanto tempo fora do ar é tolerável?
99% de uptime soa ótimo até você fazer a conta: são mais de 7 horas de queda por mês. 99,9% são 43 minutos. A diferença entre esses dois números é uma decisão de arquitetura e de orçamento, e é sua, não do dev. O SRE Book do Google é a referência de como se define isso sem chutar.

4. Segurança e privacidade. Quem pode ver o quê?
Se você lida com dado de saúde, financeiro ou qualquer dado pessoal, a LGPD não é um requisito opcional; é uma obrigação legal com multa. Quem acessa o prontuário? O dado fica criptografado em repouso? Existe log de quem viu o quê? Isso é requisito não funcional, e ninguém vai escrever no seu lugar.

5. Usabilidade e acessibilidade. Usável por quem?
“A recepcionista precisa concluir um agendamento em menos de 4 cliques.” “O app funciona em Android 9, porque metade da nossa base está em aparelho antigo.” Um requisito de usabilidade com número é um requisito. Sem número, é decoração.

6. Manutenibilidade. Quem consegue mexer nisso depois?
O requisito que mais economiza dinheiro no ano 2 e que praticamente ninguém escreve. Outro time consegue assumir esse código? Tem teste automatizado? Tem documentação? Você está comprando um ativo ou um refém.

7. Recuperação. E quando der errado?
Backup de quanto em quanto tempo? Quanto tempo para restaurar? Você aceita perder as últimas 24 horas de dados, ou os últimos 5 minutos? Essas duas respostas custam preços muito diferentes, e a única coisa pior do que escolher a cara é não escolher e descobrir qual você comprou no dia do desastre.

O requisito em branco não é vazio. Ele tem um valor padrão.

Esta é a frase que vale o artigo inteiro.

Quando você não especifica quantos usuários simultâneos o sistema aguenta, o desenvolvedor não deixa esse campo vazio. Ele preenche. E ele preenche com o valor que é mais rápido de construir e mais barato de rodar, porque foi isso que você pediu quando pediu “o mais rápido e barato possível”. Ele vai subir uma instância pequena, um banco sem réplica, sem fila, sem cache. E vai estar certo, porque você não pediu outra coisa.

O mesmo vale para os outros seis. Sem requisito de disponibilidade, você comprou “o que der”. Sem requisito de backup, você comprou “provavelmente tem”. Sem requisito de manutenibilidade, você comprou um código que só uma pessoa no mundo entende, e essa pessoa não trabalha para você.

Nada disso é má-fé do estúdio. É a consequência mecânica de um contrato que só descreve funções. O fornecedor entrega o que está escrito, e o que está escrito funciona: o checkout do nosso fundador funcionava. Passou em todos os testes. Com um usuário.

É por isso que a pergunta “quanto custa um app?” quase nunca tem resposta honesta antes dessa conversa. O mesmo conjunto de funcionalidades pode custar R$ 80 mil ou R$ 300 mil dependendo apenas dos não funcionais, e nós já escrevemos sobre por que o preço de um aplicativo depende mais de você do que do estúdio.

O teste do número

Se você levar uma única coisa deste artigo, leve esta:

Um requisito não funcional sem número não é um requisito. É um desejo.

“O sistema deve ser rápido” é um desejo. “O sistema deve ser seguro” é um desejo. “O sistema deve ser escalável” é o mais caro de todos os desejos, porque soa técnico o suficiente para todo mundo assinar embaixo sem entender o que comprou.

Um requisito não funcional de verdade tem três partes: número, condição e consequência.

Repare no que a coluna da direita faz: ela transforma uma opinião em algo que pode ser medido, testado e cobrado. É a mesma disciplina dos critérios de aceitação, aplicada às qualidades do sistema em vez de às suas funções.

E repare na terceira parte, a consequência. “Exibe um aviso de espera em vez de erro” é uma decisão de produto que só você pode tomar. O dev pode te dizer quanto custa. Não pode te dizer o que é aceitável para o seu cliente.

Por que os não funcionais decidem o preço

Um estúdio sério vai te cobrar mais caro quando você entrega bons requisitos não funcionais. Isso parece contraintuitivo e é o melhor sinal que existe.

O motivo é simples: aguentar 800 checkouts simultâneos exige infraestrutura, fila, cache e teste de carga. Isso é trabalho real, e trabalho real tem preço. Quando o orçamento sobe depois que você especifica a carga, o que aconteceu não foi um aumento. Foi a revelação do preço verdadeiro, que antes estava escondido atrás de uma premissa que ninguém tinha dito em voz alta.

O orçamento barato que você recebeu antes de escrever os não funcionais não era mais barato. Era o mesmo produto com o risco transferido para você.

Essa é, aliás, a melhor forma de comparar propostas. Mande os sete números para três estúdios. Quem devolver o mesmo preço de antes não leu. Quem subir o preço e explicar linha a linha onde subiu, esse você quer na mesa.

Onde o não funcional vira obrigação

Um número que mora num Google Doc não protege ninguém. Ele precisa atravessar três documentos para virar obrigação:

No levantamento, ele nasce. É onde você descobre que existe um pico às 8h e que metade da base usa Android antigo. Esse trabalho é seu, e nós já detalhamos como fazer um levantamento de requisitos sem ser técnico.

No critério de aceite, ele vira teste. “Teste de carga com 800 sessões simultâneas, executado antes do go-live” é uma linha que transforma uma promessa em um evento verificável, com data.

No contrato, ele vira consequência. Um requisito não funcional que não aparece no contrato de desenvolvimento de software é uma conversa de corredor. Se a disponibilidade contratada é 99,5% e o sistema entrega 97%, o que acontece? Se a resposta for “a gente conversa”, você não tem um requisito. Tem um assunto.

O fundador do curso não perdeu o lançamento porque contratou gente ruim. Perdeu porque comprou um sistema que fazia tudo o que ele pediu, e ele não pediu que funcionasse para 900 pessoas ao mesmo tempo. O documento estava certo. Estava apenas pela metade.

Perguntas frequentes

O que são requisitos funcionais?
São as funções que o sistema precisa executar: o que ele faz. “O usuário redefine a senha por e-mail”, “o gestor exporta o relatório em CSV”. Têm resposta binária: o sistema faz ou não faz. São a parte do escopo que quase todo fundador consegue escrever sozinho.

O que são requisitos não funcionais?
São as qualidades e restrições que valem para todo o sistema: quão rápido, para quantos usuários simultâneos, com qual disponibilidade, com qual nível de segurança, quão fácil de manter, com qual plano de recuperação. Não descrevem uma função nova; descrevem o comportamento de todas elas sob pressão. São os requisitos que decidem o preço da build e o resultado do dia do lançamento.

Qual a diferença entre requisito funcional e não funcional?
O funcional é o quê; o não funcional é quão bem. “Emitir a nota fiscal” é funcional. “Emitir a nota fiscal em menos de 3 segundos, para 500 pedidos simultâneos, com 99,5% de disponibilidade” acrescenta os não funcionais. O funcional determina se o software serve; o não funcional determina se ele aguenta.

Quais são 3 exemplos de requisitos funcionais?
(1) “O paciente escolhe um horário disponível e confirma o agendamento.” (2) “O sistema envia um lembrete por WhatsApp 24 horas antes da consulta.” (3) “A recepcionista remarca uma consulta e o horário antigo volta a ficar disponível.” Todos descrevem uma ação concreta do sistema, com resposta binária.

Quais são os tipos de requisitos não funcionais?
Os que importam para quem contrata uma build são sete: desempenho (quão rápido), carga (para quantos ao mesmo tempo), disponibilidade (quanto downtime é tolerável), segurança e privacidade (quem vê o quê, e a LGPD), usabilidade e acessibilidade (usável por quem, em qual aparelho), manutenibilidade (quem consegue assumir o código depois) e recuperação (backup e tempo de restauração).

Quem escreve os requisitos não funcionais: eu ou o estúdio?
Os números são seus; a arquitetura é do estúdio. Só você sabe que o pico é às 8h, que perder 24 horas de dados é inaceitável e que metade dos seus usuários está em aparelho antigo. Como entregar isso é problema de quem constrói. O erro clássico é terceirizar a pergunta junto com a resposta e descobrir, no lançamento, qual valor padrão você comprou sem saber.