Um apanhado teórico visando aulas práticas oferecendo uma amostra abrangente e condensada do universo do levantamento de requisitos para o d...
Parte 1 — Engenharia de Requisitos: fundamentos
O que é Engenharia de Requisitos?
A Engenharia de Requisitos (ER) pode ser definida como o conjunto sistemático de atividades destinadas a descobrir, analisar, documentar e gerenciar os requisitos de um sistema de software (VAZQUEZ; SIMÕES, 2016). Ela é uma subdisciplina da Engenharia de Software e está presente em qualquer processo de desenvolvimento — do modelo cascata às metodologias ágeis —, embora sua forma de execução varie conforme a estratégia adotada.
O uso da palavra "engenharia" não é acidental. Assim como outras engenharias, a ER aplica métodos sistemáticos e repetíveis para transformar necessidades de negócio em especificações verificáveis. Segundo Vazquez e Simões (2016), a ER está intimamente ligada à aquisição e aplicação de conhecimento para a criação, o aperfeiçoamento e a implementação de soluções. Sem esse rigor, requisitos ficam vagos, ambíguos e propensos a gerar falhas em cascata ao longo do projeto causando um relevante impacto econômico para os envolvidos.
ER em diferentes estratégias de desenvolvimento
No modelo cascata, a ER ocupa uma fase dedicada no início do projeto, com o objetivo de produzir uma especificação exaustiva antes de qualquer linha de código. Já em processos iterativos, como o RUP (Rational Unified Process), ela é uma disciplina que se repete em cada iteração, com intensidade decrescente ao longo do tempo. Nos métodos ágeis — Scrum, XP, Kanban —, a ER é distribuída ao longo de todo o ciclo de vida: os requisitos são descobertos, refinados e priorizados continuamente em cerimônias como o backlog refinement e o sprint planning (FATTO, 2020). Independentemente da estratégia, a ER permanece necessária; o que muda é o quando e o quanto se detalha de cada vez (VAZQUEZ; SIMÕES, 2016).
O papel do analista de requisitos
O analista de requisitos (ou analista de negócios, ou product owner em contexto ágil) é o profissional responsável por mediar a comunicação entre o mundo do negócio e o mundo técnico. Suas atividades incluem elicitar necessidades dos stakeholders, analisar e modelar essas necessidades, especificar requisitos de forma verificável, e gerenciar mudanças ao longo do projeto. Em equipes ágeis, esse papel é frequentemente exercido pelo product owner, que acumula a responsabilidade de priorizar o backlog e garantir que cada item entregue valor ao negócio (VAZQUEZ; SIMÕES, 2016).
Parte 2 — Requisito: uma palavra, muitos significados
O termo "requisito" carrega pelo menos três significados distintos na literatura de Engenharia de Software (VAZQUEZ; SIMÕES, 2016). Como necessidade, é algo que o usuário precisa para resolver um problema ou atingir um objetivo. Como propriedade, é uma característica que o sistema deve possuir para satisfazer um contrato, padrão ou especificação. Como especificação, é a representação documentada de uma necessidade ou propriedade, em formato que permita comunicação, verificação e rastreabilidade.
Requisitos se classificam em diversas categorias. Os requisitos de negócio definem os objetivos de alto nível que justificam o projeto. Os requisitos das partes interessadas capturam o que cada grupo de stakeholders espera do sistema. Os requisitos funcionais descrevem o que o sistema deve fazer (funcionalidades), enquanto os requisitos não funcionais descrevem como o sistema deve se comportar (desempenho, segurança, usabilidade etc.). A classificação FURPS+ e a norma ISO/IEC 25010 são referências comuns para organizar requisitos não funcionais (VAZQUEZ; SIMÕES, 2016). Existem ainda os requisitos de transição, que tratam da migração do estado atual para o novo sistema, e os requisitos inversos, que definem o que o sistema não deve fazer.
Critérios de qualidade da especificação
Uma especificação de requisitos de qualidade deve ser: correta (reflete a real necessidade), completa (nada relevante foi omitido), clara (não ambígua), consistente (sem contradições internas), modificável (fácil de atualizar), priorizada, verificável (pode-se testar se foi atendida) e rastreável (cada requisito pode ser ligado à sua origem e aos artefatos que o implementam) (VAZQUEZ; SIMÕES, 2016). Esses critérios devem guiar tanto documentos extensos quanto histórias de usuário ágeis.
Parte 3 — Elicitação de requisitos: a reunião na prática
A elicitação (ou levantamento) é o processo de descobrir requisitos a partir da interação com stakeholders, da análise de documentos e da observação do ambiente de trabalho. O termo "elicitação" é preferido a "coleta" porque bons requisitos não podem ser simplesmente recolhidos — eles precisam ser extraídos, confrontados e refinados (WIKIPEDIA, 2026). As atividades da elicitação se organizam em quatro etapas: preparação, execução, documentação dos resultados e confirmação dos resultados (VAZQUEZ; SIMÕES, 2016).
Principais técnicas de elicitação
Tabela 1 — Técnicas de elicitação de requisitos
| Técnica | Descrição | Quando usar |
|---|---|---|
| Entrevista | Sessão interativa (estruturada ou não) com um ou mais stakeholders, usando perguntas abertas e fechadas. | Necessidade de profundidade; explorar conhecimento tácito e opiniões. |
| Análise de documentos | Exame de documentação existente (manuais, regulamentos, sistemas legados) para extrair requisitos antes de interagir com pessoas. | Acesso limitado a stakeholders; existe documentação prévia relevante. |
| Observação (etnografia) | Acompanhamento do trabalho real do usuário (ativa ou passiva) para identificar processos e necessidades implícitas. | Usuários não conseguem descrever completamente o que fazem. |
| Workshop (JAD) | Sessão estruturada com múltiplos stakeholders, conduzida por facilitador neutro, com anotador e controlador de tempo. | Projetos complexos que exigem consenso rápido entre áreas distintas. |
| Brainstorming | Geração livre de ideias, avaliadas depois por viabilidade e relevância. | Requisitos vagos; inovação desejada. |
| Pesquisa / questionário | Formulário com perguntas fechadas e/ou abertas distribuído a um grande número de pessoas. | Necessidade de dados quantitativos de muitos stakeholders. |
| Glossário | Construção de um vocabulário comum do domínio, eliminando ambiguidades entre equipe e cliente. | Domínios especializados com terminologia própria. |
Fonte: adaptado de Vazquez e Simões (2016, cap. 7) e Software Testing Help (2025).
Na prática moderna, essas técnicas raramente são usadas isoladamente. A entrevista é a mais comum e exige preparação cuidadosa: o analista deve elaborar um roteiro de questões, manter escuta ativa, buscar fatos e opiniões e registrar tudo de forma acessível. Vazquez e Simões (2016) recomendam que o entrevistador "vá de coração aberto" — livre de preconceitos sobre o que o sistema deveria ser.
A reunião de levantamento no contexto ágil
Nos projetos ágeis — hoje majoritários no mercado de TI — a elicitação se distribui ao longo de todo o ciclo. O product owner apresenta itens prioritários do product backlog na reunião de planejamento do sprint, e a equipe os discute até haver entendimento suficiente para iniciar o desenvolvimento. Diferentemente do cascata, não se busca detalhar tudo de uma vez; o esforço é restrito ao mínimo necessário para aquele ciclo, e requisitos futuros são refinados apenas quando se aproximam da implementação (FATTO, 2020). Ferramentas de IA, como Fireflies.ai e Otter.ai, já são usadas por cerca de 40% das empresas para transcrever sessões em tempo real e extrair itens de ação automaticamente (TECHTARGET, 2026).
Parte 4 — Análise de requisitos: especificação, verificação e validação
Especificar para documentar
A especificação é o registro formal dos requisitos em um formato que permita comunicação entre equipe e stakeholders, verificação posterior e rastreabilidade. Ela pode assumir a forma de um documento extenso (como o SRS — Software Requirements Specification) ou de artefatos ágeis mais leves (histórias de usuário com critérios de aceitação). O quando elaborar depende da estratégia: no cascata, antes do desenvolvimento; no ágil, de forma incremental durante os refinamentos. O como envolve selecionar os modelos adequados (textuais, diagramáticos ou prototípicos), aplicar os critérios de qualidade citados anteriormente e garantir que cada requisito seja verificável e rastreável (VAZQUEZ; SIMÕES, 2016).
Verificação de requisitos
A verificação responde à pergunta: "estamos construindo o produto corretamente?" — ou seja, os requisitos estão bem escritos, completos, consistentes e sem ambiguidades? Ela é realizada pela própria equipe de desenvolvimento (analistas, desenvolvedores, testadores) por meio de revisões por pares, inspeções formais e checklists. Segundo Vazquez e Simões (2016), a verificação deve acontecer em três níveis: a verificação de cada modelo individualmente e sua integração com os demais; a verificação da definição do escopo (a lista de requisitos funcionais cobre todo o escopo previsto?); e a verificação do detalhamento de cada requisito funcional (a descrição é suficiente para implementar e testar?). Técnicas úteis incluem listas de verificação (checklists), revisão cruzada entre analistas, matrizes de rastreabilidade e prototipação.
Validação de requisitos
A validação, por sua vez, responde: "estamos construindo o produto certo?" — ou seja, os requisitos realmente atendem às necessidades do cliente? A validação é feita com os stakeholders, por meio de revisões conjuntas, apresentações de protótipos, demonstrações de incrementos (como na sprint review) e testes de aceitação. É a última linha de defesa contra requisitos que estão tecnicamente corretos, mas não resolvem o problema real (VAZQUEZ; SIMÕES, 2016).
Listas de verificação (checklists)
Uma lista de verificação é um conjunto predefinido de itens que devem ser conferidos para garantir que nenhum aspecto importante foi esquecido. Na ER, checklists são aplicadas tanto na verificação (cada requisito é não ambíguo? é testável? é rastreável?) quanto na elicitação (todos os stakeholders foram consultados? requisitos não funcionais foram considerados?). Sua principal vantagem é transformar experiência acumulada em um processo repetível e menos dependente da memória individual (VAZQUEZ; SIMÕES, 2016).
Parte 5 — Técnicas de modelagem e análise
Modelagem de casos de uso
Um caso de uso é uma descrição de uma sequência de interações entre um ator (uma entidade externa ao sistema — pessoa, outro sistema ou dispositivo) e o próprio sistema para atingir um objetivo. O diagrama de casos de uso (da UML) oferece uma visão gráfica de alto nível: mostra os atores conectados aos casos de uso por linhas de associação. Outros relacionamentos incluem o <<include>> (um caso de uso sempre incorpora outro), o <<extend>> (um caso de uso opcionalmente estende outro) e a generalização entre atores ou entre casos de uso (VAZQUEZ; SIMÕES, 2016).
A especificação do caso de uso vai além do diagrama: descreve os cenários — o fluxo principal (caminho feliz), os fluxos alternativos e os fluxos de exceção. Para identificar um caso de uso, o analista deve perguntar: "Quem interage com o sistema? Quais são seus objetivos? Que valor o sistema entrega a esse ator?". Casos de uso são especialmente úteis para sistemas com interações complexas entre usuários e funcionalidades, e servem como base para derivar casos de teste (VAZQUEZ; SIMÕES, 2016).
Prototipação
A prototipação é a criação de representações visuais (parciais ou completas) do sistema antes de sua implementação definitiva, com o objetivo de validar requisitos com os usuários de forma tangível. Segundo Vazquez e Simões (2016), ela se classifica em diversos eixos. Quanto à fidelidade: protótipos de baixa fidelidade (esboços em papel, wireframes simples) são rápidos e baratos, ideais para explorar ideias iniciais; protótipos de alta fidelidade (mockups interativos, navegáveis) simulam o comportamento real e são indicados para validações mais refinadas. Quanto à permanência: protótipos descartáveis são criados exclusivamente para validar requisitos e depois abandonados; protótipos evolutivos se transformam gradualmente no sistema final.
A relação entre protótipo e caso de uso é complementar: o caso de uso descreve o "o quê" e o "porquê" de uma funcionalidade, enquanto o protótipo ilustra o "como será". Juntos, reduzem a lacuna de comunicação entre analista e usuário. A prototipação é particularmente valiosa quando os requisitos são visuais ou experienciais — situações em que o usuário não consegue articular verbalmente o que deseja, mas reconhece quando vê (VAZQUEZ; SIMÕES, 2016).
Tabela 2 — Classificações de protótipos
| Eixo | Tipo A | Tipo B |
|---|---|---|
| Fidelidade | Baixa — esboços, wireframes, post-its. Rápidos e baratos. | Alta — mockups interativos, navegáveis. Simulam comportamento real. |
| Permanência | Descartável — serve apenas para validar requisitos; depois é abandonado. | Evolutivo — evolui gradualmente até se tornar o sistema final. |
| Escopo | Horizontal — amplo, cobre muitas funcionalidades superficialmente. | Vertical — profundo, implementa poucas funcionalidades por completo. |
Fonte: adaptado de Vazquez e Simões (2016, cap. 8).
Parte 6 — Histórias de usuário na prática
A história de usuário (user story) é a menor unidade de trabalho em um framework ágil. Diferente de uma especificação técnica, ela descreve uma funcionalidade a partir da perspectiva do usuário final, usando linguagem não técnica. O conceito surgiu com Kent Beck em 1999 (Extreme Programming Explained) e desde então tornou-se o formato predominante para itens de product backlog (ATLASSIAN, 2025). Vazquez e Simões (2016) a classificam como uma técnica de análise que serve tanto para documentar requisitos de forma leve quanto para estimular a conversa entre equipe e cliente.
O critério INVEST
Uma boa história de usuário deve atender ao acrônimo INVEST, proposto por Bill Wake:
- Independente (não depende de outras para fazer sentido),
- Negociável (ponto de partida para discussão, não contrato rígido), com
- Valor (entrega benefício perceptível),
- Estimável (a equipe consegue estimar o esforço),
- Small (pequena o bastante para caber em um sprint) e
- Testável (tem critérios claros de verificação) (VAZQUEZ; SIMÕES, 2016; JUSTINMIND, 2025).
Os 3 Cs: Cartão, Conversação e Confirmação
Ron Jeffries propôs que toda história se compõe de três partes começadas com C. O Cartão é a frase curta no formato "Como um [papel], eu quero [objetivo] para que [benefício]" — breve o bastante para caber em um post-it. A Conversação são as discussões detalhadas entre equipe e stakeholders que dão vida ao cartão; é nela que os requisitos reais emergem. A Confirmação são os critérios de aceitação que definem quando a história está concluída — condições verificáveis que comprovam que a funcionalidade foi implementada corretamente (VAZQUEZ; SIMÕES, 2016; VALENTE, 2025).
Temas, épicos e histórias: a hierarquia do backlog
As histórias se organizam em uma taxonomia: temas representam grandes objetivos de negócio; cada tema se desdobra em épicos, funcionalidades amplas demais para um único sprint; e os épicos são decompostos em histórias de usuário individuais. Quando necessário, cada história pode ser dividida em tarefas técnicas (VAZQUEZ; SIMÕES, 2016; KONRAD, 2025). A técnica de dividir histórias grandes em menores é essencial para que cada item do backlog atenda ao critério Small do INVEST.
Quem escreve, quando e onde
Embora a responsabilidade formal de manter o product backlog seja do product owner, qualquer membro da equipe pode redigir histórias. Segundo Mike Cohn, quem escreve importa muito menos do que quem participa da conversa (COHN, 2025). As histórias nascem em sessões de story mapping ou workshops de visão do produto, são refinadas no backlog refinement, comprometidas no sprint planning e validadas na sprint review. Seu registro é feito em ferramentas como Jira, Azure DevOps, Linear ou Trello — ou ainda em post-its em dinâmicas presenciais (ATLASSIAN, 2025).
Exemplos práticos: sistema de cantina universitária
Para ilustrar, considere o cenário de um sistema de pedidos para uma cantina universitária — um domínio de exercício acadêmico. Abaixo, exemplos que seguem o formato e os critérios discutidos.
US01 — Pedido antecipado | Prioridade: Alta
Descrição: Como um aluno, eu quero fazer meu pedido pelo aplicativo antes de chegar à cantina para que eu possa retirá-lo rapidamente no intervalo de aula.
Critérios de aceitação:
1. O aplicativo deve exibir apenas os itens disponíveis no horário atual.
2. O aluno recebe uma confirmação com número do pedido e tempo estimado de preparo.
3. Se o item ficar indisponível após o pedido, o sistema notifica o aluno e sugere alternativas.
US02 — Restrições alimentares | Prioridade: Alta
Descrição: Como um aluno com restrição alimentar, eu quero filtrar o cardápio por restrições (lactose, glúten, açúcar) para que eu só veja itens seguros para minha dieta.
Critérios de aceitação:
1. Os filtros devem incluir pelo menos: sem lactose, sem glúten, sem açúcar.
2. Itens que atendem ao filtro devem exibir selo de conformidade.
3. A informação nutricional deve ser fornecida por um nutricionista parceiro.
US03 — Painel de pedidos | Prioridade: Alta
Descrição: Como um atendente da cantina, eu quero visualizar os pedidos em um painel atualizado automaticamente para que eu possa prepará-los na ordem correta e reduzir erros.
Critérios de aceitação:
1. O painel deve atualizar em tempo real (ou com polling a cada 10 s em caso de internet instável).
2. Cada pedido exibe: número, itens, observações e horário limite de retirada.
3. O atendente pode marcar um pedido como "em preparo" e depois como "pronto para retirada".
Anti-exemplo — História mal escrita
❌ "Como product owner, eu quero um banco de dados MySQL com tabelas para pedidos, itens e pagamentos, com índices otimizados para consultas."
Erros:
— O PO não é o usuário final; a história deveria identificar quem se beneficia (COHN, 2025).
— Prescreve solução técnica (MySQL, índices), ferindo o critério "Negociável" do INVEST.
— Não menciona o "para que", impossibilitando avaliar o valor de negócio.
✔ Corrigida: "Como o dono da cantina, eu quero consultar um relatório de vendas do dia para que eu possa ajustar o cardápio do dia seguinte conforme a demanda real."
Parte 7 — Gerência de requisitos
Se a elicitação e a análise descobrem e documentam os requisitos, a gerência de requisitos garante que eles permaneçam íntegros, aprovados e rastreáveis ao longo de todo o ciclo de vida do projeto. Vazquez e Simões (2016) estruturam essa gerência em torno de quatro pilares: gestão de mudanças, aprovação, rastreabilidade e priorização.
Gerência de requisitos no CMMI-DEV
No modelo CMMI (Capability Maturity Model Integration), a Engenharia de Requisitos é abordada em duas áreas de processo: Desenvolvimento de Requisitos (RD — Requirements Development), que trata da elicitação, análise e especificação; e Gestão de Requisitos (REQM — Requirements Management), que trata do controle sobre os requisitos já estabelecidos — incluindo obter comprometimento dos envolvidos, gerenciar mudanças, manter a rastreabilidade e identificar inconsistências entre requisitos e os artefatos de projeto (VAZQUEZ; SIMÕES, 2016).
Gestão de mudanças
Requisitos mudam — é inevitável. A gestão de mudanças fornece um processo controlado para avaliar o impacto de cada alteração antes de aceitá-la: qual o custo? Quais artefatos serão afetados? A mudança mantém a consistência da especificação? No contexto ágil, o product backlog é o instrumento vivo de gestão de mudanças: novos itens entram, itens existentes são repriorizado ou removidos, e cada sprint entrega apenas o que foi comprometido (FATTO, 2020).
Matriz de rastreabilidade
A rastreabilidade é a capacidade de seguir o caminho de um requisito desde sua origem (quem pediu? por quê?) até sua implementação (qual código? qual teste?). A matriz de rastreabilidade é uma tabela que cruza requisitos com outros artefatos — como casos de teste, componentes de código ou objetivos de negócio. Existem dois eixos: horizontal (entre artefatos do mesmo nível, como requisito x caso de teste) e vertical (entre níveis, como requisito de negócio x requisito funcional). A rastreabilidade pode ainda ser pré (da origem ao requisito) ou pós (do requisito ao artefato de implementação). Seus benefícios incluem análise de impacto de mudanças, verificação de cobertura de testes e auditoria (VAZQUEZ; SIMÕES, 2016).
Priorização com MoSCoW
A análise MoSCoW é uma técnica de priorização que classifica cada requisito em quatro categorias: Must have (essencial — sem isso o sistema não funciona), Should have (importante, mas não impede a entrega), Could have (desejável, implementado se houver tempo/recursos) e Won't have (descartado nesta versão, mas registrado para o futuro). A diretriz prática é que os Must have não ultrapassem 60% do esforço total do timebox, reservando margem para imprevistos. A técnica é simples de aplicar e eficaz para alinhar expectativas entre equipe e stakeholders sobre o que será e o que não será entregue (VAZQUEZ; SIMÕES, 2016).
Tabela 3 — Categorias da análise MoSCoW
| Categoria | Significado | Diretriz prática |
|---|---|---|
| Must have | Requisito essencial; sem ele, a entrega não tem valor. | Não deve exceder ~60% do esforço do timebox*. |
| Should have | Importante, mas o sistema funciona sem ele; pode ser contornado temporariamente. | Incluso se o esforço dos Must permitir. |
| Could have | Desejável, mas facilmente descartável neste ciclo. | Só entra se houver folga comprovada de tempo/recurso. |
| Won't have | Fora do escopo desta versão, mas registrado para avaliação futura. | Documentar para evitar re-discussão. |
Fonte: adaptado de Vazquez e Simões (2016, cap. 9).
- Como técnica de priorização (VAZQUEZ; SIMÕES, 2016): em vez de perguntar "quanto tempo precisamos para entregar tudo?", inverte-se a pergunta para "dado esse prazo (ou orçamento) fixo, o que conseguimos entregar?". Isso força a equipe e os stakeholders a priorizarem de verdade — separando o essencial do desejável. Em sua obra os autores agrupam timeboxing e budgeting juntos: a lógica é a mesma, seja o recurso escasso tempo ou dinheiro.
- Como estrutura dos sprints no Scrum: cada sprint é, por definição, um timebox (geralmente de 2 a 4 semanas). Nenhum requisito novo entra durante o sprint, e ao final a equipe entrega o incremento com o que foi possível concluir. As próprias cerimônias do Scrum também são timeboxed — a daily tem 15 minutos, o sprint planning tem duração proporcional ao tamanho do sprint, e assim por diante.
Parte 8 — Aplicação prática: o fluxo completo de uma reunião de levantamento
Quando se reúnem os conceitos anteriores em um exercício prático — como o proposto em contextos acadêmicos de Prototipagem de Sistemas —, o fluxo típico segue uma sequência lógica que reflete diretamente as atividades da ER. A Tabela 4 sintetiza esse fluxo e os artefatos produzidos em cada etapa.
Tabela 4 — Fluxo prático de um levantamento de requisitos
| Etapa | Atividade | Artefato produzido |
|---|---|---|
| 1. Análise do cenário | Ler documentação sobre o cenário do negócio; identificar atores, fluxos e regras explícitas. | Notas de análise; rascunho de escopo. |
| 2. Matriz de stakeholders | Mapear interessados, seus papéis e suas necessidades/interesses principais. | Matriz de stakeholders (tabela com nome/perfil, papel no sistema e interesses). |
| 3. Roteiro de elicitação | Elaborar perguntas estratégicas focadas em regras de negócio ocultas, exceções e fluxos alternativos (exemplo de perguntas). | Roteiro de entrevista. |
| 4. Sessão de entrevista | Executar a entrevista com o cliente (real ou simulado), registrando perguntas e respostas. | Transcrição do diálogo completo. |
| 5. Escrita das user stories | Traduzir necessidades em histórias no formato padrão, com critérios de aceitação e prioridade. | Product backlog inicial. |
| 6. Revisão e entrega | Compilar todos os artefatos; verificar consistência interna usando checklist. | Documento final consolidado. |
Fonte: elaboração própria com base em Vazquez e Simões (2016) e Gomes (2026).
Observe como cada etapa se conecta aos fundamentos teóricos: a análise do cenário é uma forma simplificada de análise de documentos; a matriz de stakeholders aplica o conceito de partes interessadas; o roteiro remete à preparação da entrevista; a sessão é a execução da entrevista em si; a escrita das user stories é a especificação em formato ágil; e a revisão final é uma verificação simplificada com apoio de checklist. Os critérios de avaliação típicos — compreensão do cenário, qualidade do roteiro, estrutura das histórias (o "quê" e o "porquê", nunca o "como") e testabilidade dos critérios de aceitação — refletem diretamente os critérios de qualidade de uma especificação de requisitos discutidos na Parte 2.
Considerações finais
A Engenharia de Requisitos não é burocracia — é a disciplina que transforma necessidades vagas em compromissos verificáveis. Este post percorreu o caminho completo: dos fundamentos (o que é ER, o que é um requisito, os critérios de qualidade), passando pelas técnicas de elicitação (entrevista, observação, workshop) e análise (casos de uso, prototipação, histórias de usuário com INVEST e CCC, listas de verificação), chegando à gerência (CMMI-DEV, gestão de mudanças, MoSCoW, rastreabilidade) e, finalmente, à prática de uma reunião real de levantamento.
O ponto central permanece: boas especificações — sejam documentos formais ou histórias em post-its — dependem de boas conversas. Projetos não falham por falta de perguntas, mas por pararem cedo demais nas respostas (AQUA CLOUD, 2025). Dominar as técnicas apresentadas aqui é dominar a arte de perguntar certo, ouvir com atenção e transformar respostas em artefatos que guiam a construção do software correto para o problema certo.
Referências
AQUA CLOUD. 8 essential strategies for effective requirements elicitation. 2025. Disponível em: https://aqua-cloud.io/8-essential-strategies-effective-requirements-elicitation/. Acesso em: 24 mar. 2026.
ATLASSIAN. User stories with examples and a template. 2025. Disponível em: https://www.atlassian.com/agile/project-management/user-stories. Acesso em: 24 mar. 2026.
COHN, M. User stories and user story examples. Mountain Goat Software, 2025. Disponível em: https://www.mountaingoatsoftware.com/agile/user-stories. Acesso em: 24 mar. 2026.
FATTO. Engenharia de requisitos no contexto ágil. 2020. Disponível em: https://www.fattocs.com/blog/engenharia-de-requisitos-no-contexto-agil/. Acesso em: 24 mar. 2026.
GOMES, Alexandre. Técnica de entrevista: elicitação de requisitos — prototipagem de sistemas (exercício prático em grupo). Brasília: UDF/Cruzeiro do Sul Educacional, 2026. Material didático e notas de aula. Problemas propostos disponível em: https://blog.brasilacademico.com/p/desafio-mvp.html. Acesso em: 25 mar. 2026.
JUSTINMIND. 20 user story examples and best practices. 2025. Disponível em: https://www.justinmind.com/blog/examples-user-story-best-practices/. Acesso em: 24 mar. 2026.
KONRAD. User stories, maps and examples: 2025 guide. 2025. Disponível em: https://www.konrad.com/research/user-stories. Acesso em: 24 mar. 2026.
SOMMERVILLE, I.; SAWYER, P. Requirements engineering: a good practice guide. Chichester: John Wiley, 1997.
SOFTWARE TESTING HELP. Top 10 most common requirements elicitation techniques. 2025. Disponível em: https://www.softwaretestinghelp.com/requirements-elicitation-techniques/. Acesso em: 24 mar. 2026.
TECHTARGET. 8 AI meeting assistants to consider in 2026. 2026. Disponível em: https://www.techtarget.com/searchunifiedcommunications/tip/AI-meeting-assistants-to-consider. Acesso em: 24 mar. 2026.
VALENTE, M. T. Engenharia de software moderna: princípios e práticas para desenvolvimento de software com produtividade. Belo Horizonte: ASERG/DCC/UFMG, 2025. Disponível em: https://engsoftmoderna.info/. Acesso em: 24 mar. 2026.
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software orientado ao negócio. Rio de Janeiro: Brasport, 2016.
WIKIPEDIA. Requirements elicitation. 2026. Disponível em: https://en.wikipedia.org/wiki/Requirements_elicitation. Acesso em: 24 mar. 2026.
Fonte: Visto no Brasil Acadêmico
Comentários