Levantamento de Requisitos de Software: Guia Prático

Aprenda a conduzir o levantamento de requisitos de software com objetivos, processos, regras, requisitos funcionais, qualidade e critérios de aceitação.

O que é levantamento de requisitos de software?

Levantamento de requisitos de software é o processo de compreender o problema, as pessoas, as regras, os dados e as condições de qualidade que uma solução precisa atender. O resultado não é apenas uma lista de telas: é um entendimento verificável sobre por que o produto existe, o que está dentro do escopo, como deve se comportar e quais limites não pode ultrapassar.

Esse trabalho também é chamado de elicitação ou descoberta de requisitos. Ele combina entrevistas, observação do processo, análise de sistemas existentes, workshops, protótipos e validação. A documentação pode ser enxuta ou formal conforme o risco, mas precisa ser suficiente para que negócio, design, tecnologia e qualidade tomem decisões coerentes.

O SWEBOK v4.0a mantém requisitos de software entre as áreas centrais da engenharia de software. Na prática, investir nessa clareza reduz discussões tardias sobre algo que nunca foi combinado e evita construir corretamente a solução errada.

Requisito não é pedido de funcionalidade

“Preciso de um dashboard” é uma solicitação, não um requisito completo. Antes de desenhar o painel, pergunte qual decisão ele apoia, quais indicadores são confiáveis, quem pode acessá-los, com que atualização e o que acontece quando os dados estão incompletos.

Uma boa formulação conecta cinco elementos:

objetivo: qual resultado precisa mudar;
ator: quem executa ou recebe o comportamento;
condição: em qual contexto;
comportamento esperado: o que o sistema deve fazer;
evidência: como confirmar que foi atendido.

O levantamento não serve para transformar toda conversa em especificação rígida. Serve para tornar hipóteses, dependências e dúvidas visíveis antes que se convertam em código e custo de mudança.

Quando fazer o levantamento de requisitos?

Ele é necessário ao criar um produto, substituir planilhas, modernizar um legado, integrar sistemas ou evoluir uma função crítica. Também deve ser retomado quando processos, leis, riscos, volume ou estratégia mudam.

Em uma iniciativa de software sob medida, o levantamento orienta arquitetura, experiência, estimativa e sequência de entregas. Quando o problema ainda não está delimitado ou envolve vários sistemas e riscos, um assessment de TI pode organizar o cenário antes da especificação do produto.

Não espere descobrir absolutamente tudo para começar. Em contextos incertos, detalhe primeiro o que sustenta a decisão imediata e mantenha uma lista explícita de questões abertas. A profundidade deve acompanhar criticidade e proximidade da implementação.

Quem deve participar?

Requisitos não pertencem apenas à área solicitante ou ao time técnico. Convide representantes que conheçam:

objetivo e prioridade do negócio;
execução diária e exceções do processo;
clientes ou usuários finais;
dados e indicadores;
segurança, privacidade e conformidade;
integrações e sistemas legados;
suporte, operação e continuidade;
restrições de orçamento e prazo.

A participação não precisa ocorrer em todas as reuniões. Crie uma matriz simples: quem decide, quem fornece informação, quem valida e quem precisa ser informado. Se duas áreas disputam a mesma regra, registre o conflito e o responsável pela decisão; não deixe o desenvolvedor escolher silenciosamente.

Como fazer o levantamento de requisitos de software

1. Defina o problema e o resultado esperado

Comece pelo contexto, não pela solução sugerida. Documente:

situação atual e impacto observado;
público afetado;
resultado que justificaria o investimento;
indicadores disponíveis;
restrições conhecidas;
itens explicitamente fora do escopo.

Compare “automatizar aprovações” com “reduzir solicitações paradas sem responsável e manter evidência de cada decisão”. A segunda formulação oferece direção sem impor uma tecnologia prematuramente.

2. Mapeie o processo atual e suas exceções

Observe como o trabalho acontece, não apenas como o procedimento diz que deveria acontecer. Acompanhe uma solicitação real do início ao fim, incluindo esperas, planilhas auxiliares, mensagens, retrabalho e decisões manuais.

Registre o caminho comum e exceções: dado ausente, aprovação recusada, usuário sem acesso, integração indisponível, prazo vencido, duplicidade e cancelamento. Muitos defeitos surgem porque o requisito descreveu apenas o “caminho feliz”.

3. Identifique atores, permissões e responsabilidades

