Como escrever requisitos de software sem ser programador

O diretor manda para três fornecedores a mesma mensagem: "precisamos de um sistema para controlar pedidos, com cadastro de clientes, estoque, relatórios e acesso pelo celular". Volta uma proposta enxuta, outra três vezes maior e uma terceira cheia de perguntas. Nenhuma dá para comparar com as outras, porque cada fornecedor imaginou um sistema diferente a partir das mesmas duas linhas.

Meses depois, com o projeto em andamento, aparece o outro lado do problema. "Mas o pedido de cliente com crédito bloqueado tinha que ir para aprovação do financeiro." Ninguém escreveu isso. Para quem vive a operação, era óbvio. Para quem desenvolve, era invisível.

Escrever bons requisitos de software não exige saber programar nem dominar termos técnicos. Exige contar o problema, as pessoas, o processo e as regras do jeito que eles acontecem na empresa, com exemplos. Este texto mostra como fazer isso em um documento que permite comparar propostas entre si.

A resposta curta: o que um bom pedido precisa conter

Se você tem pouco tempo, um bom documento de requisitos, escrito por quem decide, cobre sete pontos:

1. O problema e o objetivo. O que dói hoje e como você vai saber que melhorou.
2. Quem usa. Os perfis de usuário, quantos são, onde trabalham e o que cada um precisa fazer.
3. O processo atual. Como o trabalho é feito hoje, passo a passo, com planilhas, papéis e sistemas envolvidos.
4. O processo desejado. O que muda com o sistema novo.
5. Regras de negócio e exceções. As condições que decidem o caminho de um pedido, de um cadastro ou de uma aprovação, sempre com exemplos reais.
6. Integrações, volumes e restrições. Com quais sistemas conversa, quanto movimento existe e quais limites não podem ser ultrapassados (prazo, legislação, infraestrutura).
7. O que fica fora. O que não faz parte deste projeto, para ninguém orçar a mais nem a menos.

Por que lista de funcionalidades não basta

O pedido mais comum é uma lista: cadastro de clientes, produtos, pedidos, relatórios, painel gerencial. Parece objetivo, mas cada item esconde dezenas de decisões.

"Cadastro de clientes" pode ser um formulário com nome e telefone ou um módulo com análise de crédito, múltiplos endereços de entrega, contatos por departamento, tabela de preço específica e histórico de negociação. "Relatórios" pode significar três telas simples ou um ambiente de análise com filtros, exportação e permissões por filial.

A lista diz o que existe, mas não por que nem como é usado, e é aí que mora o tamanho real do projeto. Sem essa informação, o fornecedor preenche a lacuna com suposições. Um supõe o mínimo para chegar a uma proposta competitiva. Outro supõe o máximo para se proteger. O resultado são propostas que não falam do mesmo sistema.

Comece pelo problema e pelo objetivo

Antes de qualquer tela ou funcionalidade, escreva um parágrafo respondendo: o que está errado hoje e o que você quer que aconteça depois?

Compare duas formas de começar:

• "Queremos um sistema de gestão de pedidos com integração ao ERP."
• "Hoje os vendedores enviam pedidos por WhatsApp, a equipe interna digita no ERP e a digitação leva até um dia. Erros de código de produto geram devoluções toda semana. Queremos que o pedido chegue ao ERP no mesmo dia, sem redigitação, e que o vendedor veja o status sem precisar ligar para o escritório."

A segunda versão diz ao fornecedor onde está o valor e abre espaço para alternativas: talvez um app para o vendedor, talvez um portal para o próprio cliente, talvez as duas coisas em fases.

Inclua também como você vai saber que deu certo, de forma verificável: "o pedido entra no ERP sem redigitação", "o fechamento do mês deixa de depender da planilha da Fulana".

Quem usa o sistema e para quê

Descreva cada perfil de usuário em poucas linhas:

• Quem é: vendedor externo, analista de crédito, separador do estoque, cliente final, gerente de filial.
• Quantos são: uma ordem de grandeza basta (cinco, cinquenta, quinhentos).
• Onde e como trabalham: no escritório com dois monitores, em campo com celular e sinal ruim, no galpão com luva, no balcão com fila.
• O que precisam fazer: as três ou quatro tarefas principais, com a frequência de cada uma.
• O que não podem ver ou fazer: o vendedor não vê a margem; o separador não altera preço.

Exemplo: "Vendedores externos, cerca de vinte, visitam clientes no interior e muitas vezes ficam sem internet. Precisam consultar estoque e preço, montar o pedido na frente do cliente e enviar quando o sinal voltar. Não podem dar desconto acima do limite da tabela sem aprovação do gerente."

Esse parágrafo já informa que o app precisa funcionar offline, que existe uma regra de alçada e que o gerente também é usuário.

Processo atual e processo desejado

Descreva o processo como ele é, não como deveria ser

