Levantamento de requisitos é a etapa em que a software house descobre o que o cliente precisa, o que fica fora e o que pode dar errado, antes de dar preço. O resultado é um documento de escopo que vira anexo do contrato.
Para quem vende em escopo fechado, é o documento que decide se o projeto dá lucro. Abaixo está um roteiro em sete passos, da primeira reunião de pré-venda até o escopo assinado.
Passo 1: entenda o negócio antes do sistema
Na primeira conversa, deixe as telas para depois e pergunte sobre o negócio do cliente: quem usa, quanto dinheiro passa pelo processo, o que acontece hoje sem o sistema, qual a dor que fez o cliente procurar uma software house agora.
As respostas definem prioridade. Um cliente que perde vendas por causa de um processo manual aceita cortar funcionalidade para entrar em produção antes.
Perguntas que funcionam:
- Quem são os usuários e quantos são?
- Como o processo funciona hoje, passo a passo?
- O que acontece se o sistema não ficar pronto na data?
- Quem decide e quem assina do lado do cliente?
- Qual o orçamento previsto?
Passo 2: mapeie os usuários e os fluxos de uso
Liste os perfis de usuário e, para cada um, as tarefas principais:
- cliente final;
- operador;
- administrador;
- financeiro.
Escreva em forma de história. Isso facilita estimar e testar depois.
Passo 3: levante requisitos funcionais
Para cada fluxo, liste o que o sistema precisa fazer. Seja específico: “filtrar pedidos por data, status e cliente” é requisito. “Ter filtros” não é.
Marque cada item com prioridade:
| Prioridade | Quando o prazo aperta |
|---|---|
| Essencial | Fica |
| Importante | Fica, se der |
| Desejável | É o que você corta |
Passo 4: levante requisitos não funcionais e integrações
Esta é a parte que estoura prazo. Pergunte e escreva:
- Integrações: ERP, gateway de pagamento, emissão de nota fiscal, APIs de terceiros. Para cada uma, quem fornece acesso e documentação.
- Dados legados: existe migração? Em que formato estão os dados? Quem limpa?
- Desempenho e volume: quantos usuários simultâneos, quantos registros.
- Segurança e dados pessoais: o sistema trata dados pessoais? Quem é o controlador?
- Ambiente: onde roda, quem paga a infraestrutura, quem faz deploy.
Passo 5: desenhe um protótipo
Um protótipo navegável das telas principais acaba com metade das dúvidas. O cliente vê o que vai receber e corrige antes de você escrever código.
| Onde muda | Quanto custa |
|---|---|
| No protótipo | Minutos |
| No sistema pronto | Uma sprint |
Passo 6: escreva o documento de escopo
O documento junta tudo:
- Objetivo do projeto, em uma frase.
- Perfis de usuário e fluxos de uso.
- Requisitos funcionais com prioridade.
- Requisitos não funcionais e integrações.
- Fora do escopo: a lista do que não está incluído. É a seção mais importante para o escopo fechado.
- Premissas: o que o cliente fornece (acessos, conteúdo, dados) e até quando.
- Critérios de aceite de cada entrega.
- Protótipo como anexo.
Passo 7: valide e assine
- Repasse o documento com o cliente item por item.
- Peça assinatura ou aceite formal por e-mail.
- Só depois dê o preço final.
Com o escopo fechado e assinado, calcular o preço fica mais simples. Veja quanto cobrar por um sistema.
Erros comuns na pré-venda
- Dar preço na primeira reunião. O cliente ancora no número e você fica preso a ele.
- Ignorar integrações. “É só puxar do ERP” já custou muito projeto.
- Não escrever o fora do escopo. Se não está escrito que relatório customizado está fora, o cliente vai pedir.
- Levantamento grátis demais. Três semanas de análise sem contrato é consultoria de graça.
O que o levantamento tem a ver com o seu código
O documento de escopo também serve para separar o que é sob medida do que você já tem pronto.