Módulo 07 — Técnicas de Levantamento de Requisitos (entrevista, observação)

Onde estamos. No módulo anterior discutimos o que são requisitos e por que a especificação é a atividade que mais determina o sucesso ou o fracasso de um sistema. Agora vamos descer um degrau e olhar para a parte mais artesanal e humana desse trabalho: como, na prática, se descobre o que um sistema deve fazer. Quero que você chegue à aula sabendo que elicitação não é receber uma lista pronta de um cliente, e sim uma investigação conduzida com método, técnica e um bom tanto de escuta.

Deixe-me começar com uma provocação honesta. É tentador imaginar que levantar requisitos seja apenas perguntar ao cliente o que ele quer e anotar. Se fosse assim, não precisaríamos de um módulo inteiro. O problema é que, quase sempre, o cliente não sabe exatamente o que quer, não consegue verbalizar o que já sabe, descreve o trabalho de um jeito diferente de como ele acontece, e muda de ideia ao longo do caminho. A elicitação é a disciplina de contornar todas essas dificuldades ao mesmo tempo, misturando técnicas de conversa, de observação e de análise, cada uma boa para revelar um tipo diferente de verdade. Vamos percorrer essas técnicas uma a uma, entendendo a força, a limitação e o momento certo de cada uma.

O que é elicitação e por que ela é difícil

Vale começar pelo nome. Usamos “elicitação” — do latim elicere, extrair — em vez de “coleta” de propósito. Coletar sugere que os requisitos já existem prontos, esperando ser recolhidos. Elicitar reconhece a verdade mais dura: boa parte dos requisitos ainda não existe de forma explícita quando começamos. Eles estão dispersos na cabeça de várias pessoas, embutidos em rotinas que ninguém escreveu, escondidos em planilhas informais e, com frequência, em contradição entre si. O trabalho é fazê-los emergir, dar-lhes forma e reconciliá-los.

Sommerville organiza os problemas centrais dessa atividade de um modo que quero que você memorize, porque cada técnica adiante é uma resposta a um deles. Os stakeholders muitas vezes não sabem o que realmente querem, ou pedem coisas irreais. Eles expressam requisitos com termos e conhecimento implícito do domínio, que o analista pode não compartilhar. Diferentes stakeholders têm requisitos conflitantes. Fatores políticos internos influenciam o que é pedido. E o ambiente de negócio é dinâmico, de modo que os requisitos mudam durante a própria análise — surgem novos stakeholders, e as prioridades se alteram.

A ideia central que você deve carregar

Elicitação não é transcrição. É investigação. O analista de requisitos se parece mais com um jornalista investigativo ou um antropólogo do que com um estenógrafo: ele cruza fontes, desconfia de respostas fáceis, observa o que as pessoas fazem além do que dizem, e reconstrói uma compreensão do domínio que nem os próprios usuários possuíam de forma articulada.

Um mapa das técnicas

Antes de detalhar cada técnica, quero lhe dar uma visão de conjunto. Nenhuma técnica isolada revela tudo. Entrevistas capturam o que as pessoas sabem e conseguem dizer; observação captura o que elas fazem sem perceber; a análise de documentos captura o já formalizado; a prototipagem captura o que só aparece quando há algo concreto para reagir. Boa elicitação combina várias fontes de propósito, prática que chamamos de triangulação: quando dois métodos independentes apontam para a mesma conclusão, a confiança aumenta; quando divergem, encontramos exatamente a ambiguidade que precisamos resolver.

flowchart TB
    subgraph Fontes
      E[Entrevistas]
      O[Observação / Etnografia]
      D[Análise de documentos]
      Q[Questionários]
    end
    E --> T{Triangulação}
    O --> T
    D --> T
    Q --> T
    T -->|convergência| C[Requisito confiável]
    T -->|divergência| A[Ambiguidade a investigar]
    A -.-> E
    style T fill:#fff3cd,stroke:#664d03,stroke-width:2px
    style C fill:#d1e7dd,stroke:#0f5132
    style A fill:#f8d7da,stroke:#842029

Repare que o diagrama não termina no requisito confiável. A divergência realimenta o processo, empurrando o analista de volta às fontes com uma pergunta mais afiada. Isso é o coração da elicitação: cada rodada de investigação torna a próxima mais precisa.

Entrevistas: a técnica central

