Engenharia de Requisitos: do pedido vago ao requisito verificável

Introdução

Sabe quando um projeto começa com uma frase simples?

“Precisamos de um sistema de agendamento”, “precisamos de um dashboard” ou “precisamos de uma área de assinatura”.

No começo, parece suficiente. O time já imagina telas, endpoints, banco de dados, integrações e até algumas decisões de arquitetura.

Mas logo aparecem as perguntas que ninguém respondeu:

• quem pode usar?
• quais regras precisam ser respeitadas?
• o que acontece quando dá erro?
• existe limite, permissão ou histórico?
• como saberemos que isso ficou pronto?

É aí que muita complexidade aparece. Não porque o código seja impossível, mas porque, naquele momento, o entendimento do problema ainda era insuficiente.

Software construído em cima de suposição costuma cobrar a conta depois: retrabalho, mudança de escopo, regra escondida, teste faltando e decisão técnica tomada cedo demais.

Engenharia de requisitos entra justamente nesse ponto: antes de sair construindo, precisamos entender o problema, as regras e os limites.

Não adianta produzir um documento enorme que ninguém lê. A documentação existe para alinhar negócio, usuário, produto e tecnologia antes que uma ideia vaga vire código.

O que é requisito

Requisito é uma representação clara e utilizável de uma necessidade: algo que uma mudança, processo ou solução precisa atender para gerar valor ou respeitar uma condição.

Ele ajuda a responder perguntas como:

• o que precisa acontecer?
• para quem isso importa?
• quais regras precisam ser respeitadas?
• quais limites não podem ser ignorados?
• como saberemos que funcionou?

Um erro comum é tratar requisito como sinônimo de feature.

Feature é uma possível entrega.
Requisito é a necessidade que justifica essa entrega.

Por exemplo:

• “precisamos de uma tela de relatórios” é uma possível solução;
• “o usuário precisa acompanhar pedidos atrasados por período, status e responsável” é uma necessidade mais clara.

O mesmo vale para decisões técnicas.

Dizer “precisamos usar Kafka” já pula direto para a solução. Talvez Kafka faça sentido, talvez não. O requisito por trás pode ser outro:

Precisamos processar eventos com tolerância a falhas, sem perder mensagens e com possibilidade de reprocessamento.

Agora a conversa muda.

Em vez de discutir tecnologia por preferência, o time passa a discutir qual solução atende melhor ao problema.

Quanto mais claro o requisito, menos a decisão técnica depende de achismo.

Quando cada um entende uma coisa

Requisitos ruins geralmente não começam como problema de código.

Começam na comunicação.

Uma pessoa faz o pedido, outra transforma aquilo em escopo, outra decide como construir e, no final, o usuário pode receber algo diferente do que realmente precisava.

A tirinha tem décadas e continua descrevendo projetos atuais. O desenho exagera de propósito. O problema que ele mostra, não.

O cliente imagina uma coisa. Produto entende outra. Desenvolvimento implementa outra. E o usuário talvez precisasse de algo muito mais simples, algo que nem ele conseguia explicar com clareza.

Esse desencontro acontece porque cada pessoa observa o problema a partir do próprio contexto:

• o cliente fala sobre uma necessidade;
• produto pensa em escopo e prioridade;
• engenharia pensa em implementação;
• gestão pensa em prazo e custo;
• suporte antecipa os problemas que podem aparecer;
• o usuário apenas quer concluir sua tarefa com o menor atrito possível.

Nenhuma dessas perspectivas é necessariamente errada. O problema aparece quando elas permanecem implícitas e cada pessoa assume que todos entenderam a mesma coisa.

O papel dos requisitos é tornar essas interpretações visíveis antes que elas virem escopo, código e retrabalho.

Requisito bom não é o texto mais longo.

É o entendimento que reduz ambiguidade entre quem pede, quem decide, quem constrói e quem usa.

Tipos de requisitos

Nem todo requisito descreve uma funcionalidade do sistema.

