Questão de Engenharia de Software — Engenharia de Requisitos — FGV 2025
Engenharia de Software›Engenharia de Requisitos
Código
fg121746
Banca
FGV
Órgão
TCE-PI
Ano
2025
Nível
Superior
Cargo
Auditor de Controle Externo - Controle Externo - Específica de Tecnologia da Informação - Sistemas, Engenharia de Dados e Ciência de Dados (Manhã)
Acerca da elicitação e validação de requisitos, ao utilizar a técnica de casos de uso, assinale a opção que indica a prática que pode comprometer principalmente a rastreabilidade dos requisitos.
AA construção dos casos de uso baseados somente em entrevistas com os usuários chave.
BA ausência de detalhamento de cenários alternativos e exceções nos diagramas de casos de uso.
CA falta de revisão contínua dos casos de uso pelos desenvolvedores após cada iteração do projeto.
DA utilização de uma linguagem de modelagem que seja amplamente compreendida pelos usuários finais.
EA inclusão de detalhes técnicos no fluxograma de casos de uso, visando a implementação direta pelos desenvolvedores
Revelar gabarito e comentário▾
GabaritoB — A ausência de detalhamento de cenários alternativos e exceções nos diagramas de casos de uso.
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”.
Elicitação e Validação de Requisitos com Casos de Uso
Gabarito: letra B. A ausência de detalhamento de cenários alternativos e exceções compromete a rastreabilidade porque esses cenários representam requisitos que, se não documentados, ficam sem vínculo com as fases seguintes. A rastreabilidade exige que cada requisito seja identificável e ligado a sua origem e implementação; omitir partes do comportamento do sistema quebra essa cadeia.
As alternativas A, C, D e E podem trazer outros problemas, mas não atingem diretamente a rastreabilidade com a mesma gravidade.
Prática
Impacto na Rastreabilidade
Motivo
Construção baseada somente em entrevistas com usuários-chave
Baixo
As fontes ainda são documentadas, permitindo rastrear requisitos
Ausência de detalhamento de cenários alternativos e exceções
Alto (compromete)
Esses cenários representam requisitos que, se não documentados, ficam sem vínculo com fases seguintes
Falta de revisão contínua pelos desenvolvedores
Médio
Pode levar a requisitos desatualizados, mas não impede rastreabilidade do que foi documentado
Uso de linguagem amplamente compreensível pelos usuários finais
Nenhum
Facilita validação e comunicação, não prejudica rastreabilidade
Inclusão de detalhes técnicos no fluxograma de casos de uso
Baixo
Requisitos ainda estão registrados; rastreabilidade depende de identificadores e ligações
Rastreabilidade de requisitos
1Comprometida por
Omissão de cenários alternativos
Omissão de cenários de exceção
2Preservada quando
Cada requisito registrado
Vínculo com origem e implementação
3Não comprometem diretamente
Entrevistas só com usuários-chave
Falta de revisão contínua
Linguagem compreensível
Detalhes técnicos no diagrama
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
A construção baseada somente em entrevistas com usuários-chave pode limitar a abrangência da elicitação, mas não necessariamente compromete a rastreabilidade. As fontes ainda são documentadas (as entrevistas), permitindo rastrear requisitos.
Alternativa B — ✅ Correta ⟵ GABARITO
Cenários alternativos e de exceção são partes essenciais dos requisitos. Se não forem detalhados (em diagramas ou textos), esses requisitos simplesmente não existem na especificação, impossibilitando sua rastreabilidade. A rastreabilidade depende de cada requisito estar registrado e identificado; a omissão deliberada de cenários quebra esse princípio.
Alternativa C — ❌ Incorreta
A falta de revisão contínua pode levar a requisitos desatualizados, mas não impede a rastreabilidade do que já foi documentado. A revisão é uma boa prática, mas sua ausência não é o principal fator de comprometimento da rastreabilidade.
Alternativa D — ❌ Incorreta
Usar linguagem compreensível para os usuários finais é desejável e não prejudica a rastreabilidade; pelo contrário, facilita a validação e a comunicação.
Alternativa E — ❌ Incorreta
Incluir detalhes técnicos no fluxograma (na verdade, no diagrama de caso de uso) pode poluir a representação, mas não inviabiliza a rastreabilidade. Os requisitos ainda estão registrados — a rastreabilidade depende de identificadores e ligações, não do nível de abstração.
NÃO CAIA NESSA!
A banca explora o fato de que diagramas de caso de uso (UML) não exibem cenários alternativos — isso é normal. Mas o detalhamento desses cenários deve estar presente em outros artefatos (descrições textuais). A ausência em qualquer lugar quebra a rastreabilidade. O enunciado diz “nos diagramas”, mas a intenção é a falta de documentação desses cenários como um todo.