Questão de Engenharia de Software — Engenharia de Requisitos — Quadrix 2025

Engenharia de Requisitos: participação dos stakeholders

❌ ERRADO. A análise de requisitos não deve ser feita somente pelos desenvolvedores — ela é um processo colaborativo que envolve, além da equipe técnica, os clientes, usuários finais e demais partes interessadas (stakeholders). O erro da afirmação está em restringir a atividade a um único grupo, quando a engenharia de requisitos exige justamente o contrário: a participação ativa de todos os envolvidos para identificar as reais necessidades do sistema.

A engenharia de requisitos é o processo formal, sistemático e contínuo de identificar, analisar, documentar, validar e gerenciar os requisitos de um software. Ela é considerada uma das fases mais críticas do desenvolvimento, pois um erro cometido nessa etapa compromete todo o projeto — a maioria dos defeitos de software nasce justamente na especificação de requisitos. Os requisitos são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento, refletindo as necessidades dos clientes para um sistema que serve a uma finalidade determinada.

A participação dos stakeholders é essencial porque são eles que conhecem o negócio, os processos e as necessidades reais que o software deve atender. Os desenvolvedores, por sua vez, possuem conhecimento técnico sobre como construir o sistema, mas não detêm, sozinhos, o entendimento completo do domínio do problema. A análise de requisitos é, portanto, uma atividade de comunicação e colaboração: o analista de requisitos atua como ponte entre o cliente e a equipe técnica, traduzindo as necessidades do negócio em especificações técnicas precisas.

Na prática, a análise de requisitos envolve técnicas como entrevistas, workshops, observação, questionários e prototipação, todas elas dependentes da interação com os stakeholders. Um exemplo concreto: ao desenvolver um sistema de controle de estoque para uma loja, o analista precisa conversar com o gerente (para entender as regras de negócio), com os vendedores (para entender como o sistema será usado no dia a dia) e com o setor de compras (para entender os fluxos de reposição). Se apenas os desenvolvedores participassem, o sistema poderia ser tecnicamente perfeito, mas não atenderia às necessidades reais dos usuários.

A distinção que importa aqui é entre requisitos de usuário e requisitos de sistema. Os requisitos de usuário são declarações em linguagem natural, mais abstratas, escritas principalmente para gerentes, usuários finais e arquitetos. Os requisitos de sistema são descrições mais detalhadas das funções, serviços e restrições operacionais, voltadas para a equipe técnica. Ambos são essenciais, e a análise de requisitos precisa capturar os dois níveis — o que só é possível com a participação conjunta de todos os envolvidos.

A pegadinha que a banca explora nesta questão é a generalização indevida: a afirmação usa o termo "somente" para restringir a análise de requisitos aos desenvolvedores, quando a prática da engenharia de software exige uma abordagem colaborativa. O candidato que conhece o conceito de engenharia de requisitos percebe imediatamente que a participação dos stakeholders é um princípio fundamental dessa disciplina.

Guarde o critério decisivo: a análise de requisitos é uma atividade colaborativa, que envolve desenvolvedores, clientes, usuários e demais partes interessadas — nunca exclusiva de um único grupo. É exatamente essa fronteira que separa a afirmação correta da incorreta.

❌ ERRADO. A análise de requisitos não é uma atividade exclusiva dos desenvolvedores. Ela exige a participação colaborativa de todos os stakeholders — clientes, usuários finais, analistas de negócio e a própria equipe técnica — para identificar corretamente as necessidades do sistema. A afirmação erra ao usar o termo "somente", que exclui indevidamente os demais envolvidos do processo.

Gabarito: ERRADO.