Prazo mal escrito parece detalhe enquanto a interface ainda está sendo desenhada, mas definir prazos em requisitos SDD precisa entrar cedo na especificação. O problema aparece quando reset de senha, proposta, cupom, sessão, retry de API ou reserva começa a depender do relógio e ninguém sabe qual regra deveria vencer.

Para definir prazos em requisitos SDD, a pessoa precisa escrever o gatilho que inicia a contagem, a duração com unidade e timezone, e a consequência aplicada quando o prazo expira. Sem isso, a IA tende a preencher o vazio com uma suposição razoável, mas difícil de revisar depois.

Direto ao ponto

Tempo em requisito não é enfeite técnico, porque define expiração, validade, timeout, janela de retry, sessão, reserva e mudança de estado. Um SDD útil transforma esse tempo em regra verificável, com evento inicial, duração, referência de horário, tolerância e efeito depois do vencimento.

Esse cuidado reduz suposição na implementação assistida por IA e torna a revisão mais concreta. Quando o prazo está claro, quem escreve código entende a regra, quem revisa sabe o que testar e quem mantém o sistema não precisa reconstruir a decisão pela memória.

O que precisa entrar no requisito temporal

Um requisito temporal ruim costuma usar palavras que parecem claras na conversa humana, como “temporário”, “em breve”, “depois de um tempo”, “até a confirmação” ou “por alguns dias”. Para código, teste e IA, essas expressões deixam espaço demais, porque não dizem quando a contagem começa nem o que acontece no vencimento.

Eu gosto de ler requisito temporal procurando cinco peças, sempre conectadas ao comportamento que será implementado. A tabela abaixo serve como revisão rápida para transformar prazo vago em regra que pode ser testada.

Peça	Revisão	Exemplo de resposta clara
Gatilho	Identificar o evento que inicia a contagem.	Envio do email, aceite da proposta, login, pagamento aprovado ou criação da reserva.
Duração	Definir quanto tempo vale a regra.	15 minutos, 24 horas, 7 dias corridos, 5 dias úteis ou 30 dias.
Referência	Registrar qual timezone ou calendário será usado.	UTC, America/Sao_Paulo, calendário comercial ou regra interna de feriados.
Tolerância	Declarar margem aceita para atraso, retry ou processamento assíncrono.	Até 5 minutos de atraso antes de marcar falha, quando houver fila.
Consequência	Escrever a ação aplicada ao expirar.	Bloquear, avisar, liberar recurso, pedir revalidação ou enviar para revisão humana.

Quando essas peças aparecem no SDD, a implementação fica menos aberta a interpretação e a IA recebe escopo suficiente para gerar algo mais próximo da intenção real. Esse mesmo princípio aparece em como escrever requisitos menos ambíguos no SDD hoje, porque ambiguidade também nasce quando uma palavra simples esconde uma regra verificável.

Onde o prazo vago cria bug caro de revisar

Prazo vago é traiçoeiro porque a tela pode parecer correta, o botão aparece, o formulário envia, a mensagem chega e o teste feliz passa. O problema nasce nos casos de borda, quando o relógio decide algo que o requisito não explicou.

Um link de redefinição de senha pode continuar válido por tempo demais, enquanto uma proposta pode expirar antes do prazo comercial combinado. Um cupom pode funcionar em timezone errado, uma sessão pode derrubar o usuário durante uma ação crítica e um retry de integração pode duplicar evento porque ninguém definiu janela de idempotência.

Esses bugs raramente aparecem como erro visual, pois chegam como disputa de regra, atendimento confuso, falha de segurança, dado duplicado ou reclamação comercial. Por isso eu trato tempo como parte do contrato do sistema, não como detalhe escondido na implementação.

Esse raciocínio conversa com como definir estados do sistema no SDD com clareza. Prazo muda estado, e estado mal definido tende a criar comportamento instável quando a regra precisa decidir entre ativo, expirado, pendente, bloqueado ou revalidado.

Como a IA interpreta tempo quando o SDD não explica

Quando o SDD não define prazo, a IA costuma escolher um padrão provável, como 24 horas para um link, 30 minutos para uma sessão, 3 tentativas para retry ou horário local do servidor para expiração. Esses palpites parecem bons porque são comuns, mas comum não significa correto para o seu sistema.

O risco aumenta porque a implementação pode vir acompanhada de nomes convincentes, testes superficiais e comentários que dão aparência de decisão tomada. Se ninguém escreveu a regra temporal, o código passa a registrar uma suposição como se fosse requisito.

Aqui na Promovaweb, eu prefiro revisar requisito temporal como parte da especificação no Vibe Coding. A IA ajuda a transformar especificação em código, mas a pessoa responsável precisa declarar evento, duração, timezone e consequência antes da implementação.

Esse é o tipo de histórico que também aparece na Formação IA Makers, porque desenvolvimento assistido por IA depende de especificação revisável. Sem essa base, a IA pode gerar rápido e ainda assim deixar o sistema preso a decisões que ninguém assumiu.

