Sistema que funciona com dez registros pode falhar com dez mil. Esse é o cenário que exige saber como definir limites de quantidade para requisitos antes que a diferença apareça em importação, exportação, busca, upload, webhook, fila, login e relatório.

A pergunta prática é como definir limites de quantidade para requisitos antes da geração de código com IA. Volume, tamanho, frequência e lote precisam entrar no texto da especificação, porque o agente não conhece o uso real se ninguém registrar.

Eu vejo esse erro com frequência em projetos guiados por IA: o requisito descreve o fluxo feliz, mas não diz quantos itens, quantas tentativas, qual tamanho de arquivo ou qual volume diário precisa ser suportado. Aqui na Promovaweb, eu prefiro que esse limite apareça cedo, mesmo como hipótese revisável.

Direto ao ponto

Para definir limites de quantidade para requisitos, escreva números ou hipóteses para volume, tamanho, frequência, paginação, lote e capacidade. Também registre o que acontece quando o limite é excedido: bloqueio, fila, aviso, processamento em segundo plano ou revisão humana.

Quantidade é parte do requisito

Quantidade não é enfeite técnico. Quando alguém escreve listar pedidos, ainda falta saber se a tela mostra 20, 50 ou 500 itens por página. Quando alguém escreve importar contatos, ainda falta saber se o arquivo terá 80 linhas, 8 mil linhas ou 80 mil linhas.

Essas respostas mudam o desenho do sistema. Uma busca pequena pode consultar direto. Uma exportação pesada talvez precise de fila, processamento em segundo plano e aviso de conclusão. Um upload sem limite pode gerar custo de armazenamento e suporte antes que alguém perceba.

No SDD, eu gosto de tratar quantidade como uma categoria explícita da especificação. O requisito deve dizer até onde aquele fluxo foi pensado para funcionar, qual cenário inicial foi assumido e qual comportamento deve acontecer quando o teto for atingido.

Onde os limites aparecem na prática

Os limites mais úteis costumam aparecer em lugares simples. Listagem precisa de paginação. Upload precisa de tamanho e formato. Importação precisa de quantidade por arquivo. Login precisa de tentativas. Webhook precisa de frequência aceitável. Relatório precisa de período, lote e forma de entrega.

Um requisito fraco diz o usuário pode anexar documento. Um requisito melhor diz o usuário pode anexar PDF ou JPG com até 5 MB por arquivo, até 10 arquivos por cadastro.

Um requisito fraco diz o gestor pode exportar holerites. Um requisito melhor diz o gestor pode solicitar exportação mensal de até 1.500 holerites; se o lote passar de 200 arquivos, o sistema processa em segundo plano e avisa quando terminar.

Esse tipo de frase parece simples, mas muda a implementação. Também muda a conversa com o cliente, porque todo mundo passa a saber o que foi prometido.

Hipótese é melhor que silêncio

Nem sempre você vai saber o número correto no primeiro dia. Ainda assim, silêncio é pior do que hipótese.

Eu prefiro registrar hipótese inicial: até 10 mil registros por conta do que deixar o requisito aberto. Esse número pode ser revisado quando houver uso real, mas já orienta banco de dados, índice, paginação, fila e teste.

O mesmo vale para tempo de resposta e lote. Em vez de escrever a busca deve ser boa, escreva a busca deve retornar em até 2 segundos no cenário de até 50 mil registros por conta. Se depois o cenário mudar, a especificação muda junto.

Esse cuidado conversa com o artigo sobre como escrever requisitos menos ambíguos no SDD. Ambiguidade não está apenas em frase vaga. Ela também aparece quando falta número.

O que a IA faz quando não recebe limite

Quando o prompt não traz quantidade, a IA tende a resolver o menor exemplo possível. Ela cria uma lista que carrega tudo, uma importação síncrona, uma validação simples ou um endpoint que passa no teste local.

Isso não é má vontade do modelo. É ausência de referência. Se a pessoa pede importar contatos e mostra uma planilha pequena, o agente pode gerar uma solução adequada para aquela amostra. O problema começa quando a primeira conta grande usa o mesmo fluxo.

Eu não deixaria a IA escolher sem orientação se uma importação deve ser síncrona, se precisa de fila, se aceita arquivo grande ou se deve bloquear envio repetido. Essas são decisões de requisito antes de serem decisões de código.

