Engenharia de requisitos: o que o pedido não diz

O pedido chega como uma frase. “Precisamos de um sistema para cadastrar pacientes, acompanhar consultas e registrar pagamentos.” Parece completo. Não está.

Quem formula o pedido já vive o problema. Por isso omite o óbvio: quem pode ver o prontuário, o que acontece quando o pagamento atrasa, se o mesmo paciente pode ter dois cadastros, se o médico atende em mais de uma clínica. O que falta não é um parágrafo a mais. É o trabalho de descobrir o que a frase não diz.

Engenharia de requisitos não é transcrever o desejo. É transformar um sintoma em restrições verificáveis.

O pedido é um exemplo disfarçado de regra

Quase todo pedido vem na forma de um caso. “O paciente paga com cartão.” “A secretária imprime a ficha.” “O médico consulta o histórico.” Esses casos são úteis. Eles não são a regra.

A regra responde a outra pergunta: o que deve valer para todos os casos parecidos, inclusive os que ninguém descreveu ainda?

Se o cliente diz que o paciente paga com cartão, a regra pode ser: a clínica aceita os meios de pagamento que a operadora usa hoje. Cartão é um exemplo. Pix, convênio e isenção por campanha são variações que o exemplo escondeu. Se você implementar só o cartão, não falhou a programação. Falhou a generalização.

A distinção evita um erro comum: tratar a demonstração do usuário como especificação. Uma tela desenhada no papel é um recorte. Uma regra de negócio sobrevive à troca de tela.

flowchart TD
  A[Pedido] --> B[Perguntas]
  B --> C{Exemplo ou regra?}
  C -->|Exemplo| D[Generalizar]
  C -->|Regra| E[Restrição]
  D --> F[Especificação]
  E --> F
  classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
  classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
  classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
  class A ouro
  class B,C,D,E verde
  class F fim

O sistema antigo já contém a maior parte das regras

Quando existe um legado — fichas de papel, planilha, sistema velho — o pedido costuma descrever o que incomoda, não o que funciona. O que funciona permanece invisível porque ninguém discute o que já está no hábito.

Sente ao lado de quem opera. Não para copiar a tela. Para ver as exceções: o paciente que muda de nome, o médico que atende no lugar de outro, o convênio que cobre só parte do procedimento, o caixa que fecha com diferença. Essas exceções são requisitos. Elas raramente aparecem na primeira reunião.

Pergunte também o que a forma atual impede. Nem toda regra antiga merece sobreviver. Algumas existem porque o papel não permitia outra coisa. Distinguir restrição de negócio de restrição de suporte antigo é parte da análise.

Perguntas que fazem a restrição aparecer

As perguntas úteis não pedem mais features. Elas forçam o limite.

• Quem? Quem usa, quem aprova, quem não pode ver. “O médico acompanha o histórico” não diz se a recepção lê o mesmo histórico, se um médico vê o de outro, se o paciente acessa o próprio prontuário.
• Quando? Antes, durante ou depois de qual evento. Um pagamento registrado na hora da consulta não é o mesmo que um pagamento conciliado no dia seguinte.
• O que acontece se falhar? Sem internet, sem estoque, sem autorização do convênio, com paciente menor de idade. A exceção revela a regra melhor do que o caminho feliz.
• O que é proibido? Requisitos negativos importam. “Não armazenar o número completo do cartão” é tão decisivo quanto “aceitar cartão”.
• Como se mede que está certo? Se ninguém sabe dizer o que seria um erro, o requisito ainda é um desejo.

Faça essas perguntas para cada detalhe, não só para o sistema inteiro. Paciência aqui economiza retrabalho depois. Medo de perguntar é uma forma cara de adivinhar.

Regras, preferências e invariantes

Nem tudo que o cliente pede tem o mesmo peso. Três categorias ajudam a não tratar tudo como urgente.

Invariante é o que não pode ser violado sem quebrar o negócio ou a lei: um medicamento controlado não pode ser vendido sem a restrição correspondente; um prontuário não pode ser apagado por engano. Isso entra cedo e não é negociável no sprint.

Regra é uma condição que o sistema aplica: se o convênio não autorizar, a consulta não entra como coberta. Regras podem evoluir, mas precisam estar explícitas.

Preferência é flexível. O cliente pode preferir cartão e, no mês seguinte, Pix. Oferecer um padrão e deixar a escolha aberta é diferente de gravar a preferência como se fosse lei.

Quando tudo vira “requisito crítico”, nada é. Priorizar — crítico, importante, adiado — só funciona depois que você separou o que é invariante do que é gosto.

O que o documento precisa carregar

Um documento de requisitos não precisa ser um romance nem um contrato ilegível. Precisa permitir que alguém, meses depois, distinga o que foi pedido do que foi assumido.

Registre, para cada regra relevante:

1. a afirmação em linguagem do negócio;
2. o exemplo que a originou;
3. a restrição que o exemplo não dizia;
4. o que acontece no caso de falha;
5. quem confirmou.

Essa lista é mais útil do que uma ata genérica. A ata ainda vale: envie o que foi dito, peça confirmação, evite o “eu pensei que”. Mas a unidade de trabalho não é a reunião. É a regra verificável.

Requisitos funcionais descrevem o que o sistema faz. Não funcionais descrevem o que o sistema precisa aguentar: tempo de resposta, privacidade, auditoria, horário de funcionamento. Um cadastro de pacientes que “funciona” e demora meia hora para abrir o histórico não atende o pedido, mesmo que a tela esteja certa.

Há ainda os requisitos de domínio: regras que vêm da profissão, não da imaginação do time. Farmácia, clínica, escola e banco já chegam com restrições prontas. Ignorá-las não é agilidade. É construir o sistema errado com rapidez.

Comunicação é a ferramenta, não a cerimônia

Entrevista aberta serve para descobrir. Entrevista fechada serve para confirmar. Workshop serve quando várias papéis precisam ver o mesmo desenho. Nenhuma dessas formas substitui a pergunta precisa.

Fale a língua do negócio. “Módulo de faturamento” pode significar três coisas diferentes para o financeiro, para a recepção e para o médico. Se você traduz cedo demais para tabela e endpoint, perde o conflito. O conflito é o requisito: duas áreas querem comportamentos incompatíveis, e alguém precisa decidir.

Não manipule a resposta. Apresente o que ouviu sem maquiagem. O analista que “ajuda” o cliente a querer o que o time já sabe fazer está documentando a solução, não o problema.

Por onde começar na próxima conversa

1. Escreva o pedido em uma frase, como chegou.
2. Marque cada substantivo e cada verbo: paciente, consulta, pagamento, cadastrar, acompanhar.
3. Para cada um, faça uma pergunta de limite: quem, quando, o que é proibido, o que acontece se falhar.
4. Separe o que era exemplo do que é regra.
5. Leve a regra de volta para quem opera e pergunte onde ela quebra.

O pedido não é o inimigo. Ele é o ponto de partida. O trabalho começa quando você admite que a frase mais clara da reunião ainda esconde metade do sistema.

Requisito mal feito vira código que ninguém consegue explicar. A Programming One cresce o projeto a partir da necessidade do capítulo, não de uma lista de features combinada no vazio.

Leia também: Como pesquisar sem se perder em informação.