A entrevista é a técnica mais usada e, quando bem conduzida, uma das mais produtivas. Ela consiste em conversar com stakeholders para entender suas necessidades, seu vocabulário e sua visão do sistema. Sommerville distingue dois formatos que você deve dominar. As entrevistas fechadas seguem um roteiro de perguntas predefinidas; garantem que certos pontos sejam cobertos e facilitam a comparação entre respostas, mas correm o risco de não capturar o que o entrevistador não pensou em perguntar. As entrevistas abertas não têm agenda fixa: o analista explora as questões que emergem, deixando a conversa revelar aspectos inesperados do domínio. Na prática, a boa entrevista é um híbrido — começa aberta, para o entrevistado mostrar o território, e vai fechando à medida que o analista sabe o que perguntar.

Boas práticas para conduzir uma entrevista

Prepare-se estudando o domínio antes, para não gastar o tempo do entrevistado com o básico. Comece com perguntas abertas e específicas, como “descreva como você faz X hoje”, em vez de perguntas fechadas que só admitem sim ou não. Não sugira respostas nem induza o entrevistado à solução que você já imaginou. Peça exemplos concretos e casos reais, porque o abstrato esconde exceções. Registre com cuidado e valide depois o que entendeu, devolvendo ao entrevistado um resumo para confirmação.

As armadilhas são igualmente importantes. A primeira é o viés de confirmação do analista, que ouve o que confirma sua ideia prévia de solução e filtra o resto. A segunda é o conhecimento tácito: especialistas frequentemente sabem fazer algo tão bem que não conseguem mais explicar como fazem, tratando como óbvio aquilo que é o requisito mais importante. A terceira é o poder da sugestão — se você pergunta “vocês vão querer um relatório mensal, certo?”, quase sempre ouve um sim que não significa nada. E há uma armadilha estrutural: entrevistas são péssimas para requisitos que envolvem a organização como um todo, porque cada entrevistado enxerga apenas o próprio pedaço. Pressman lembra que o entrevistador precisa de habilidade social tanto quanto técnica; uma entrevista é uma relação, e relações mal conduzidas produzem informação ruim.

Questionários: alcance amplo, profundidade rasa

Quando você precisa ouvir muitas pessoas — dezenas ou centenas de usuários espalhados — a entrevista individual não escala. O questionário resolve o alcance: com um conjunto fixo de perguntas, você atinge um público grande a custo baixo e obtém dados até tratáveis quantitativamente. É a técnica certa para medir a frequência de um comportamento, aferir preferências entre opções conhecidas ou validar em larga escala uma hipótese levantada por outro meio.

As limitações, porém, são sérias. O questionário só pergunta o que você já pensou em perguntar, então é cego para o inesperado — justamente o que mais interessa no início. Perguntas mal formuladas produzem respostas ambíguas sem que você possa pedir esclarecimento, e não há como aprofundar uma resposta interessante nem perceber a hesitação que numa conversa revelaria um problema. Por isso o questionário raramente funciona como técnica de partida; ele brilha como complemento, para confirmar em escala o que a entrevista e a observação sugeriram em profundidade.

Observação direta e etnografia: o trabalho real, não o declarado

Aqui está, para mim, a técnica mais reveladora e a mais subestimada. Existe uma diferença sistemática entre o trabalho que as pessoas descrevem e o trabalho que elas realmente fazem. Não por má-fé: quando descrevemos nossa rotina, contamos a versão idealizada, o processo oficial, esquecendo os atalhos, as exceções e as adaptações informais que na verdade sustentam a operação. Só que são justamente esses atalhos e exceções que um sistema mal projetado destrói, gerando a temida resistência dos usuários.

A observação direta consiste em acompanhar as pessoas enquanto trabalham, vendo com os próprios olhos o que acontece. A etnografia, técnica tomada emprestada da antropologia, aprofunda isso: o analista imerge no ambiente de trabalho por um período, participando do cotidiano, para compreender a cultura, as práticas sociais e o conhecimento implícito que estruturam a atividade. Sommerville a valoriza para revelar dois tipos de requisito que nenhuma entrevista captura: os que decorrem da forma como as pessoas de fato fazem o trabalho, em oposição à forma como os processos formais dizem que deveriam, e os que decorrem da cooperação e do conhecimento compartilhado entre as pessoas.

Por que observar muda tudo

Um operador entrevistado dirá que “confere o pedido no sistema e aprova”. Observando-o, você descobre que ele mantém uma planilha paralela porque o sistema não mostra um dado de que precisa, telefona para o depósito para confirmar o estoque real, e só então aprova. Os três passos reais — a planilha, o telefonema, a desconfiança do estoque — são requisitos verdadeiros que jamais apareceriam numa conversa. O trabalho declarado é uma abstração; o trabalho observado é o sistema.

A limitação da observação é o custo em tempo e a possibilidade de o observado alterar o comportamento por se saber observado. Além disso, ela é excelente para entender o presente e fraca para revelar o que o sistema deveria passar a fazer de novo — ninguém observa um requisito que ainda não existe. Por isso a combinamos com entrevistas, que projetam o futuro, e com prototipagem.

