Questão de Engenharia de Software — Geral — CESPE / CEBRASPE 2024
Engenharia de Software›Geral
Código
ce403903
Banca
CESPE / CEBRASPE
Órgão
TSE
Ano
2024
Cargo
AJ
Julgue o próximo item, relativo à engenharia de requisitos de software no contexto de análise e projeto de sistemas.
Em um projeto ágil, a gestão das tarefas a realizar normalmente é iniciada com um backlog limitado de produtos com requisitos de alto nível de abstração, limitando a realidade ao que é relevante a este nível mais genérico.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Engenharia de Requisitos em Projetos Ágeis: Backlog e Abstração
Gabarito: Certo (C). Em projetos ágeis, a gestão de tarefas começa com um Product Backlog limitado, contendo itens de alto nível de abstração (épicos e histórias de usuário genéricas), que são refinados continuamente conforme o projeto avança — é exatamente o que o enunciado afirma. Essa abordagem segue o princípio da especificação "just in time", evitando desperdício de planejamento detalhado em um cenário de requisitos voláteis.
O Product Backlog é o coração do planejamento ágil. Ele é uma lista priorizada e dinâmica de tudo que pode ser necessário ao produto — funcionalidades, melhorias, correções e requisitos técnicos. A característica fundamental desse artefato é que ele não precisa estar completo nem detalhado no início. Pelo contrário: começa com itens de alto nível, como épicos (grandes funcionalidades ainda não detalhadas) ou histórias de usuário genéricas, e vai sendo refinado ao longo do tempo.
Por que essa estratégia? Em ambientes complexos e dinâmicos, os requisitos mudam com frequência. Investir pesado em detalhamento precoce seria desperdício — o esforço poderia ser jogado fora se as prioridades mudassem. O princípio da especificação "just in time" (ou "just in time specification") diz que os requisitos devem ser detalhados no momento em que serão trabalhados, não antes. Isso mantém o foco no que é relevante agora, sem engessar o projeto.
Na prática, o ciclo funciona assim: o Product Owner prioriza o backlog; a equipe seleciona os itens de maior prioridade para a Sprint; durante o Sprint, os itens são detalhados e implementados; e, ao final, o backlog é revisado e refinado (em reuniões de refinement ou backlog grooming), com novas histórias sendo desmembradas, estimadas e priorizadas. Esse processo iterativo garante flexibilidade e adaptação contínua.
A pegadinha que a banca poderia explorar aqui é inverter a lógica: dizer que o backlog começa completo e detalhado, ou que os requisitos são especificados integralmente no início — o que é característica de metodologias tradicionais (cascata), não de métodos ágeis. O enunciado, porém, descreve corretamente a abordagem ágil, sem cair nessa armadilha.
1Product Owner prioriza
2Equipe seleciona p/ Sprint
3Detalha e implementa
4Revisa e refina
LEVEL · soulevel.com.br
NÃO CAIA NESSA!
A banca adora inverter a lógica do backlog: dizer que ele começa completo e detalhado, ou que os requisitos são especificados integralmente no início — o que é característica de metodologias tradicionais (cascata), não de métodos ágeis. O enunciado, porém, descreve corretamente a abordagem ágil, sem cair nessa armadilha.