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

Engenharia de Requisitos: elicitação e definição de requisitos

Gabarito: letra A. A prática eficaz na elicitação de requisitos é realizar entrevistas com os stakeholders e usuários finais para entender suas necessidades e expectativas — método clássico e direto de levantamento de requisitos, conforme a engenharia de requisitos descrita por autores como Sommerville e Pressman. As demais alternativas contrariam princípios fundamentais da área, como o uso de protótipos, a definição de requisitos antes do desenvolvimento e a especificidade dos requisitos.

A engenharia de requisitos é o processo de compreensão e definição dos serviços que o sistema deve fornecer, além da identificação de restrições de operação e desenvolvimento. É a atividade que estabelece a ponte entre as necessidades dos stakeholders e a construção do software — sem ela, o produto resultante tem grande probabilidade de não atender ao que o cliente realmente precisa. O processo envolve tarefas como concepção, levantamento, elaboração, negociação, especificação, validação e gestão, todas iterativas e adaptadas ao contexto do projeto.

A elicitação de requisitos (também chamada de levantamento) é a fase em que a equipe busca descobrir o que os stakeholders realmente necessitam. Existem diversos métodos para isso, cada um com vantagens e limitações: entrevistas, questionários, observação, análise de documentos, brainstorming, prototipagem, entre outros. A escolha do método depende do contexto, do tipo de sistema e do perfil dos envolvidos. A entrevista, em particular, é um dos métodos mais eficazes porque permite interação direta, perguntas de acompanhamento e compreensão profunda das necessidades — exatamente o que a alternativa A descreve.

A prototipagem é uma técnica valiosa na elicitação: permite que os stakeholders visualizem uma versão preliminar do sistema e forneçam feedback concreto, reduzindo ambiguidades e mal-entendidos. Longe de confundir, o protótipo ajuda a alinhar expectativas e a validar requisitos antes do desenvolvimento completo. Já a definição de requisitos após o desenvolvimento é um contrassenso: os requisitos são a base para o projeto e a construção, e defini-los depois inviabiliza o planejamento e a entrega adequada. Requisitos vagos e genéricos também são prejudiciais — a especificidade é essencial para que a equipe saiba exatamente o que construir e para que a validação seja possível.

A pegadinha desta questão está em alternativas que parecem plausíveis à primeira vista, mas contrariam as boas práticas da engenharia de requisitos. A banca explora o senso comum de que "questionários são mais rápidos" ou que "flexibilidade é sempre boa", quando na verdade a eficácia da elicitação depende de métodos interativos e da clareza dos requisitos. Guarde o critério: a elicitação eficaz envolve interação direta com os stakeholders e técnicas que permitam compreensão profunda e validação contínua — é exatamente isso que separa a alternativa correta das demais.

Alternativa A — ✅ Correta ⟵ GABARITO

A entrevista é um dos métodos mais tradicionais e eficazes de elicitação de requisitos. Ela permite que o analista converse diretamente com stakeholders e usuários finais, fazendo perguntas abertas e fechadas, explorando necessidades, expectativas, restrições e prioridades. A interação face a face (ou por videoconferência) possibilita esclarecer dúvidas na hora, captar nuances e construir um entendimento compartilhado — exatamente o que o enunciado pede: "entender suas necessidades e expectativas em relação ao sistema".

Alternativa B — ❌ Incorreta

Afirma que protótipos devem ser evitados porque "podem confundir os stakeholders". Isso é o oposto da prática recomendada. A prototipagem é uma técnica de elicitação e validação de requisitos que ajuda os stakeholders a visualizarem o sistema e fornecerem feedback concreto, reduzindo ambiguidades. O protótipo não confunde — ele alinha expectativas e permite ajustes precoces, evitando retrabalho. O erro está em descartar uma ferramenta valiosa por um receio infundado.

Alternativa C — ❌ Incorreta

Definir requisitos "apenas após a fase de desenvolvimento" é logicamente impossível e tecnicamente absurdo. Os requisitos são o ponto de partida do desenvolvimento: sem eles, não há como planejar, projetar ou construir o sistema. A engenharia de requisitos ocorre antes do desenvolvimento, justamente para garantir que o sistema atenda às necessidades reais. Definir requisitos depois seria como construir uma casa sem planta e só então descobrir o que o morador queria.

Alternativa D — ❌ Incorreta

A afirmação de que a elicitação deve ser feita "exclusivamente através de questionários" é restritiva demais. Questionários são úteis para coletar informações de um grande número de pessoas de forma padronizada, mas têm limitações: não permitem aprofundamento, esclarecimento de dúvidas ou captura de nuances. A boa prática é combinar múltiplos métodos (entrevistas, questionários, observação, protótipos, etc.), escolhendo os mais adequados ao contexto. Depender exclusivamente de um único método empobrece a elicitação.

Alternativa E — ❌ Incorreta

Manter requisitos "vagos e genéricos" contraria o princípio da especificidade. Requisitos devem ser claros, precisos, testáveis e sem ambiguidade — é isso que permite à equipe construir o sistema certo e validar se ele atende ao esperado. Requisitos vagos geram interpretações divergentes, retrabalho e insatisfação. A flexibilidade desejada no desenvolvimento não vem de requisitos vagos, mas de um processo de gestão de mudanças bem definido.

Gabarito: letra A — a entrevista com stakeholders e usuários finais é a prática eficaz de elicitação de requisitos descrita corretamente.