Liste pessoas, sistemas e serviços externos que interagem com a solução. Para cada papel, responda o que pode consultar, criar, alterar, aprovar, exportar e excluir.

Evite perfis genéricos como “administrador” sem limite. Separe administração técnica, gestão do processo, auditoria e uso operacional quando houver conflito de interesse. Inclua contas de serviço e integrações, não apenas usuários humanos.

4. Especifique requisitos funcionais

Requisitos funcionais descrevem comportamentos observáveis. Exemplos:

ao receber uma solicitação completa, o sistema deve encaminhá-la ao aprovador definido pela unidade;
quando uma aprovação for recusada, o solicitante deve receber o motivo e poder corrigir os campos permitidos;
o sistema deve impedir o envio do mesmo documento para o mesmo período e unidade.

Escreva regras junto ao comportamento. “Permitir cadastro” não esclarece campos obrigatórios, unicidade, validação, estados ou efeitos posteriores.

Histórias de usuário, casos de uso e fluxos são formatos possíveis. Escolha o que melhor comunica o risco. Uma frase curta pode bastar para uma alteração simples; um processo financeiro pode exigir estados, tabela de regras e exemplos.

5. Modele dados e integrações

Identifique entidades, origem, responsável, sensibilidade, qualidade e ciclo de vida. Pergunte:

qual sistema é a fonte de verdade;
quais identificadores permanecem estáveis;
que histórico precisa ser preservado;
como corrigir e excluir;
quais dados pessoais são realmente necessários;
quais relatórios e auditorias dependem deles.

Para integrações, defina direção, eventos, frequência, autenticação, volume, limites, idempotência, indisponibilidade e reconciliação. O guia de integração de sistemas via API aprofunda esses contratos.

6. Transforme qualidade em requisitos mensuráveis

Requisitos não funcionais descrevem condições de qualidade e operação. “O sistema deve ser rápido, seguro e fácil” não pode ser testado. Substitua adjetivos por contexto e medida:

95% das consultas críticas devem responder em até dois segundos, na carga e no ambiente definidos;
uma falha de zona não deve causar perda de pedidos confirmados;
ações de aprovação devem registrar ator, horário, decisão e identificador de correlação;
a recuperação deve respeitar objetivos acordados de tempo e perda de dados.

A ISO/IEC 25010:2023 oferece um modelo de qualidade para especificar e avaliar propriedades de produtos de software. Use-o como roteiro para perguntar sobre adequação funcional, desempenho, compatibilidade, confiabilidade, segurança, usabilidade, manutenibilidade e outras características relevantes — não como checklist aplicado sem contexto.

7. Inclua segurança, privacidade e acessibilidade

Segurança não deve aparecer somente na revisão final. O NIST Secure Software Development Framework recomenda documentar requisitos de segurança e acompanhar requisitos, riscos e decisões de design durante o desenvolvimento.

Defina classificação dos dados, autenticação, autorização, segregação, retenção, auditoria, proteção de segredos e resposta a abuso. Para aplicações web, o OWASP ASVS fornece requisitos verificáveis que podem apoiar especificação, desenvolvimento e contratação.

Acessibilidade também precisa ser testável. A WCAG 2.2 apresenta critérios de sucesso independentes de tecnologia. Em uma frente de UX/UI design, protótipos devem validar conteúdo, navegação, teclado, foco, mensagens de erro e diferentes formas de interação — não apenas aparência.

8. Escreva critérios de aceitação

Critérios de aceitação delimitam exemplos verificáveis. Para o requisito “recuperar senha”, considere:

usuário existente solicita recuperação sem revelar se o e-mail está cadastrado;
link possui validade e uso único;
senha anterior deixa de funcionar após a alteração;
tentativas excessivas recebem proteção;
evento relevante é auditado sem registrar o segredo.

Inclua casos válidos, limites e falhas. O critério deve permitir que negócio e qualidade reconheçam o comportamento correto sem depender de interpretação posterior.

9. Priorize por valor, risco e dependência

“Tudo é prioridade” impede qualquer planejamento. Classifique itens por:

contribuição ao objetivo;
risco legal, operacional ou de segurança;
frequência e quantidade de usuários;
dependências técnicas ou de dados;
custo de adiar;
incerteza que precisa de experimento.

Separe o mínimo necessário para validar a hipótese do que pertence à operação completa. O artigo sobre software sob medida ou sistema pronto ajuda a decidir quando requisitos diferenciadores justificam desenvolvimento.