Workshops, sessões conjuntas e brainstorming

Nem toda elicitação é um a um. Quando há muitos stakeholders com visões parciais e conflitantes, reuni-los numa mesma sala pode produzir, em pouco tempo, o que semanas de entrevistas separadas não produziriam. Os workshops de requisitos — Pressman descreve variantes reunidas sob a ideia de reuniões estruturadas e colaborativas de análise — juntam clientes, usuários e desenvolvedores sob um facilitador neutro, com regras de participação e uma pauta preparada, para construir de forma negociada um entendimento comum. A força é resolver conflitos na hora, com todos presentes, em vez de descobri-los tarde demais. A exigência é facilitação competente: sem alguém que contenha o participante dominante e traga à tona o silencioso, o workshop vira a reunião mais barulhenta ganhando.

O brainstorming costuma ser uma etapa dentro desses encontros. Sua regra de ouro é separar a geração de ideias da avaliação: primeiro se produz o maior número de ideias sem crítica, para não inibir a criatividade, e só depois se filtram e priorizam. É poderoso para destravar requisitos que ninguém havia imaginado, e fraco para produzir precisão — o que sai dele é matéria-prima que outras técnicas precisam refinar.

Análise de documentos e de sistemas legados

Antes de perguntar às pessoas, muitas vezes vale ler o que a organização já escreveu sobre si mesma. Formulários, manuais, relatórios, regulamentos, contratos e normas carregam requisitos já formalizados, definições de termos do domínio e regras de negócio que ninguém lembraria de mencionar numa conversa. A análise de documentos é barata, não consome o tempo dos stakeholders e ancora o vocabulário do analista no da organização. Seu risco é a defasagem: documentos envelhecem, e o processo escrito pode não corresponder mais ao praticado — mais um motivo para triangular com observação.

O caso especial e frequentíssimo é o sistema legado. Quando o novo software vai substituir um antigo, esse sistema é, ele próprio, a especificação mais completa e menos ambígua que existe, porque codifica anos de regras de negócio que sobreviveram ao uso real. O problema é que essa especificação está escrita em código, muitas vezes sem documentação, e extraí-la exige engenharia reversa e conversa com quem o mantém. Ignorar o legado é a causa clássica de um sistema novo que “esqueceu” uma regra que todos consideravam óbvia demais para mencionar.

Técnica	Força principal	Limitação principal	Quando usar
Entrevista aberta	Revela o inesperado, explora o domínio em profundidade	Não escala; depende da habilidade do analista; sofre com conhecimento tácito	Início da elicitação, para mapear o território
Entrevista fechada	Cobre pontos definidos; permite comparar respostas	Cega para o que não foi previsto	Quando já se sabe o que perguntar e se quer confirmar
Questionário	Alcança muitas pessoas a baixo custo; dado quantificável	Superficial; sem aprofundamento; sensível à formulação	Validar hipóteses em larga escala; medir frequências
Observação / etnografia	Mostra o trabalho real e o conhecimento tácito	Cara em tempo; foca no presente; efeito do observador	Domínios complexos onde o dito difere do feito
Workshop / sessão conjunta	Resolve conflitos com todos presentes; constrói consenso	Exige facilitação forte; risco de dominância	Muitos stakeholders com visões divergentes
Brainstorming	Gera ideias novas; destrava o inimaginado	Produz matéria bruta, não requisitos precisos	Fase criativa, exploração de possibilidades
Análise de documentos	Barata; ancora vocabulário; regras já formalizadas	Documentos defasados em relação à prática	Preparação inicial; entender regras e domínio
Prototipagem	Torna o abstrato tangível; revela o requisito latente	Custo de construir; risco de fixar em detalhes de tela	Requisitos incertos, de interface ou de fluxo

Prototipagem como técnica de elicitação

Guardei a prototipagem para depois da tabela porque ela ocupa um lugar peculiar. Um protótipo é uma versão preliminar e descartável do sistema, feita não para ser entregue, mas para provocar reação. E aqui está sua genialidade como técnica de elicitação: pessoas que não conseguem dizer o que querem no abstrato quase sempre conseguem dizer o que está errado quando têm algo concreto na frente. O protótipo transforma a pergunta impossível “o que você quer?” na pergunta respondível “isto que fiz está certo?”, materializando o requisito latente, aquele que só se torna consciente quando confrontado com uma proposta.

O fluxo geral da elicitação, integrando prototipagem, costuma ter esta forma cíclica, que quero que você visualize:

