Requisitos incompletos: 10 lacunas que o usuário encontrou
Uma especificação aprovada ainda deixou 10 regras sem definição. Quem as encontrou, as alternativas de cada uma e o que mudou antes do código.
Neste artigo
Requisitos incompletos não são exceção: são o estado normal de qualquer especificação. A do primeiro incremento deste CRM de cobrança tinha 29 regras com exemplos e 26 critérios de aceite, foi revisada e aprovada. Mesmo assim, quando a implementação começou, apareceram dez pontos que ela não definia. Este artigo mostra quais foram, quem os encontrou, as alternativas de cada um e o que foi decidido. Mostra também a parte que costuma ficar invisível: o que acontece quando ninguém decide.
Quem encontra lacunas#
Lacunas não aparecem sozinhas. Quem as encontra são pessoas: quem usa o sistema, quem testa, quem implementa. A diferença está no momento. O usuário encontra a lacuna quando o sistema faz algo inesperado, e aí ela já virou defeito. Quem testa encontra na homologação. Quem implementa encontra antes, porque é obrigado a decidir cada caso.
Uma especificação pode ser lida por cima; uma implementação, não. Cada condição precisa de um caminho: se a linha está em branco, faz o quê? Se o telefone veio vazio, apaga o que estava gravado? Quem revisa o documento lê “o sistema importa a planilha” e segue em frente. Quem implementa precisa escrever o que acontece em cada caso, e é aí que a pergunta aparece.
Neste projeto, as perguntas surgiram durante a implementação, feita com o assistente de IA, e chegaram a mim, usuário da ferramenta e dono das regras, como decisões a tomar.
Num projeto comum, é nesse momento que o requisito incompleto vira uma decisão que ninguém tomou. Não é quem programa que decide: é o projeto. O prazo está correndo, a pergunta não tem a quem ser feita, e a primeira resposta razoável entra no código e ninguém mais fala dela. A regra passa a existir sem ter dono, e só reaparece quando alguém de negócio vê um resultado que não esperava, na homologação ou, pior, em produção.
Com um assistente de IA escrevendo o código, o risco é o mesmo, em velocidade maior. A diferença, neste projeto, foi uma regra de trabalho: lacuna na especificação vira pergunta, nunca suposição. A implementação seguiu com o comportamento mais conservador em cada ponto, para não travar o trabalho, e as dez lacunas voltaram para a especificação como decisões em aberto, com dono e prazo.
As dez lacunas e o que foi decidido#
No formato da planilha#
| Lacuna | Alternativas | Decisão |
|---|---|---|
| Linhas totalmente em branco no meio do arquivo | Ignorar em silêncio; ignorar e informar quantas foram; recusar cada uma | Ignorar e informar: nada some sem o gestor saber, e o relatório de recusas não se enche de falsos erros |
| Linha com mais células preenchidas que o cabeçalho | Ignorar as sobras; ignorar e avisar; recusar a linha | Recusar a linha, mais rígido que a recomendação, que era ignorar e avisar |
| Campo acima do limite (nome com mais de 300 caracteres, por exemplo) | Recusar a linha; cortar o campo e avisar | Recusar: um número de título cortado pode colidir com outro |
Data sem zero à esquerda (1/9/2026) | Aceitar; aceitar só dd/mm/aaaa | Aceitar: não há ambiguidade, e o Excel às vezes exporta assim |
A segunda decisão merece atenção. Uma célula a mais costuma ser um ponto e vírgula dentro de um nome ou de uma descrição, o separador do arquivo aparecendo no meio do texto. Ele desloca todas as colunas seguintes: o valor vai parar no lugar do vencimento, a descrição no lugar do valor. Ignorar as sobras em silêncio, que era o comportamento provisório, podia gravar um valor errado sem nenhum aviso. A recomendação era avisar. A decisão foi recusar a linha, a opção que mais protege contra esse erro.
No cadastro do devedor#
A regra aprovada dizia que nome, telefone e e-mail do devedor seguem a última importação. A lacuna: e se o telefone vier vazio?
- Seguir a regra à risca: o vazio apaga o telefone gravado. Basta o sistema de faturamento exportar um arquivo sem a coluna de telefone para que a carteira inteira perca os contatos.
- Tratar vazio como “não informado”: o telefone anterior continua.
A decisão foi a segunda, e ela mudou uma regra já aprovada. É um caso em que a regra estava certa no geral e errada no detalhe, e só o código mostrou o detalhe.
Na privacidade#
O CPF aparece mascarado na lista de devedores (529.***.***-25), e completo só na ficha. A especificação não dizia nada sobre o CNPJ. As alternativas eram mascarar igual ao CPF, mostrar completo, porque o CNPJ é dado público no cadastro da Receita, ou deixar a decisão com quem cuida da LGPD. A decisão foi mascarar igual ao CPF. O motivo é o microempreendedor individual: o cadastro do MEI costuma trazer o nome e o CPF do dono, e o CNPJ dele aponta para uma pessoa física.
Na consulta da carteira#
| Lacuna | Alternativas | Decisão |
|---|---|---|
| O que soma cada faixa de atraso no resumo | O vencido do devedor, na faixa do seu título mais atrasado; cada título na faixa do seu próprio atraso; as duas visões | As duas visões, contra a recomendação de uma só |
| Credor que deixa o “a vencer” só na ficha: devedor que só tem títulos a vencer aparece na lista? | Aparecer como “sem atraso”; sair da lista e ser encontrado pela busca | Sair da lista, coerente com “fora dos totais” |
| A busca por “joao” encontra “João”? | Ignorar acentos; diferenciar | Ignorar acentos: quem digita rápido não acentua |
| Tempo máximo da lista com 200 mil títulos (medido: 2,8 s) | 1 s, otimizando a consulta; 3 s; sem meta por ora | 3 s, contra a recomendação de 1 s |
As faixas de atraso mostram um conflito entre áreas que a especificação não tinha percebido. Para a cobrança, o devedor é a unidade: quem tem um título de 400 dias e outro de 5 dias é um devedor antigo, e é assim que vai ser abordado. Para o financeiro, a unidade é o título: o de 5 dias é recente, e é assim que entra na conta da provisão para perdas. As duas leituras estão certas. Uma tabela só atenderia uma das áreas. A decisão foi mostrar as duas.
O que mudou na especificação#
As decisões viraram a revisão 2 da especificação, aprovada antes de qualquer alteração no código:
- Quatro regras mudaram: a do cadastro (contato vazio não apaga), a do modo “só na ficha”, a da busca (sem acento) e a do resumo (duas distribuições por faixa).
- O formato da planilha ganhou regras para linhas em branco, células a mais, tamanho de campo e datas.
- Seis critérios de aceite novos, um para cada comportamento alterado, no mesmo formato “dado, quando, então” dos anteriores. Um deles: “Dado a devedora Maria da Silva gravada com telefone (11) 98765-4321, quando uma nova carga traz Maria sem telefone e é confirmada, então o telefone continua (11) 98765-4321”.
- A meta de desempenho passou a incluir a lista com 200 mil títulos em até 3 segundos.
A ordem importa: especificação primeiro, código depois. Se o código mudasse antes, a especificação deixaria de descrever o sistema, e a próxima pessoa a ler o documento estaria lendo um sistema que não existe mais.
O padrão por trás das dez lacunas#
Das dez lacunas, três teriam passado despercebidas até causar dano, e nenhuma delas é um defeito de programação. Todas são decisões de negócio que ninguém tinha tomado:
- o contato vazio apagaria os telefones da carteira inteira no primeiro arquivo incompleto;
- a coluna deslocada por um ponto e vírgula gravaria valores errados em silêncio;
- uma faixa de atraso calculada só de um jeito deixaria uma das áreas trabalhando com o número da outra.
Em três das dez, a decisão contrariou a recomendação: recusar a linha com células a mais, mostrar as duas visões de faixa e aceitar 3 segundos na lista. Em todas, quem decidiu foi quem conhece a operação, olhando as consequências de cada alternativa. Nenhuma ficou a cargo de quem estava escrevendo o código.
O que vem a seguir#
Com a revisão 2 aprovada, o código muda para cumprir as quatro regras alteradas e os seis critérios novos, que viram testes automatizados como os anteriores. Depois começa a especificação do segundo incremento: perfis de gestor e operador, gestão de usuários pela tela e um usuário de demonstração público, com dados fictícios renovados todo dia.
