Pular para o conteúdo principal

Questão de Engenharia de Software — Geral — INSTITUTO AOCP 2025

Engenharia de SoftwareGeral
Código
qa700026
Banca
INSTITUTO AOCP
Órgão
TRE TO
Ano
2025
Cargo
TJ
O levantamento de requisitos é uma etapa fundamental no processo de análise de projetos, pois visa identificar necessidades, expectativas e restrições dos stakeholders em relação ao sistema a ser desenvolvido. Durante essa fase, são mapeados os requisitos funcionais e não funcionais, que servirão de base para o projeto do sistema. A análise de requisitos permite que a equipe de desenvolvimento entenda claramente as funcionalidades desejadas, os critérios de sucesso e as condições para atender aos objetivos do negócio. Esse processo orienta o desenvolvimento de soluções eficazes e alinhadas às expectativas dos usuários e stakeholders. Considerando o exposto, assinale a alternativa que apresenta a técnica que descreve como os usuários (ou “atores”) interagem com o sistema para atingir um objetivo específico, detalhando os processos do sistema e os fluxos de eventos em cenários específicos.
  1. ABenchmarking.
  2. BProtótipo.
  3. CAnálise de Documentos.
  4. DCasos de uso.
  5. EEntrevista.
Revelar gabarito e comentário

GabaritoD — 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”.

Levantamento de Requisitos: Casos de Uso

Gabarito: letra D. A técnica que descreve como os usuários (atores) interagem com o sistema para atingir um objetivo específico, detalhando processos e fluxos de eventos em cenários, é o caso de uso — conceito central da UML e da engenharia de requisitos orientada a objetos. As demais alternativas são técnicas de elicitação ou modelagem que não possuem essa característica de descrever interações ator-sistema em cenários.

O levantamento de requisitos é a fase em que a equipe descobre, analisa, documenta e verifica o que o sistema deve fazer para atender às necessidades dos stakeholders. Dentro desse processo, existem diversas técnicas de elicitação — como entrevistas, questionários, brainstorming, análise de documentos, observação, prototipagem e benchmarking — e também técnicas de modelagem, como os casos de uso. A distinção fundamental é que as técnicas de elicitação são voltadas à coleta de informações, enquanto os casos de uso são uma técnica de modelagem e especificação que organiza essas informações em uma narrativa estruturada.

O caso de uso, formalizado por Ivar Jacobson e incorporado à UML, descreve um comportamento do sistema sob a perspectiva do usuário. Ele responde à pergunta: "o que o sistema faz para que um ator alcance um objetivo?". Cada caso de uso é composto por um ator (quem interage), um objetivo (o que se deseja alcançar) e um fluxo de eventos (a sequência de passos que descreve a interação). Esse fluxo pode incluir o fluxo principal (caminho feliz), fluxos alternativos (variações) e fluxos de exceção (erros). Por exemplo, em um sistema de caixa eletrônico, o caso de uso "Sacar dinheiro" envolve o ator Cliente, o objetivo de retirar dinheiro, e o fluxo: inserir cartão, digitar senha, informar valor, receber cédulas. Essa estrutura é exatamente o que o enunciado descreve: "como os usuários (ou 'atores') interagem com o sistema para atingir um objetivo específico, detalhando os processos do sistema e os fluxos de eventos em cenários específicos".

A banca explora a confusão entre técnicas de elicitação (entrevista, análise de documentos, benchmarking) e técnicas de modelagem (casos de uso, protótipos). Enquanto a entrevista e a análise de documentos são formas de coletar requisitos diretamente com stakeholders ou de fontes existentes, o caso de uso é uma forma de representar e especificar o comportamento do sistema de maneira padronizada. O protótipo, por sua vez, é uma versão simplificada do sistema para validar requisitos, mas não descreve formalmente os fluxos de eventos em cenários como o caso de uso faz.

Guarde a fronteira entre elicitação (coletar) e modelagem (representar): é exatamente nela que as alternativas se dividem. A questão pede uma técnica que descreve interações — isso é modelagem, não coleta.

Técnicas de requisitos
  • 1Elicitação (coletar)
    • Entrevista
    • Análise de documentos
    • Benchmarking
  • 2Modelagem (representar)
    • Casos de uso
      • Ator (quem interage)
      • Objetivo (o que alcançar)
      • Fluxo de eventos
        • Principal (caminho feliz)
        • Alternativo (variações)
        • Exceção (erros)
    • Protótipo (validação)
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

O benchmarking é uma técnica de elicitação que consiste em analisar produtos, processos ou práticas de outras organizações (concorrentes ou referências) para identificar boas práticas e oportunidades de melhoria. Ele não descreve interações ator-sistema nem fluxos de eventos; é uma técnica comparativa de mercado, não uma técnica de modelagem de requisitos.

Alternativa B — ❌ Incorreta

O protótipo é uma versão preliminar e simplificada do sistema, usada para validar requisitos com os usuários e obter feedback. Embora ajude a entender as interações, ele não é uma técnica que descreve formalmente os fluxos de eventos em cenários — é um artefato concreto para validação, não uma especificação narrativa como o caso de uso.

Alternativa C — ❌ Incorreta

A análise de documentos é uma técnica de elicitação que examina documentos existentes (manuais, formulários, relatórios, sistemas legados) para extrair requisitos. Ela é uma fonte de informação, mas não descreve como os atores interagem com o sistema em cenários específicos — é uma técnica de coleta passiva, não de modelagem comportamental.

Alternativa D — ✅ Correta ⟵ GABARITO

O caso de uso é exatamente a técnica que descreve as interações entre atores e o sistema para atingir um objetivo, detalhando os fluxos de eventos em cenários. É um dos diagramas comportamentais da UML e uma das principais técnicas de especificação de requisitos funcionais na abordagem orientada a objetos. A definição do enunciado — "como os usuários (ou 'atores') interagem com o sistema para atingir um objetivo específico, detalhando os processos do sistema e os fluxos de eventos em cenários específicos" — é a definição clássica de caso de uso.

Alternativa E — ❌ Incorreta

A entrevista é uma técnica de elicitação em que o analista conversa diretamente com stakeholders para coletar requisitos. É uma técnica de coleta de informações, não de modelagem. Ela pode alimentar a criação de casos de uso, mas não é a técnica que descreve as interações ator-sistema em cenários.

NÃO CAIA NESSA!

A banca mistura técnicas de elicitação (entrevista, análise de documentos, benchmarking) com técnicas de modelagem (casos de uso). O candidato que decora apenas os nomes das técnicas sem entender a função de cada uma tende a marcar "entrevista" por ser a mais conhecida. A palavra-chave é "descreve como os usuários interagem" — isso é modelagem comportamental, não coleta de informações. Com treino, você identifica essa distinção de longe 💪

PEGA ESSA DICA!

Para diferenciar as técnicas, pergunte-se: "essa técnica coleta informação ou representa o comportamento do sistema?". Entrevista, questionário, brainstorming, análise de documentos e benchmarking coletam. Casos de uso, protótipos e diagramas representam. O caso de uso é o único que descreve formalmente a interação ator-sistema com fluxos de eventos.

Gabarito: letra D

Link permanente: /questoes/qa700026