Como escrever prazos no SDD sem virar tutorial

O SDD não precisa virar manual extenso, mas precisa registrar decisões que afetam comportamento. Para prazo, uma frase boa costuma combinar evento inicial, duração, referência de horário e efeito aplicado depois do vencimento.

Em vez de escrever “o link expira depois de um tempo”, registre que o link de redefinição expira 30 minutos após o envio do email, usando timezone UTC, e que uma nova solicitação invalida o link anterior. Esse tipo de frase dá base para implementação, teste e revisão, porque transforma uma intenção vaga em regra observável.

Em vez de “a proposta fica válida por alguns dias”, registre que a proposta fica válida por 7 dias corridos a partir do aceite enviado ao cliente, com expiração às 23h59 no timezone America/Sao_Paulo. Depois desse horário, o sistema deve pedir nova aprovação comercial e mostrar um aviso claro para quem tenta seguir com a proposta antiga.

O formato pode variar, desde que a regra responda aos pontos que sustentam implementação e teste. Eu revisaria início, duração, fonte de horário, mudança de estado, efeito para o usuário e evidência de validação.

• Início: qual evento começa a contar o prazo.
• Duração: qual unidade, quantidade e calendário serão usados.
• Fonte de horário: qual timezone ou referência técnica orienta a comparação.
• Mudança de estado: qual campo muda quando o prazo vence.
• Efeito para o usuário: qual aviso, bloqueio ou próxima ação aparece.
• Revisão: qual teste prova que a regra foi respeitada.

Ferramentas ajudam quando a regra já está explícita

GitHub, Laravel e n8n podem apoiar esse fluxo em pontos diferentes. GitHub ajuda a registrar issue, pull request, discussão e regra de aceite; Laravel implementa a regra temporal no domínio da aplicação; n8n orquestra alertas, retries e integrações que dependem de horário.

Ferramenta nenhuma substitui a regra, porque um SDD que diz “expirar depois” permite que Laravel implemente um prazo arbitrário. Se o workflow do n8n não sabe quantas tentativas são aceitas ou qual janela vale para retry, a automação pode insistir demais ou interromper cedo demais.

Esse tema se conecta ao post sobre como usar GitHub Issues no SaaS com governança clara. Issue boa não é tarefa solta, pois registra intenção, evidência e aceite, enquanto prazo em requisito precisa desse mesmo nível de clareza.

Para comparar essa decisão com outras trilhas da Promovaweb, a página de formações ajuda a separar aprendizado de IA, automação, infraestrutura e gestão. Neste tema, o vínculo principal fica com IA Makers porque o risco nasce antes da geração de código.

Critérios frequentes sobre prazo em requisitos SDD

Prazo numérico

Quando o prazo vira comportamento de sistema, ele precisa ter número, unidade e evento inicial. Termos como “temporário” ou “em breve” podem orientar conversa, mas não sustentam teste automatizado, revisão de código ou implementação com IA.

Timezone no requisito

O requisito deve definir a referência usada para gravar, comparar e exibir horários. Em sistemas distribuídos, UTC costuma ser usado para armazenamento e comparação, enquanto a interface pode exibir o horário no fuso do usuário ou da empresa.

Prazo, expiração e timeout

Prazo costuma indicar validade de uma regra de negócio, como proposta ou reserva, enquanto expiração marca o momento em que um acesso, link ou condição perde validade. Timeout indica limite técnico de espera por resposta, conexão ou processamento, e misturar esses termos no SDD cria implementação confusa.

Primeiro lugar do erro temporal

O erro temporal aparece primeiro em fluxos que mudam de estado sem intervenção direta, como reset de senha, sessão, reserva, cupom, proposta, retry de integração, pagamento pendente e reprocessamento de fila. Eu revisaria antes os pontos em que expiração afeta segurança, cobrança, acesso, atendimento ou dado sensível.

Revisão com IA

Leia o SDD procurando gatilho, duração, timezone, tolerância e consequência, depois peça para a IA apontar casos de borda. Se a IA sugerir um padrão, trate como hipótese, porque a decisão final precisa vir de regra de negócio, contrato, segurança, suporte ou experiência do usuário.

Testes depois da implementação

Teste o momento antes do vencimento, o instante de vencimento, o momento depois da expiração e a repetição do evento inicial. Quando houver integração, teste também fila, retry, idempotência e comportamento em timezone diferente, porque regra temporal raramente falha só no caminho feliz.

Próximo passo prático

Escolha um fluxo do seu sistema que depende de tempo e escreva a regra em uma frase com evento inicial, duração, timezone e consequência. Depois revise se essa frase permite criar teste sem perguntar nada para quem escreveu.

Se a resposta for sim, o requisito já ficou mais útil para IA, revisão humana e manutenção. Se ainda houver dúvida, o problema não está no código, mas na decisão temporal que ainda não foi escrita.