Em um projeto de sistema de gestão de estoque, uma equipe técnica desenvolveu o sistema exclusivamente com base em requisitos de sistema, sem realizar o levantamento das necessidades junto aos usuários. Apesar da entrega atender aos aspectos técnicos, o cliente relatou que o sistema não correspondia às suas rotinas operacionais. Qual é a explicação mais adequada para esse problema?

Alternativa D

O problema descrito na questão ilustra uma falha clássica no processo de engenharia de requisitos, onde o foco técnico prevalece sobre a necessidade real do negócio.

Análise Detalhada

O cenário apresenta uma situação comum em projetos de software: a equipe desenvolveu algo que funciona tecnicamente, mas não resolve o problema do usuário. Vamos entender os conceitos envolvidos:

• Requisitos de Sistema: Refere-se às características técnicas e comportamentais do software sob a perspectiva da máquina (ex: velocidade, linguagem usada, banco de dados).
• Necessidades do Usuário: São as funcionalidades que resolvem problemas reais da rotina operacional do cliente.

Quando se ignora o contato com o usuário durante o planejamento, cria-se um "produto vazio": ele roda, mas não tem utilidade prática.

Análise das Alternativas

• A) Incorreta. O problema não foi ignorar requisitos não-funcionais (performance, segurança), pois o texto afirma que atendeu aos "aspectos técnicos". O erro foi não atender às "rotinas operacionais".
• B) Incorreta. O enunciado diz explicitamente que a equipe trabalhou "sem realizar o levantamento das necessidades junto aos usuários". Portanto, não foram usados requisitos de usuário.
• C) Incorreta. Houve requisitos de sistema, já que o sistema foi desenvolvido "exclusivamente com base em requisitos de sistema". A falha foi na validação com o usuário, não na técnica.
• D) Correta. Resume perfeitamente o problema: ao focar apenas na parte técnica (requisitos de sistema), a equipe perdeu a conexão com o que o usuário realmente precisava (demandas do usuário).
• E) Incorreta. Não há menção no texto sobre "flexibilidade" ou "requisitos de desempenho" sendo a causa do erro.

Conclusão

A lição principal é que Engenharia de Requisitos exige validação constante com o stakeholder (cliente/usuário). Um sistema deve ser útil antes de ser tecnicamente perfeito.

Portanto, a explicação mais adequada é que a priorização exclusiva dos requisitos de sistema comprometeu a aderência do sistema às demandas do usuário, conforme descrito na Alternativa D.