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

Casos de uso no processo de elicitação e análise 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 a alternativa B afirma. A figura ilustra o processo de elicitação e análise de requisitos, e os casos de uso são uma das principais técnicas utilizadas nessa fase, conforme a literatura clássica de Engenharia de Requisitos (Sommerville e Pressman).

O processo de Engenharia de Requisitos é composto por atividades que vão desde a compreensão do problema até a gestão das mudanças. Segundo Sommerville, as fases são: Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação, Validação e Gestão. A elicitação (ou descoberta) é a fase em que se derivam os requisitos do sistema por meio de observação, discussões com usuários, análise de tarefas e outras técnicas. É nesse contexto que os casos de uso se encaixam: eles descrevem cenários de interação entre atores (usuários ou sistemas externos) e o sistema, permitindo identificar o que o sistema deve fazer.

Os casos de uso foram propostos por Ivar Jacobson e posteriormente incorporados à UML como um diagrama comportamental. Eles são especialmente úteis na fase de elicitação porque ajudam a entender as funcionalidades esperadas do ponto de vista do usuário, sem se preocupar com detalhes de implementação. Cada caso de uso descreve uma funcionalidade ou objetivo do sistema, e o conjunto deles forma o modelo de casos de uso, que serve de base para a especificação de requisitos.

É importante distinguir as fases do processo de Engenharia de Requisitos para não cair em armadilhas:

A pegadinha da questão está em associar casos de uso a fases erradas do processo. Muitos candidatos confundem a elicitação com a especificação, ou acham que casos de uso são apenas documentação final. Na verdade, os casos de uso são uma técnica de elicitação porque ajudam a descobrir os requisitos funcionais ao descrever as interações entre atores e sistema. Eles também podem ser usados na especificação, mas sua principal função é na descoberta.

Guarde a fronteira: casos de uso = técnica de elicitação/descoberta de requisitos, não de priorização, negociação ou documentação final. É nesse critério que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que casos de uso só poderiam ser usados na priorização se o sistema for orientado a objetos. Há dois erros: (1) casos de uso não são restritos a sistemas orientados a objetos — embora tenham origem na OOSE de Jacobson, são uma técnica geral de modelagem de requisitos; (2) a priorização e negociação não é a fase principal de uso de casos de uso, que é a elicitação. A alternativa confunde a origem histórica com uma restrição de aplicação.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa está correta porque casos de uso são uma técnica de descoberta de requisitos (elicitação). Eles descrevem as interações entre atores e o sistema, permitindo identificar as funcionalidades que o sistema deve oferecer. Essa é a fase em que se derivam os requisitos a partir da observação e discussão com usuários, e os casos de uso são uma ferramenta clássica para isso.

Alternativa C — ❌ Incorreta

Afirma que casos de uso não estão relacionados ao processo porque o diagrama é UML e a técnica seria usada apenas ao final para documentação. Isso é falso: o diagrama de casos de uso é uma representação UML, mas a técnica em si é usada durante a elicitação de requisitos, não apenas na documentação final. A alternativa inverte o papel da técnica, tratando-a como algo posterior ao processo.

Alternativa D — ❌ Incorreta

Diz que casos de uso estão mais relacionados à especificação de requisitos, onde podem ser detalhadas as iterações do sistema. Embora casos de uso possam ser usados na especificação, sua principal função é na elicitação/descoberta, não na especificação. A alternativa troca a fase principal pela secundária. Além disso, o termo "iterações" é vago e não reflete o papel central dos casos de uso.

Alternativa E — ❌ Incorreta

Afirma que casos de uso seriam melhor classificados como atividade de priorização e negociação por envolver a descrição de atores e papéis. Isso é um erro conceitual: descrever atores e papéis é parte da elicitação, não da priorização. A priorização envolve resolver conflitos e definir prioridades entre requisitos, o que não é o foco dos casos de uso. A alternativa confunde a descrição de atores com a atividade de negociação.

Gabarito: letra B