Escreva o passo a passo do jeito que acontece hoje, incluindo os remendos. Se o pedido passa por uma planilha compartilhada, se alguém confere tudo à mão antes de faturar, se existe um e-mail que precisa ser enviado para liberar a carga, escreva. Esses remendos são justamente o que o sistema precisa resolver, ou pelo menos respeitar.

Um formato simples funciona bem:

Junte modelos reais: a planilha que hoje faz o trabalho do sistema, um pedido impresso, um relatório que a diretoria usa, prints das telas atuais. Documentos reais (com dados sensíveis mascarados) explicam mais do que qualquer descrição.

Descreva o processo desejado em termos de resultado

Para o processo novo, não tente desenhar telas. Descreva o que muda: "o pedido sai do celular do vendedor e cai direto no ERP"; "o financeiro recebe um aviso quando um pedido precisa de análise de crédito"; "o vendedor vê em que etapa o pedido está". O desenho das telas e do fluxo é trabalho conjunto com o fornecedor, e é melhor quando ele parte do resultado esperado.

Regras de negócio e exceções com exemplos

É aqui que a maior parte dos mal-entendidos nasce. Regra de negócio é qualquer condição que muda o comportamento do sistema: quem aprova o quê, como o preço é calculado, quando um pedido pode ser cancelado, que prazo vale para cada tipo de cliente.

Escreva a regra e um exemplo concreto

Regra sozinha é ambígua. Exemplo resolve a ambiguidade.

• Regra: "desconto acima do limite precisa de aprovação."
• Com exemplo: "a tabela permite até 5% de desconto para o vendedor. Se ele der 8%, o pedido fica pendente até o gerente regional aprovar. Se o gerente não responder até o fim do dia, o pedido continua pendente e o vendedor é avisado."

O exemplo responde perguntas que a regra deixava abertas: quem aprova, o que acontece enquanto espera, o que acontece se ninguém aprovar.

Liste as exceções que você conhece

Toda operação tem casos especiais, e eles quase nunca aparecem quando alguém descreve o fluxo "normal". Pergunte para a equipe que opera:

• Que tipo de pedido dá mais trabalho hoje?
• Que cliente tem condição diferente dos outros?
• O que acontece quando falta produto, quando o cliente muda o pedido depois de aprovado, quando a entrega volta?
• Existe algo que acontece só no fim do mês, só em determinada filial ou só em determinado estado?
• Que situação aconteceu uma vez, deu problema e hoje todo mundo lembra?

Cada resposta vira uma linha no documento, mesmo sem solução definida. Exceção conhecida no início é decisão de projeto; descoberta depois da entrega, é retrabalho.

Separe regra da empresa de regra externa

Algumas regras vêm de fora: obrigações fiscais, exigências de órgãos reguladores, cláusulas de contratos com clientes. Para essas, diga o que o sistema precisa suportar ("emitir nota fiscal eletrônica para os pedidos faturados", "guardar o histórico de alterações de cada cadastro") e indique quem valida o detalhe na empresa, normalmente o contador ou o jurídico. Não cabe ao documento de requisitos interpretar legislação.

Integrações, volumes e restrições

Integrações

Liste os sistemas com que o novo sistema precisa conversar e, para cada um, o que troca e em que sentido:

• ERP: recebe pedidos, devolve status de faturamento e estoque.
• Banco ou intermediador de pagamento: gera cobrança e confirma pagamento.
• Transportadora: recebe dados da carga, devolve rastreio.
• Planilhas ou sistemas que vão ser desligados: os dados precisam ser migrados?

Informe o que você sabe de cada sistema: nome, versão, se é nuvem ou servidor próprio, se oferece API, quem responde por ele. Sistema fechado e sem documentação é um dos maiores fatores de incerteza em uma proposta.

Volumes

Ordens de grandeza bastam: quantos pedidos por dia, quantos produtos no catálogo, quantos usuários simultâneos nos horários de pico, quanto histórico precisa ser migrado. Diga também se existem picos: fim de mês, datas comerciais, safra, início de semestre.

Restrições

São os limites que não estão em negociação:

• prazo com data fixa, como início de uma operação nova ou fim de contrato com o sistema atual;
• infraestrutura obrigatória, como manter dados em servidor próprio ou em nuvem específica;
• dados pessoais tratados e exigências de privacidade (LGPD);
• operação em locais sem internet estável;
• padrões que a TI interna exige, se existir uma.

O que deixar para o fornecedor propor

Um bom documento de requisitos não decide tudo. Algumas decisões são melhores quando ficam com quem vai construir, desde que o fornecedor justifique a escolha na proposta:

• Tecnologia: linguagem, banco de dados, framework. Peça que o fornecedor explique por que escolheu e como isso afeta manutenção futura. Um exemplo é Node.js, .NET ou Java no back-end.
• Desenho das telas: descreva o que o usuário precisa fazer, não onde fica cada botão.
• Arquitetura e hospedagem: informe as restrições e deixe a proposta resolver o resto.
• Divisão em fases: diga o que é mais urgente e peça uma sugestão de fatiamento. Se você está em dúvida sobre o que entra na primeira versão, vale ler como definir o escopo de um MVP.