flowchart LR
    A[Identificar stakeholders] --> B[Compreender o domínio]
    B --> C[Coletar requisitos brutos]
    C --> D[Prototipar / representar]
    D --> E[Validar com stakeholders]
    E -->|ajustes| C
    E -->|estável| F[Requisitos consolidados]
    style B fill:#cfe2ff,stroke:#084298
    style D fill:#e2d9f3,stroke:#59359a
    style E fill:#fff3cd,stroke:#664d03
    style F fill:#d1e7dd,stroke:#0f5132

O ciclo não é um defeito a ser corrigido; é a natureza da atividade. Cada volta refina o entendimento, e a espiral só se fecha quando os stakeholders param de trazer surpresas.

Os desafios que atravessam todas as técnicas

Independentemente da técnica, quatro desafios acompanham o analista o tempo todo. O primeiro é delimitar o escopo: sem uma fronteira clara do que o sistema fará e do que não fará, a elicitação se torna infinita, porque sempre há mais uma necessidade adjacente que alguém gostaria de incluir. O segundo é entender o domínio: você não elicita bem aquilo que não compreende, e por isso aprender o vocabulário e as regras do negócio antes de propor soluções é a condição para não coletar bobagem com precisão. O terceiro é a volatilidade: requisitos mudam durante o próprio levantamento, e tratar isso como anomalia leva à frustração — o correto é adotar técnicas que absorvam a mudança, como prototipagem e ciclos curtos de validação. O quarto, e o mais humano, é lidar com stakeholders que não sabem o que querem: aqui a resposta não é insistir na pergunta direta, e sim trocar de técnica, mostrando protótipos, observando o trabalho real e oferecendo alternativas concretas para reagir.

Uma heurística que uso sempre: quando um stakeholder não consegue responder ao que você pergunta, o problema geralmente está na técnica, não na pessoa. Perguntar de novo, mais alto, não ajuda. Mude a fonte de evidência — observe, prototipe, mostre exemplos — e a resposta que não vinha em palavras aparecerá em reações.

Do requisito elicitado à regra no código

Quero fechar mostrando por que esse cuidado importa para quem escreve código. Uma informação bem elicitada não fica solta num documento: ela vira uma regra de negócio explícita no software. Suponha que, observando o trabalho real de um setor de crédito, você descubra uma regra que ninguém declarou em entrevista — clientes inadimplentes nunca recebem aprovação automática, mesmo em valor baixo, e clientes premium têm um limite maior. Repare como esse conhecimento, extraído da observação, se converte diretamente em estrutura de código.

enum PerfilCliente { inadimplente, comum, premium }

class PoliticaDeCredito {
  static const Map<PerfilCliente, double> _limiteAutomatico = {
    PerfilCliente.inadimplente: 0.0, // regra revelada pela observação
    PerfilCliente.comum: 500.0,
    PerfilCliente.premium: 2000.0,
  };

  bool aprovaAutomaticamente(PerfilCliente perfil, double valor) {
    final limite = _limiteAutomatico[perfil] ?? 0.0;
    return valor <= limite;
  }
}

Note que a regra do inadimplente — o zero explícito — só está ali porque alguém a observou no trabalho real, não porque foi pedida. Se a elicitação tivesse se limitado à entrevista, esse zero provavelmente não existiria, e o sistema aprovaria automaticamente um crédito que a operação humana jamais aprovaria. Esse é o elo concreto entre a técnica de levantamento e a qualidade do produto: cada requisito que você deixa de eliciar é uma regra que faltará no código, e cada regra que falta é um defeito esperando para acontecer.

Síntese

Quero que você retenha três ideias desta conversa. A primeira é que elicitação é investigação, não transcrição: os requisitos raramente existem prontos, e o trabalho é fazê-los emergir de fontes que se contradizem e de pessoas que não sabem articulá-los. A segunda é que nenhuma técnica basta sozinha — entrevistas revelam o dito, a observação revela o feito, a análise de documentos revela o formalizado e a prototipagem revela o latente, e a boa prática é triangular fontes para separar o convergente do ambíguo. A terceira é que os desafios eternos da atividade — escopo, domínio, volatilidade e stakeholders indecisos — não se resolvem insistindo na mesma técnica, e sim escolhendo, para cada dificuldade, a técnica que a expõe. Chegue à aula com essas três ideias assentadas, porque sobre elas construiremos a especificação formal dos requisitos.

Para consolidar antes da aula: escolha uma tarefa que você mesmo faz com frequência e tente descrevê-la em voz alta, passo a passo, como se estivesse sendo entrevistado. Depois, faça o mesmo prestando atenção ao que você realmente faz, incluindo os atalhos e exceções. Se as duas descrições divergirem, você acabou de sentir na pele a diferença entre o trabalho declarado e o trabalho real — e por que a observação existe.