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 — Justificativa Lean e o Produto Mínimo Viável
A Justificativa Lean (Lean Business Case)
Antes mesmo de detalhar requisitos, é fundamental garantir que a iniciativa como um todo faça sentido para o negócio. É aqui que entra a Justificativa Lean (Lean Business Case — LBC). Diferente dos casos de negócio tradicionais — que tentam prever resultados com precisão exaustiva por meio de longos documentos e projeções financeiras de longo prazo —, a Justificativa Lean reconhece a incerteza inerente ao desenvolvimento de software e constrói mecanismos para aprender rapidamente (AGILITY AT SCALE, 2026). Fortemente baseada na filosofia Lean Startup de Eric Ries (2011), ela substitui a predição fixa pela validação iterativa através do ciclo Construir-Medir-Aprender (Build-Measure-Learn).
No contexto de frameworks ágeis em escala, como o SAFe (Scaled Agile Framework), a LBC é o artefato que enquadra cada iniciativa (épico) como uma hipótese testável — uma previsão sobre o que acontecerá se determinadas capacidades forem entregues. Seus componentes incluem a declaração de hipótese (o "por quê" conciso), a hipótese de resultados de negócio (como o sucesso será medido), indicadores antecedentes (leading indicators, que fornecem sinais iniciais de progresso) e a definição do Produto Mínimo Viável, que estabelece o escopo mínimo necessário para validar a hipótese (EFICODE, 2026). A conexão com a Engenharia de Requisitos é direta: ao definir critérios de sucesso mensuráveis logo no início, a LBC guia a priorização do backlog e apoia decisões sobre escopo, fazendo com que o analista foque nos requisitos estritamente necessários para o MVP em vez de especificar um sistema completo e monolítico (EFICODE, 2026).
O Produto Mínimo Viável (MVP)
Ries (2011) define o Produto Mínimo Viável (MVP — Minimum Viable Product) como a versão de um novo produto que permite à equipe coletar a maior quantidade de aprendizado validado sobre os clientes com o menor esforço possível. É importante destacar que "mínimo" não significa incompleto ou de baixa qualidade: significa que o MVP contém apenas as funcionalidades estritamente necessárias para que o produto entregue sua proposta de valor central e possa ser testado com usuários reais.
Definir o MVP exige que a equipe olhe para o conjunto total de funcionalidades desejadas — como as histórias de usuário levantadas durante a elicitação — e faça uma triagem rigorosa, separando o que é essencial do que é desejável. A técnica MoSCoW, apresentada na Parte 7, é uma das formas mais eficazes de realizar essa triagem: as histórias classificadas como Must have compõem o MVP; as demais (Should, Could e Won't have) ficam registradas para versões futuras (IIBA, 2015). A pergunta-chave para cada funcionalidade é: "Se retirarmos esta história, o produto ainda resolve o problema central do usuário?". Se a resposta for sim, a funcionalidade é candidata a ficar de fora da primeira versão (RIES, 2011).
O princípio da eliminação de desperdícios
A decisão sobre o que fica de fora do MVP não é arbitrária — ela se apoia no princípio Lean de eliminação de desperdícios (muda). No pensamento Lean aplicado ao software, desperdício é todo esforço empregado em algo que não contribui diretamente para o aprendizado ou para a entrega de valor ao cliente (POPPENDIECK; POPPENDIECK, 2003). Womack e Jones (2003) definem cinco princípios do pensamento Lean, entre os quais está a busca pela perfeição por meio da remoção contínua de tudo que não agrega valor.
Poppendieck e Poppendieck (2003) adaptaram os desperdícios clássicos da manufatura para o contexto de software, identificando sete tipos:
Tabela 5 — Os sete desperdícios do desenvolvimento de software
| Desperdício | Descrição |
|---|---|
| Trabalho parcialmente concluído | Funcionalidades iniciadas mas não finalizadas, que consomem recursos sem gerar valor. |
| Funcionalidades extras | Capacidades desenvolvidas além do necessário, que ninguém pediu ou que não serão usadas na validação da hipótese. |
| Reaprendizado | Retrabalho causado por informações perdidas ou decisões mal documentadas. |
| Transferências de responsabilidade | Passagens excessivas de tarefas entre pessoas ou equipes (handoffs), que geram perda de contexto. |
| Atrasos | Tempo de espera por aprovações, decisões ou recursos. |
| Troca de tarefas | Alternância constante entre atividades (task switching), que reduz a produtividade. |
| Defeitos | Erros que exigem correção posterior. |
Fonte: adaptado de Poppendieck e Poppendieck (2003, cap. 1).
No contexto da definição do MVP, o desperdício mais relevante a ser combatido é o de funcionalidades extras — ou seja, construir algo que, embora possa ser útil no futuro, não é necessário agora para testar se a proposta de valor funciona. Toda funcionalidade que não é essencial para validar a hipótese de negócio representa um custo de desenvolvimento sem retorno garantido (POPPENDIECK; POPPENDIECK, 2003).
Da priorização à justificativa: explicar o que ficou de fora e por quê
A Justificativa Lean vai além de simplesmente listar o que está no MVP. Ela exige que a equipe documente explicitamente o que foi excluído e o motivo da exclusão, à luz do princípio de eliminação de desperdícios. Cada funcionalidade deixada de fora deve ser acompanhada de uma explicação que demonstre por que, neste momento, desenvolvê-la representaria um desperdício — seja porque não é necessária para validar a hipótese central, seja porque pode ser contornada temporariamente, seja porque o custo de desenvolvimento supera o aprendizado esperado (RIES, 2011; EFICODE, 2026). Esse registro cumpre duas funções: evita que funcionalidades descartadas sejam rediscutidas sem novos argumentos e mantém um repositório de ideias para iterações futuras — alinhando-se à categoria Won't have da MoSCoW (VAZQUEZ; SIMÕES, 2016).
Exemplo: MVP e justificativa para a cantina universitária
Retomando o exemplo da Parte 6, suponha que a equipe tenha levantado dez histórias de usuário para o sistema da cantina. Após aplicar a MoSCoW, o MVP poderia incluir apenas três: pedido antecipado (US01), filtro por restrições alimentares (US02) e painel de pedidos para o atendente (US03) — pois sem essas três funcionalidades o sistema não resolve o problema central de agilizar o atendimento com segurança alimentar. As demais histórias — como programa de fidelidade, integração com carteira digital da universidade ou relatórios gerenciais avançados — seriam documentadas como excluídas do MVP, cada uma com sua justificativa: o programa de fidelidade, por exemplo, não é necessário para validar se os alunos de fato usarão o pedido antecipado (funcionalidade extra); relatórios gerenciais avançados podem ser temporariamente substituídos por consultas simples (contorno viável).
Parte 9 — 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 6 sintetiza esse fluxo e os artefatos produzidos em cada etapa.
Tabela 6 — 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. Definição do MVP | Aplicar MoSCoW sobre as histórias; selecionar os Must have que compõem o escopo mínimo viável. | Lista de funcionalidades do MVP. |
| 7. Justificativa Lean | Documentar as funcionalidades excluídas do MVP e justificar cada exclusão à luz da eliminação de desperdícios. | Registro de exclusões com justificativas. |
| 8. 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), Ries (2011) 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; a definição do MVP é a aplicação prática da priorização MoSCoW e do conceito de Produto Mínimo Viável; a justificativa Lean traduz o princípio de eliminação de desperdícios em decisões documentadas de escopo; 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"), testabilidade dos critérios de aceitação, coerência do MVP e fundamentação das exclusões — 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), chegando à gerência (CMMI-DEV, gestão de mudanças, MoSCoW, rastreabilidade), avançando até a Justificativa Lean e a definição do MVP — com o princípio de eliminação de desperdícios que sustenta a decisão consciente sobre o que construir agora e o que deixar para depois — 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. E boas decisões de escopo dependem de clareza sobre o que é essencial para validar uma hipótese de negócio e o que, por mais atraente que pareça, representa desperdício neste momento. 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, transformar respostas em artefatos que guiam a construção do software correto para o problema certo — e ter a disciplina de não construir mais do que o necessário para provar que se está no caminho certo.
Referências
AGILITY AT SCALE. Lean business case. 2026. Disponível em: https://agility-at-scale.com. Acesso em: 25 mar. 2026.
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.
EFICODE. Lean business case in SAFe. 2026. Disponível em: https://www.eficode.com. Acesso em: 25 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.
INTERNATIONAL INSTITUTE OF BUSINESS ANALYSIS (IIBA). A guide to the business analysis body of knowledge (BABOK Guide). 3. ed. Toronto: IIBA, 2015.
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.
POPPENDIECK, Mary; POPPENDIECK, Tom. Lean software development: an agile toolkit. Boston: Addison-Wesley, 2003.
RIES, Eric. The lean startup: how today's entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business, 2011.
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.
WOMACK, James P.; JONES, Daniel T. Lean thinking: banish waste and create wealth in your corporation. 2. ed. New York: Free Press, 2003.
Fonte: Visto no Brasil Acadêmico
Comentários