Alguns explicam por que uma mudança precisa acontecer. Outros representam necessidades de usuários e áreas envolvidas ou definem o que a solução precisa entregar.

Existem diferentes formas de organizar requisitos. Neste artigo, vamos usar uma divisão prática que acompanha o caminho entre o problema e a solução:

A seta não indica importância nem ordem de execução. Ela mostra que cada nível existe por causa do que está acima dele.

Na prática, isso vira uma pergunta útil: pegando um requisito lá de baixo, conseguimos subir até um resultado de negócio? Quando a resposta é não, normalmente falta uma conversa antes de começar a construir.

Regras de negócio e restrições também participam desse caminho, mas exercem outro papel: elas orientam ou limitam os requisitos da solução.

Requisitos de negócio

Requisitos de negócio explicam por que uma mudança precisa acontecer e qual resultado a organização espera alcançar.

Eles descrevem objetivos, problemas ou resultados desejados sem definir, necessariamente, como a solução será construída.

Uma forma simples de reconhecê-los é perguntar: qual resultado para o negócio justifica esta iniciativa?

Reduzir em 40% os cancelamentos de assinatura processados manualmente pelo suporte.

Esse requisito não descreve uma tela, um endpoint ou uma ação específica do sistema. Ele define o resultado que motivou a mudança.

A partir dele, diferentes soluções poderiam ser consideradas: permitir o cancelamento pelo próprio cliente, melhorar o processo interno do suporte ou automatizar parte do atendimento.

O requisito de negócio orienta a direção. A solução será definida depois.

Requisitos dos stakeholders

Stakeholders podem ser usuários, clientes, suporte, financeiro, jurídico, operação, segurança ou qualquer outra parte afetada pela mudança.

Seus requisitos descrevem o que essas pessoas ou áreas precisam para alcançar o resultado esperado.

Não é apenas um requisito “pedido por alguém”. Ele registra uma necessidade de quem será afetado pela mudança, sem decidir ainda como a solução vai atendê-la. Enquanto o requisito de negócio explica o resultado buscado, o requisito de stakeholder deixa claro quem precisa de quê para chegar lá.

Uma forma simples de reconhecê-los é perguntar: quem é afetado pela mudança e do que essa pessoa ou área precisa?

O cliente precisa cancelar sua assinatura sem entrar em contato com o suporte.

O suporte pode ter outra necessidade relacionada ao mesmo processo:

O suporte precisa consultar quem cancelou a assinatura, quando a ação aconteceu e por qual canal.

Nenhuma das duas frases define completamente a solução. Elas mostram necessidades de stakeholders diferentes que precisarão ser atendidas.

É comum que essas perspectivas entrem em conflito. O cliente deseja menos etapas, enquanto segurança pode exigir uma confirmação adicional. Produto busca uma experiência simples, enquanto o financeiro precisa preservar rastreabilidade.

A Engenharia de Requisitos ajuda a tornar esses conflitos visíveis antes que virem decisões implícitas no código.

Requisitos da solução

Requisitos da solução descrevem o que a solução precisa oferecer para atender às necessidades do negócio e dos stakeholders.

Eles costumam ser divididos em:

• requisitos funcionais;
• requisitos não funcionais.

Essa divisão ajuda a separar as capacidades da solução das condições de qualidade em que elas precisam funcionar.

Requisitos funcionais

Requisitos funcionais descrevem comportamentos, capacidades e respostas da solução.

Em outras palavras: o que o sistema deve fazer.

Alguns exemplos:

• cadastrar um usuário;
• gerar um relatório;
• cancelar uma assinatura;
• processar um pagamento.

Uma forma simples de reconhecê-los é perguntar: existe uma ação ou resposta observável que o sistema precisa executar?

Quando o pagamento for aprovado, o sistema deve ativar a assinatura e enviar um e-mail de confirmação ao cliente.

Esse é um requisito funcional porque descreve ações que o sistema precisa executar: ativar a assinatura e enviar a confirmação.

O comportamento também pode acontecer sem interação direta de uma pessoa. Jobs, integrações, eventos e processos automáticos continuam sendo funcionais quando descrevem algo que o sistema faz.

