Questão de Engenharia de Software — Geral — INSTITUTO AOCP 2025
- Código
- qa700026
- Banca
- INSTITUTO AOCP
- Órgão
- TRE TO
- Ano
- 2025
- Cargo
- TJ
- ABenchmarking.
- BProtótipo.
- CAnálise de Documentos.
- DCasos de uso.
- EEntrevista.
GabaritoD — 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.
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.
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.
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.
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.
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.
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 💪
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