A reunião de levantamento termina, e o resultado é uma lista: cadastrar, consultar, editar, excluir, gerar relatório, enviar notificação. Todo mundo sai com a sensação de que avançou. Só que a lista não diz por que cada item existe, o que limita seu uso nem como saber se ficou certo.

Isso é uma lista de pedidos. Requisito é outra coisa.

Quatro camadas que costumam vir misturadas

Uma das práticas mais úteis em análise é separar camadas que quase sempre chegam juntas na mesma frase:

• Necessidade: o problema ou o resultado que se quer alcançar.
• Regra de negócio: uma condição do domínio que precisa ser respeitada.
• Requisito: o comportamento ou a qualidade que a solução deve oferecer.
• Decisão de solução: como o requisito será implementado.

Veja um caso real (anonimizado). Um repositório de documentos recebeu o pedido: “colocar marca d’água nos documentos”. Parece um requisito, mas é uma solução. Separando as camadas:

A separação dá liberdade. Se a solução mudar amanhã, a necessidade e a regra continuam válidas. Quando tudo vira um único “requisito”, uma tecnologia específica passa a parecer obrigatória, mesmo que outra resolva melhor.

O mesmo vale para pedidos como “usar OCR”, “adotar microsserviços” ou “integrar com a plataforma X”. São alternativas de solução. Precisam de justificativa, não de aceitação automática.

A pergunta que transforma pedido em regra

No caso da marca d’água, a frase original deixava quase tudo em aberto. Quais documentos seriam protegidos? Em quais operações: visualizar, baixar, imprimir? Todas as páginas? E os anexos? Que identificação aparece, e quem pode ver os dados completos? Por quanto tempo os registros ficam guardados? E se a marca não puder ser aplicada?

Respondidas essas perguntas, o pedido virou regras verificáveis: identificação na visualização, no download e na impressão; proteção em todas as páginas e anexos; dado pessoal sempre mascarado; código de correlação próprio para cada acesso; nenhuma impressão concluída sem identificação. Layout, opacidade e posição da marca só foram discutidos depois, como escolhas de design subordinadas às regras.

História de usuário ajuda, mas não fecha o assunto

“Como auditor, quero identificar a origem de uma cópia para apoiar uma apuração.” A história expressa a intenção e é ótima para conversar e priorizar. Mas ainda falta dizer quais eventos podem ser consultados, que dados estarão disponíveis, que autorização é exigida e como os acessos do próprio auditor serão registrados. A história é a porta de entrada; os critérios de aceite completam o comportamento.

Critério de aceite é evidência, não instrução

Critério de aceite descreve uma condição observável que precisa ser verdadeira para a entrega ser aceita. Ele deve cobrir o fluxo principal, os limites, as exceções, a autorização e os efeitos colaterais que importam.

O formato Dado–Quando–Então ajuda a deixar contexto, ação e resultado explícitos:

Cenário: impressão identificada Dado que o usuário está autorizado a consultar o documento Quando solicitar a impressão Então todas as páginas e anexos recebem a identificação vinculada ao acesso E a tentativa e a conclusão da operação são registradas para auditoria

Repare que o cenário não fala em botão nem em tela. Ele vale para qualquer canal pelo qual a impressão aconteça. Escrever no formato Dado–Quando–Então não garante qualidade; o que garante é o cenário usar a linguagem do negócio e representar uma regra real.

As exceções também são requisito

O fluxo principal recebe atenção porque é fácil de demonstrar. A complexidade costuma morar nas exceções: arquivo corrompido, serviço fora do ar, acesso expirado, falha ao gravar a auditoria. Cada uma pede uma decisão: bloquear, repetir, compensar ou encaminhar para tratamento manual. Se a marca d’água é obrigatória, deixar a impressão seguir quando ela falha viola a regra.

Checklist de refinamento

• O problema e o resultado esperado estão claros?
• Cada regra tem origem e responsável conhecidos?
• Necessidade, requisito e decisão técnica estão separados?
• Requisitos de qualidade têm medida, e não só adjetivos como “rápido” ou “discreto”?
• Os critérios de aceite cobrem autorização, limites e exceções?
• Dá para ligar cada regra a um teste?

Para ir além

O capítulo 4 do livro Engenharia de Software: Fundamentos e Práticas aprofunda esse caminho: tipos de regra de negócio, requisitos de acessibilidade com base na WCAG e na ABNT NBR 17225, a diferença entre protótipo, prova de conceito, piloto e MVP, e um exercício para transformar um pedido escrito como solução em regras, requisitos e critérios.

Conheça o livro e veja o sumário completo. Se ainda não leu, o artigo Engenharia de Software começa antes do código é um bom ponto de partida.