Requisitos não funcionais

Requisitos não funcionais descrevem características de qualidade e condições nas quais a solução precisa operar.

Eles não dizem necessariamente o que o sistema faz, mas definem com qual desempenho, segurança, disponibilidade, confiabilidade ou escala uma capacidade precisa funcionar.

Compare:

O usuário deve conseguir pesquisar pedidos.

Esse é um requisito funcional, porque descreve uma capacidade.

A pesquisa deve responder em até dois segundos para 95% das requisições em condições normais de uso.

Esse é não funcional, porque define o desempenho esperado para essa capacidade.

Dizer apenas que o sistema deve ser “rápido”, “seguro” ou “escalável” ainda é vago. Sempre que possível, o requisito precisa ser observável, mensurável ou verificável.

Outros exemplos seriam impedir que dados sensíveis apareçam em logs, manter determinada disponibilidade mensal ou gerar identificadores de rastreamento entre serviços.

Uma forma simples de reconhecê-los é perguntar: esse requisito define com qual desempenho, segurança, disponibilidade ou confiabilidade a solução precisa funcionar?

Também existem áreas cinzentas.

“Permitir autenticação em dois fatores” pode ser considerado funcional, porque adiciona um comportamento ao sistema. Já “proteger contas contra acessos não autorizados” representa um objetivo de segurança mais amplo.

A classificação ajuda a organizar a conversa, mas não deve virar uma disputa de nomenclatura.

Requisitos de transição

Requisitos de transição existem apenas para levar a operação do estado atual ao novo. Eles podem envolver migração de dados, treinamento, rollout gradual ou convivência temporária com legado.

Uma forma simples de reconhecê-los é perguntar: essa necessidade desaparece depois que a mudança entrar em operação?

Antes da liberação do novo sistema, as assinaturas ativas devem ser migradas com seus planos e datas de renovação preservados.

O que os separa dos demais é o prazo de validade. Depois que a transição termina, eles deixam de existir, enquanto os outros requisitos continuam descrevendo a solução em operação.

Regras e restrições

Regras de negócio e restrições não representam necessidades no mesmo nível dos requisitos anteriores.

Elas acompanham esse caminho por fora, definindo decisões que precisam ser respeitadas ou limites que reduzem as opções disponíveis quando a solução toma forma.

Regras de negócio

Regras de negócio representam políticas, decisões e condições próprias da empresa ou do domínio.

Elas definem como uma situação deve ser tratada, independentemente de existir um sistema para automatizá-la.

Uma forma simples de reconhecê-las é perguntar: qual decisão o negócio definiu para esta situação?

Ao cancelar uma assinatura, o cliente mantém o acesso até o fim do período já pago.

Essa é uma escolha do negócio.

Outra empresa poderia encerrar o acesso imediatamente ou devolver o valor proporcional. Nenhuma alternativa é tecnicamente mais correta. A organização define qual política será aplicada.

A partir dessa regra, podem surgir requisitos funcionais para cancelar a renovação, manter a assinatura ativa até uma data específica, impedir novas cobranças e comunicar o cliente.

A regra de negócio define qual política o comportamento do sistema precisa respeitar.

O requisito funcional descreve o que o sistema deve fazer para aplicar essa política.

Restrições

Restrições são limites que reduzem as opções disponíveis para o projeto.

Elas não descrevem necessariamente uma necessidade do usuário nem uma qualidade desejada. Elas determinam quais caminhos a solução pode ou não seguir.

Podem ter origem técnica, financeira, legal, operacional, organizacional ou contratual.

Alguns exemplos:

• utilizar um banco de dados já adotado pela empresa;
• executar a aplicação em determinada cloud;
• respeitar um orçamento mensal;
• integrar com um sistema legado.

Uma forma simples de reconhecê-las é perguntar: essa condição limita uma escolha de tecnologia, infraestrutura, custo, prazo, operação ou conformidade?

O sistema deve integrar com o ERP atual da empresa porque o processo financeiro continuará centralizado nele.

