Questão de Engenharia de Software — Engenharia de Requisitos — CESPE / CEBRASPE 2024

Casos de uso na Engenharia de Requisitos

Gabarito: letra B. A técnica de casos de uso é uma atividade do processo de Descoberta de requisitos (elicitação), pois descreve as interações entre atores e o sistema para identificar funcionalidades — exatamente o que o processo de elicitação busca. As demais alternativas ou restringem indevidamente o uso da técnica (como a exigência de orientação a objetos) ou a deslocam para fases posteriores do processo.

A engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar os serviços e restrições de um sistema. Dentro dela, a elicitação (ou descoberta) de requisitos é a fase em que se identificam as necessidades dos stakeholders por meio de técnicas como entrevistas, workshops, prototipagem e, justamente, casos de uso. Um caso de uso descreve uma sequência de interações entre um ou mais atores e o sistema, com o objetivo de realizar uma funcionalidade específica. Essa descrição é fundamental para entender o que o sistema deve fazer, ou seja, para descobrir os requisitos funcionais.

A técnica de casos de uso não está restrita a sistemas orientados a objetos. Embora seja um conceito central na UML, ela pode ser aplicada em qualquer paradigma de desenvolvimento, pois o foco está na interação entre ator e sistema, não na implementação. Além disso, os casos de uso não são apenas documentação final: eles são artefatos vivos que auxiliam na comunicação entre stakeholders e na validação dos requisitos ao longo de todo o processo.

A figura mencionada no enunciado ilustra o processo de elicitação e análise de requisitos, que, segundo Sommerville, é composto por etapas como descoberta, classificação e priorização, especificação e validação. A técnica de casos de uso se encaixa naturalmente na etapa de descoberta, pois é uma forma estruturada de levantar o que o sistema deve fazer a partir da perspectiva dos usuários.

A pegadinha da questão está em associar casos de uso a fases específicas ou a paradigmas de programação. A banca explora a confusão entre elicitação (descobrir o que o sistema deve fazer) e especificação (documentar formalmente os requisitos). Embora os casos de uso também possam ser usados na especificação, sua principal função é na descoberta, pois eles ajudam a identificar e entender os requisitos funcionais a partir das interações dos atores.

Guarde a fronteira entre descoberta (elicitação) e especificação: a primeira busca entender o problema e as necessidades; a segunda formaliza esse entendimento em um documento. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

A alternativa restringe o uso de casos de uso a sistemas orientados a objetos, o que é incorreto. A técnica de casos de uso é independente do paradigma de programação; ela descreve interações entre atores e sistema, podendo ser aplicada em qualquer tipo de desenvolvimento. Além disso, a priorização e negociação de requisitos é uma etapa posterior à descoberta, e os casos de uso não são a técnica principal para essa finalidade.

Alternativa B — ✅ Correta ⟵ GABARITO

A técnica de casos de uso é uma atividade do processo de Descoberta de requisitos (elicitação). Ela permite identificar as funcionalidades do sistema a partir da descrição das interações entre atores e o sistema, sendo uma das principais técnicas de levantamento de requisitos. A figura do processo de elicitação e análise de requisitos reforça essa classificação, pois os casos de uso são usados para descobrir o que o sistema deve fazer.

Alternativa C — ❌ Incorreta

A alternativa afirma que os casos de uso não estão relacionados ao processo de elicitação, pois seriam usados apenas na documentação final. Isso é incorreto: os casos de uso são uma técnica ativa de elicitação, usada durante todo o processo de engenharia de requisitos, não apenas na documentação. Além disso, o processo de elicitação não é um diagrama UML, mas sim um conjunto de atividades; os casos de uso são uma técnica que pode ser representada por diagramas UML, mas não se limitam a eles.

Alternativa D — ❌ Incorreta

A alternativa afirma que os casos de uso estão mais relacionados à especificação de requisitos, pois detalham as iterações do sistema. Embora os casos de uso possam ser usados na especificação, sua principal função é na descoberta de requisitos, pois descrevem as interações entre atores e sistema para identificar funcionalidades. A especificação é a formalização dos requisitos já descobertos, e os casos de uso são uma ferramenta de elicitação, não de documentação formal.

Alternativa E — ❌ Incorreta

A alternativa classifica os casos de uso como atividade de priorização e negociação de requisitos, por envolver a descrição de atores. Isso é incorreto: a descrição de atores é parte da elicitação, não da priorização. A priorização e negociação envolvem resolver conflitos e definir a importância dos requisitos, o que não é o foco dos casos de uso. Os casos de uso descrevem quem interage com o sistema e como, o que é uma atividade de descoberta.

Gabarito: letra B — a técnica de casos de uso é uma atividade do processo de Descoberta de requisitos.