Deixar essas decisões em aberto também vira critério de comparação: a qualidade das perguntas e justificativas diz muito sobre cada fornecedor. Os outros critérios para essa escolha estão em como escolher uma software house.

Passo a passo para montar o documento

1. Reúna as pessoas que operam o processo, não só os gestores. Uma conversa de uma hora com cada área rende mais do que uma semana de suposição.
2. Escreva o problema e o objetivo em um parágrafo cada.
3. Liste os perfis de usuário com quantidade, ambiente de trabalho e tarefas principais.
4. Monte a tabela do processo atual, passo a passo, com os problemas de cada etapa.
5. Descreva o processo desejado em termos de resultado.
6. Registre as regras de negócio com exemplos e a lista de exceções conhecidas.
7. Liste integrações, volumes e restrições.
8. Escreva o que fica fora deste projeto.
9. Anexe documentos reais: planilhas, relatórios, prints, formulários.
10. Marque as dúvidas abertas. "Ainda não sabemos se o cliente final vai acessar o sistema" é uma informação útil, não uma falha.

O documento não precisa ser longo nem perfeito: serve como ponto de partida para a conversa, não como contrato fechado.

Checklist antes de enviar para os fornecedores

• Alguém de fora da área entende o problema lendo só o primeiro parágrafo?
• Cada perfil de usuário tem tarefas e restrições descritas?
• Cada regra de negócio importante tem pelo menos um exemplo?
• As exceções que a equipe mais lembra estão registradas?
• Os sistemas a integrar estão identificados, com o que se sabe de cada um?
• Os volumes e os picos estão informados?
• Está claro o que fica fora deste projeto?
• Todos os fornecedores vão receber exatamente o mesmo documento?

O último item garante propostas comparáveis: se uma pergunta de um fornecedor muda o entendimento, envie a resposta para todos.

Quando o documento não basta

Há projetos em que nem a empresa tem clareza suficiente para escrever tudo isso: processos que variam por área, sistemas antigos sem documentação, decisões ainda não tomadas sobre como a operação vai funcionar. Nesses casos, o mais seguro é uma etapa curta de investigação antes de pedir proposta de desenvolvimento, conduzida junto com o fornecedor. É o que se chama de discovery de software: entrevistas, análise de sistemas e protótipos que transformam necessidades difusas em um escopo com riscos conhecidos.

Perguntas frequentes

Qual a diferença entre requisito funcional e não funcional?

Requisito funcional descreve o que o sistema faz, como registrar um pedido ou avisar o financeiro sobre uma análise de crédito. Requisito não funcional descreve condições de funcionamento, como volume de usuários, desempenho, segurança, operação sem internet e exigências da LGPD. Um bom documento de requisitos traz os dois, sem precisar usar esses nomes técnicos.

Quem deve escrever os requisitos de um sistema?

Quem decide sobre o projeto, com a participação de quem opera o processo no dia a dia. O gestor conhece o objetivo, mas são as equipes da operação que lembram das exceções, dos remendos e das regras que nunca foram escritas. O fornecedor ajuda a completar os requisitos do sistema, mas não deveria ter que adivinhá-los.

O documento de requisitos precisa ser longo e detalhado?

Não. O documento de requisitos precisa ser claro, não extenso: problema, usuários, processo, regras com exemplos, integrações, volumes e o que fica fora. Ele serve como ponto de partida para a conversa com os fornecedores, não como contrato fechado, e pode registrar dúvidas ainda abertas sem perder valor.

Preciso escolher a tecnologia antes de pedir propostas de software?

Não necessariamente. Linguagem, banco de dados, desenho das telas e arquitetura podem ficar com o fornecedor, desde que ele justifique a escolha na proposta e explique o impacto na manutenção futura. O que a empresa precisa informar são as restrições, como infraestrutura obrigatória, padrões exigidos pela TI interna e exigências de privacidade.

Como a Pervian Tech trabalha levantamento de requisitos

Na Pervian Tech, o levantamento de requisitos faz parte do trabalho de arquitetura de software. Começamos pelo problema e pelas pessoas: conversamos com quem decide e com quem opera, analisamos as planilhas e os sistemas envolvidos e registramos regras e exceções com exemplos reais. Se você já tem um documento, partimos dele e devolvemos as perguntas que ainda faltam responder.

O resultado é um escopo escrito em linguagem de negócio, com o que entra, o que fica fora, as integrações e os riscos, que serve de base para um plano sob medida. O diagnóstico inicial é gratuito, e o investimento é definido sob consulta a partir do que foi levantado. Se você precisa de um sistema e ainda está tentando colocar a necessidade no papel, conte para a gente o que está acontecendo.