Essa restrição reduz as opções da solução. Mesmo que exista uma alternativa tecnicamente melhor, o projeto precisa conviver com o sistema atual.

Outro exemplo seria exigir que os dados permaneçam armazenados em servidores localizados no Brasil. A origem pode ser legal, contratual ou organizacional, mas o efeito é o mesmo: limitar decisões de infraestrutura.

A diferença entre requisito não funcional e restrição pode parecer pequena.

Um requisito não funcional define um resultado ou qualidade esperada:

O serviço deve permanecer disponível durante 99,9% do mês.

Já uma restrição limita como a solução pode ser construída:

O serviço deve ser executado na infraestrutura AWS já contratada pela empresa.

O primeiro define qualidade. O segundo reduz opções.

Quando o tema não define a categoria

Dados, segurança, integração, conformidade, acessibilidade e domínio costumam ganhar tratamento próprio na documentação. Isso organiza a leitura, mas cria uma armadilha: o assunto passa a parecer uma categoria.

Muitos desses recortes detalham requisitos não funcionais, como desempenho, disponibilidade, confiabilidade, observabilidade e manutenibilidade. Outros descrevem comportamento, política do negócio ou limite imposto ao projeto. O assunto é o mesmo. A natureza da necessidade, não.

Segurança deixa isso evidente. Quatro frases do mesmo tema, quatro categorias diferentes:

• bloquear a conta após cinco tentativas descreve um comportamento funcional;
• liberar acesso a dados de folha apenas com aprovação do gestor é uma regra de negócio;
• criptografar dados em repouso define um requisito não funcional;
• usar obrigatoriamente o provedor de identidade corporativo representa uma restrição.

O objetivo não é encontrar uma etiqueta perfeita, mas deixar cada necessidade, regra e limite claro, validado e visível para quem vai decidir, construir e testar a solução.

Da necessidade ao requisito

Transformar uma necessidade em requisito não é preencher um documento seguindo uma linha reta.

O time descobre informações, analisa conflitos, registra o entendimento e valida com as pessoas envolvidas. Quando uma dúvida aparece, o processo volta algumas etapas. Na prática, elicitação, análise, especificação e validação acontecem de forma iterativa.

Vamos usar o mesmo pedido como fio condutor:

Quero que o usuário consiga cancelar uma assinatura.

1. Contexto

Antes de discutir tela ou endpoint, é preciso entender qual problema existe e por que vale resolvê-lo. Nesse caso, o objetivo pode ser reduzir chamados no suporte, dar mais autonomia ao cliente e diminuir o tempo de atendimento.

Sem contexto, o time corre o risco de entregar um botão de cancelamento que parece correto, mas não resolve a dor que motivou a mudança.

2. Elicitação

Elicitação é o trabalho de descobrir o que ainda não está claro. Isso pode acontecer em conversas, entrevistas, análise de dados, observação do processo, workshops ou protótipos.

Para o cancelamento, as perguntas começam a aparecer:

• o cliente pode cancelar a qualquer momento?
• o acesso termina imediatamente ou continua até o fim do período pago?
• existe reembolso ou apenas cancelamento da próxima renovação?
• o suporte também pode cancelar?
• é preciso registrar histórico e enviar confirmação?

3. Análise

Analisar é transformar respostas soltas em uma decisão coerente. É onde conflitos ficam visíveis: o cliente quer poucas etapas, o financeiro quer evitar reembolso indevido e o suporte precisa consultar o histórico.

Nesse caso, o negócio pode definir que o cancelamento interrompe apenas a próxima renovação, mantém o acesso até o fim do período pago e não gera reembolso automático. Essas decisões viram regras que a solução precisa respeitar.

4. Especificação

Especificar é registrar o entendimento de uma forma clara o suficiente para orientar construção e testes.

O cliente pode cancelar a renovação automática de uma assinatura ativa a qualquer momento.

Após o cancelamento, o acesso deve permanecer disponível até o fim do período já pago. O sistema deve registrar a data e o responsável pela ação e enviar um e-mail de confirmação ao cliente.

