Questão de Engenharia de Software — Engenharia de Requisitos — FGV 2024

Elicitação de Requisitos: Prototipação

Gabarito: letra B. Para garantir que todos os requisitos críticos sejam identificados e documentados, a melhor prática é utilizar técnicas de prototipação, que permitem que os usuários interajam com um modelo preliminar e forneçam feedback antes do desenvolvimento completo. Essa abordagem iterativa é fundamental na Engenharia de Requisitos, pois reduz ambiguidades e valida as necessidades dos stakeholders de forma contínua.

A Engenharia de Requisitos é o processo formal, sistemático e contínuo de identificar, analisar, documentar, validar e gerenciar requisitos de software. É uma das fases mais críticas do desenvolvimento, pois erros nessa etapa comprometem todo o projeto. O objetivo é produzir e manter o Documento de Requisitos, que serve como base para o projeto e a construção do sistema.

A elicitação de requisitos é a atividade de descobrir as necessidades dos stakeholders. Existem diversas técnicas para isso, como entrevistas, questionários, brainstorming, workshops, casos de uso, etnografia e prototipação. Cada técnica tem suas vantagens e desvantagens, e a escolha depende do contexto do projeto. A prototipação, em particular, é uma técnica poderosa porque permite que os usuários visualizem e interajam com uma versão preliminar do sistema, fornecendo feedback valioso que ajuda a refinar os requisitos antes do desenvolvimento completo.

A prototipação é especialmente útil quando os requisitos não são bem compreendidos ou quando há incerteza sobre as necessidades dos usuários. Ela permite validar ideias, conceitos e requisitos de forma iterativa, reduzindo o risco de desenvolver um sistema que não atenda às expectativas. Além disso, a prototipação ajuda a identificar requisitos que não foram explicitamente declarados, mas que são essenciais para a usabilidade e a satisfação do usuário.

A banca explora a confusão entre prototipação e outras práticas, como o MVP (Produto Mínimo Viável). Enquanto a prototipação é uma técnica de elicitação que visa validar requisitos, o MVP é uma estratégia de desenvolvimento que visa lançar rapidamente uma versão mínima do produto para aprender com o feedback dos usuários. Ambos envolvem feedback, mas em momentos diferentes do ciclo de vida. A alternativa C, que sugere implementar um MVP sem coletar feedback, é claramente incorreta, pois o MVP deve ser usado justamente para coletar feedback.

Outra pegadinha é a ideia de que os requisitos devem ser reunidos de uma vez no início do projeto e não sofrer mudanças. Isso é uma visão tradicional (modelo cascata) que não reflete a realidade de muitos projetos, onde os requisitos evoluem. A Engenharia de Requisitos moderna reconhece que os requisitos são voláteis e que a gestão de mudanças é essencial.

Portanto, a alternativa B é a única que está alinhada com as boas práticas de Engenharia de Requisitos, pois a prototipação é uma técnica que promove a interação com os usuários e o feedback contínuo, garantindo que os requisitos críticos sejam identificados e documentados corretamente.

Alternativa A — ❌ Incorreta

Focar exclusivamente em entrevistas com a alta direção, ignorando os usuários finais, é um erro grave. Os usuários finais são os que realmente interagem com o sistema e conhecem as necessidades operacionais. Ignorá-los pode levar a requisitos incompletos ou incorretos. A elicitação deve envolver todos os stakeholders relevantes, não apenas a alta direção.

Alternativa B — ✅ Correta ⟵ GABARITO

A prototipação é uma técnica de elicitação de requisitos que permite que os usuários interajam com um modelo preliminar do sistema. Isso possibilita que eles forneçam feedback sobre funcionalidades, usabilidade e fluxos, antes do desenvolvimento completo. Esse feedback é essencial para refinar e validar os requisitos, garantindo que o sistema atenda às expectativas dos stakeholders. A prototipação é especialmente útil quando os requisitos são vagos ou complexos.

Alternativa C — ❌ Incorreta

Implementar imediatamente um MVP sem coletar feedback dos stakeholders é contrário ao próprio conceito de MVP. O MVP é uma versão mínima do produto que deve ser usada para validar hipóteses e coletar feedback dos usuários. Sem esse feedback, o MVP perde seu propósito e aumenta o risco de desenvolver um produto que não atenda às necessidades. A alternativa confunde a estratégia de MVP com a ausência de elicitação.

Alternativa D — ❌ Incorreta

Reunir todos os requisitos de uma vez no início do projeto e evitar mudanças durante o desenvolvimento é uma abordagem tradicional (cascata) que não é adequada para muitos projetos. Os requisitos são voláteis e mudam à medida que o entendimento do problema evolui. A Engenharia de Requisitos moderna reconhece a necessidade de gestão de mudanças e iteração. Evitar mudanças pode levar a um sistema desatualizado ou que não atende às necessidades reais.

Alternativa E — ❌ Incorreta

Deixar que a equipe de desenvolvimento defina os requisitos sem a participação dos stakeholders é um erro grave. Os stakeholders são a fonte primária de requisitos, pois conhecem o negócio e as necessidades. Sem a participação deles, a equipe pode desenvolver um sistema que não atende às expectativas, resultando em retrabalho e insatisfação. A elicitação de requisitos deve ser colaborativa.

Gabarito: letra B