10. Valide com exemplos e protótipos

Reúna participantes para percorrer cenários reais. Use protótipos navegáveis, amostras de dados, diagramas, tabelas de decisão e contratos de API conforme a dúvida.

Protótipo valida fluxo e compreensão, mas não prova desempenho, segurança ou viabilidade de integração. Para incertezas técnicas, faça uma prova de conceito com hipótese e critério de saída. Não confunda um protótipo descartável com produto pronto.

Técnicas de elicitação e quando usar

Entrevista: aprofunda objetivos, decisões e exceções com especialistas.
Observação contextual: revela atalhos e dificuldades que a descrição formal omite.
Workshop: resolve divergências entre áreas e modela processos em conjunto.
Análise documental: identifica regras em contratos, normas, manuais e relatórios.
Análise do sistema atual: encontra dados, integrações, uso e comportamentos herdados.
Questionário: alcança muitos participantes, mas raramente substitui aprofundamento.
Protótipo: testa compreensão de jornada, conteúdo e interação.
Prova de conceito: reduz incerteza técnica específica.

Combine técnicas. Entrevistar apenas gestores pode ignorar exceções operacionais; observar apenas usuários atuais pode limitar a solução ao processo existente.

Como documentar sem criar burocracia

Um pacote proporcional pode conter:

visão do problema, objetivo e indicadores;
escopo e itens excluídos;
glossário;
stakeholders, atores e permissões;
mapa do processo e estados;
requisitos funcionais;
atributos de qualidade;
modelo de dados e integrações;
regras de negócio e tabelas de decisão;
protótipos;
critérios de aceitação;
riscos, dependências e perguntas abertas;
prioridades e registro de decisões.

Cada requisito deve ter identificador, fonte, estado, prioridade, responsável pela validação e vínculos com critérios e testes quando o risco justificar. Evite documentos duplicados que divergem. Defina uma fonte oficial e mantenha histórico de alterações.

Modelo enxuto de requisito

Use esta estrutura como ponto de partida:

ID e nome: identificação estável;
objetivo relacionado: por que existe;
ator e contexto: quem e quando;
comportamento ou regra: o que deve ocorrer;
dados: entradas, saídas e restrições;
critérios de aceitação: exemplos verificáveis;
qualidade e segurança: limites aplicáveis;
dependências: sistemas, decisões e outros requisitos;
prioridade e status: sequência e maturidade;
questões abertas: incertezas ainda não resolvidas.

O modelo é uma ferramenta, não um fim. Se um campo não melhora entendimento, decisão ou teste, avalie removê-lo.

Requisitos mudam: controle sem congelar o produto

Mudança não significa falha. O problema é alterar escopo sem compreender impacto. Registre a origem da mudança, requisitos afetados, custo, risco, dependências e decisão.

O Scrum Guide descreve o Product Backlog como uma lista emergente e ordenada do que é necessário para melhorar o produto. Mesmo fora do Scrum, a ideia é útil: detalhe itens conforme se aproximam da entrega e revise prioridades com evidências. Isso não elimina arquitetura, qualidade ou rastreabilidade; adapta a profundidade ao momento.

Antes de estimar uma entrega, diferencie requisitos confirmados, hipóteses e desconhecidos. Estimativas responsáveis apresentam premissas e intervalo quando ainda existe incerteza material.

Erros comuns no levantamento de requisitos

começar pela tecnologia ou por telas prontas;
ouvir apenas quem aprovou o orçamento;
copiar o processo atual sem questionar o objetivo;
ignorar exceções, estados e permissões;
escrever adjetivos em vez de medidas;
deixar dados e integrações para depois;
tratar segurança e acessibilidade como melhorias opcionais;
colocar tudo no MVP;
validar frases sem percorrer exemplos reais;
confundir protótipo com viabilidade técnica;
estimar com dúvidas críticas escondidas;
manter requisitos em documentos conflitantes;
aceitar mudança sem avaliar impacto.

Checklist de levantamento de requisitos de software

Conclusão

Um bom levantamento de requisitos de software transforma necessidades dispersas em decisões compartilhadas e verificáveis. Ele não promete eliminar mudanças; cria contexto para mudar com menos desperdício e risco.

Comece pelo resultado, observe o processo real, modele exceções, torne qualidade mensurável e valide com exemplos. Se sua empresa precisa estruturar um produto digital ou modernizar um sistema existente, converse com a Mattos Tech Solutions.