Do vago ao verificável

Registrar um requisito não é escrever mais. É escrever de um jeito que negócio, desenvolvimento e testes consigam interpretar da mesma forma.

5. Validação

Validar é confirmar se o requisito representa o que negócio, usuários e áreas afetadas realmente precisam. No exemplo, vale confirmar a política de acesso, a ausência de reembolso automático, o histórico necessário para suporte e se o comportamento pode ser testado.

As respostas não devem ser inventadas pelo desenvolvimento. Um requisito só fica completo quando o entendimento é validado por quem conhece o produto, o processo e as regras do negócio.

IA pode ajudar a resumir conversas, encontrar ambiguidades e sugerir perguntas ou critérios de aceitação. Mas ela não conhece sozinha o contexto da empresa nem decide qual política o negócio deve adotar.

Quando a validação revela uma decisão diferente da que foi registrada, o requisito volta para análise ou especificação. É por isso que as etapas não formam uma fila. Refazer aqui custa uma conversa. Descobrir depois da implementação custa retrabalho.

Requisitos e arquitetura

Arquitetura deveria nascer dos requisitos, não do gosto por tecnologia. É o requisito que torna uma decisão necessária e permite avaliar se o custo e a complexidade dela fazem sentido.

Na maioria das vezes, quem empurra uma decisão de arquitetura não é o requisito funcional. Dois sistemas podem cancelar assinaturas exatamente do mesmo jeito e ainda assim ter arquiteturas muito diferentes. O que separa os dois é a qualidade exigida: quanto a resposta pode demorar, quanto tempo o sistema pode ficar indisponível, quanto histórico precisa ser preservado.

Repare que a coluna da esquerda ainda está vaga. “Baixa latência” não decide nada sozinha: responder em 2 segundos e responder em 200 milissegundos levam a arquiteturas diferentes, com custos diferentes. O requisito só orienta a decisão depois de virar número.

Cada peça acrescentada também cobra alguma coisa. Cache cobra invalidação e risco de dado velho. Fila cobra ordenação, reprocessamento e mais um ponto de falha. Réplica cobra sincronização. O ganho costuma aparecer rápido, e a conta chega na operação.

Antes de perguntar se precisa de cache, fila, microsserviço ou banco separado, precisamos entender qual requisito torna essa decisão necessária. Uma forma de checar é inverter a pergunta: se essa peça sair, qual requisito deixa de ser atendido? Quando ninguém consegue responder, ela entrou por gosto.

Quando os requisitos mudam

Requisitos mudam porque o time aprende mais sobre o problema, o negócio muda de direção ou a operação mostra limites que não apareciam no início. Isso é normal.

Quase todo time já viu um pedido pequeno mexer em muito mais coisa do que parecia. O problema não é a mudança em si. É aceitá-la sem avaliar o que ela afeta: regras de negócio, integrações, dados, decisões de arquitetura, critérios de aceitação e testes.

Quando a mudança fizer sentido, atualize o requisito, os critérios e os testes relacionados. Também vale preservar o motivo das decisões importantes e manter rastreabilidade suficiente entre necessidade, requisito, implementação e validação.

Documentação não precisa virar uma matriz enorme para ser útil. Ela só precisa continuar refletindo o que o time decidiu construir e por quê.

Antes de fechar, cinco perguntas rápidas sobre tipos, regras, limites e o efeito deles na arquitetura:

Conclusão

Engenharia de requisitos não é burocracia. É reduzir incerteza antes que ela vire código, retrabalho e decisão técnica errada.

O trabalho começa entendendo o problema, passa por necessidades, regras e limites, e termina em requisitos claros o suficiente para orientar construção, validação e evolução.

Quando isso acontece, arquitetura e System Design deixam de ser chute. Passam a ser consequência do que o negócio e a operação realmente precisam.

Agora abra o último requisito que o seu time escreveu e tente subir: ele chega a um resultado de negócio? Se a resposta não vier rápido, você achou uma conversa que precisava ter acontecido antes do código.