Durante o desenvolvimento de um software de gerenciamento de estoque, a equipe focou nas funcionalidades sem considerar a escalabilidade necessária para o rápido crescimento do varejista. A falta de comunicação com stakeholders e o pouco engajamento dos usuários finais não revelou esse problema. Após a implementação, o software apresentou problemas de desempenho, causando atrasos e insatisfação. Para evitar esse problema é necessário
- A)focar exclusivamente no desenvolvimento de funcionalidades adicionais para aumentar a satisfação do cliente no curto prazo.
Errada, porque focar só em novas funcionalidades ignora requisitos de escalabilidade e desempenho, que eram justamente o ponto crítico do caso.
- B)limitar o envolvimento dos usuários finais no processo de validação dos requisitos, mas aumentar o envolvimento dos stakeholders para acelerar o desenvolvimento.
Errada, pois reduzir o envolvimento dos usuários finais piora a chance de detectar problemas reais de uso e não resolve a falha de comunicação.
- C)aumentar a dependência em ferramentas automatizadas de validação de requisitos para reduzir a necessidade de feedback direto dos usuários finais.
Errada, porque ferramenta automatizada ajuda, mas não substitui o feedback direto de quem usa e de quem define as necessidades do negócio.
- D)utilizar uma abordagem de desenvolvimento waterfall, garantindo que todas as etapas sejam completadas sequencialmente com interação do usuário apenas antes do lançamento.
Errada, já que o modelo waterfall, com pouca interação durante o processo, tende a dificultar a descoberta precoce de mudanças e necessidades reais.
- E)implementar um processo de comunicação mais eficaz que inclua revisões frequentes dos requisitos com stakeholders e sessões de feedback com usuários finais para garantir que todos os requisitos sejam devidamente entendidos e documentados.
Certa, porque revisões frequentes com stakeholders e feedback dos usuários finais melhoram a comunicação, validam requisitos e reduzem o risco de falhas de entendimento.
Gabarito: E
Em desenvolvimento de software, não basta sair codando funcionalidades como se o mundo não mudasse no dia seguinte. É preciso levantar requisitos com cuidado, conversar com quem vai usar e com quem tem interesse no sistema, porque muitas falhas aparecem justamente quando a equipe ignora necessidades não funcionais, como desempenho, escalabilidade e usabilidade. Aqui, o problema surgiu porque a equipe ouviu pouco os stakeholders e praticamente não envolveu os usuários finais, então a necessidade de crescimento do varejista não apareceu no radar. A lógica correta é tratar requisitos como algo que precisa ser entendido, validado e refinado ao longo do processo. Revisões frequentes ajudam a descobrir ambiguidades, conflitos e exigências de escala antes que o sistema esteja em produção. Isso evita aquele clássico drama de depois do lançamento descobrir que o sistema até funciona, mas não aguenta o volume real de uso. Por isso, o gabarito é a letra E. Ela propõe um processo de comunicação mais eficaz, com revisões frequentes dos requisitos com stakeholders e sessões de feedback com usuários finais, exatamente o que faltou no caso narrado. Em termos de boas práticas de Engenharia de Software, isso está alinhado à Engenharia de Requisitos, que recomenda elicitação, validação e gerenciamento contínuo dos requisitos, especialmente os não funcionais. Em resumo: quando você amplia a comunicação e valida continuamente o que foi entendido, fica muito mais difícil entregar um sistema bonito no papel e sofrível na prática. Em concurso, desconfie de alternativas que prometem velocidade às custas de diálogo: quase sempre isso vira retrabalho depois.