O post sobre como usar IA em requisitos com GitHub Spec Kit aprofunda esse ponto. A ferramenta ajuda a organizar a especificação, mas o critério precisa vir de quem entende o processo, o custo e o risco.

Limite de negócio vem antes do suporte técnico

Um limite pode nascer como regra de negócio. Por exemplo: uma proposta só pode ser reenviada 3 vezes por dia. Depois a implementação pode usar rate limit, log, fila ou alerta.

Se a discussão começa pela ferramenta, o requisito fica fraco. O responsável técnico discute Redis, fila ou cache antes de saber o que precisa proteger. Eu prefiro escrever primeiro o motivo do limite: evitar abuso, controlar custo, preservar experiência, reduzir duplicidade ou manter histórico confiável.

Depois disso, a implementação fica mais objetiva. O código passa a sustentar uma regra explícita, não uma preferencia técnica escondida.

Escreva também a resposta ao limite excedido

Definir teto sem dizer o que acontece depois ainda deixa buraco. O requisito precisa explicar se arquivo acima de 5 MB será rejeitado com mensagem clara, se exportação acima de 200 itens entrará em fila e se a sexta tentativa de login bloqueará o acesso por 15 minutos.

Essas respostas precisam aparecer no requisito. Elas ajudam interface, backend, teste e suporte a trabalharem com a mesma regra.

O artigo sobre como definir estados do sistema no SDD com clareza se conecta aqui. Quando o limite é atingido, o sistema muda de estado: aceito, rejeitado, em fila, aguardando processamento, bloqueado ou pendente de revisão.

Sem essa definição, cada pessoa resolve de um jeito. A interface pode prometer uma coisa, o backend fazer outra e o suporte explicar uma terceira.

Quantidade também orienta testes

Teste bom precisa de número. Se o requisito diz até 50 itens por página, o teste pode verificar paginação. Se diz 5 tentativas em 15 minutos, o teste pode simular a sexta tentativa. Se diz importação até 10 mil linhas, o teste pode validar o cenário limite.

Esse é um ganho importante em projetos com IA. O agente consegue escrever teste melhor quando recebe dado verificável. Sem quantidade, ele tende a testar apenas se a função responde.

Eu considero esse ponto central no Vibe Coding. A IA ajuda muito quando a especificação traz entrada, saída, exceção, limite e critério de aceite. Sem isso, ela entrega código plausível e deixa a revisão pesada para depois.

Perguntas frequentes sobre quantidade em requisitos

Todo requisito precisa ter número?

Não. Mas toda funcionalidade sensível a volume, tamanho, frequência, lote, tentativa ou capacidade deveria ter uma hipótese quantitativa explícita.

E se eu não souber o volume real?

Registre uma hipótese inicial e marque como revisável. Um número provisório orienta melhor do que silêncio, desde que fique claro que ele depende de validação.

Limite é regra de negócio ou detalhe técnico?

Pode ser os dois, mas deve começar pelo negócio. Primeiro defina o que precisa ser protegido. Depois escolha a solução técnica que sustenta essa regra.

Como escrever limite sem travar evolução?

Use linguagem revisável: cenário inicial, hipótese, limite padrão, revisar após uso real e comportamento ao exceder. Isso dá direção sem fingir certeza absoluta.

O que acontece quando o limite é excedido?

O requisito precisa dizer. As opções comuns são bloquear, avisar, enfileirar, processar em segundo plano, pedir redução do arquivo ou encaminhar para revisão humana.

Por que isso importa em projetos com IA?

Porque a IA tende a resolver o exemplo informado. Se o exemplo não traz escala, volume ou frequência, o código pode funcionar no teste pequeno e falhar em produção.

Próximo passo

Se você está usando SDD, GitHub Spec Kit ou agentes de IA para especificar sistemas, a Formação IA Makers da Promovaweb ajuda a escrever requisitos com limite, teste e revisão desde o começo.

Também vale conhecer o material sobre GitHub Spec Kit para organizar melhor especificações antes da implementação.

Definir limites de quantidade nos requisitos não deixa o software mais burocrático. Pelo contrário: deixa a promessa mais honesta. Quem desenvolve sabe qual cenário sustentar, quem testa sabe o que validar e quem vende sabe qual expectativa não deve ultrapassar.