Questão de Engenharia de Software — Geral — FCC 2025
Engenharia de Software›Geral
Código
fc150557
Banca
FCC
Órgão
TRT 2
Ano
2025
Cargo
AJ TRT2
Durante o desenvolvimento de um novo sistema para gestão de pautas de audiências e notificações no âmbito da Justiça do Trabalho, a equipe de TI de um TRT detectou grande variação nos requisitos repassados pelas secretarias das varas, ocasionando mudanças frequentes nos critérios de notificação, conforme determinações da corregedoria regional.
Diante desse cenário, o coordenador do projeto propôs a adoção de um modelo de processo evolutivo, aliado a práticas formais de elicitação e validação de requisitos, com uso de protótipos e interação com os usuários finais.
Com base nessa situação, representa a prática mais adequada de engenharia de software e de requisitos, nesse contexto,
Atrabalhar com requisitos fixos definidos exclusivamente com o setor de TI, evitando interferência de usuários que podem gerar instabilidade no escopo.
Bpriorizar o desenvolvimento técnico sobre o levantamento de requisitos, aplicando práticas de refatoração contínua, como principal mecanismo de adaptação.
Cadotar o modelo em cascata com levantamento extensivo de requisitos no início, seguido por uma fase de análise congelada para evitar mudanças durante o desenvolvimento.
Dadotar um processo incremental com ciclos curtos, utilizando técnicas como prototipação e validação contínua com os usuários para capturar requisitos instáveis e que podem mudar frequentemente.
Eutilizar o modelo Big Bang para entregar uma versão única e final do sistema após a coleta inicial de requisitos, favorecendo rapidez na entrega.
Revelar gabarito e comentário▾
GabaritoD — adotar um processo incremental com ciclos curtos, utilizando técnicas como prototipação e validação contínua com os usuários para capturar requisitos instáveis e que podem mudar frequentemente.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Modelos de processo de software e requisitos instáveis
Gabarito: letra D. Em cenários de requisitos instáveis e sujeitos a mudanças frequentes, a prática mais adequada é adotar um processo incremental com ciclos curtos, aliado à prototipação e à validação contínua com os usuários — exatamente o que a alternativa D descreve. Essa abordagem permite capturar e refinar requisitos em evolução, reduzindo riscos e garantindo que o produto final atenda às reais necessidades dos usuários.
O cenário apresentado é clássico em engenharia de software: requisitos que mudam com frequência, influenciados por determinações externas (no caso, da corregedoria regional). Modelos tradicionais, como o cascata, pressupõem requisitos estáveis e bem compreendidos desde o início — o que não se aplica aqui. Modelos evolucionários, como o incremental e a prototipação, foram concebidos justamente para lidar com essa incerteza.
O modelo incremental divide o desenvolvimento em incrementos (builds), cada um entregando um subconjunto funcional do sistema. Isso permite que o usuário avalie cada entrega e forneça feedback, que realimenta o ciclo. A prototipação, por sua vez, é uma técnica que auxilia na elicitação e validação de requisitos, permitindo que os interessados visualizem e experimentem uma versão inicial do sistema antes da implementação final. Sommerville destaca que a prototipação ajuda a compreender melhor o que está para ser construído, sendo útil tanto na engenharia de requisitos quanto no projeto de interface.
A combinação dessas práticas é especialmente eficaz quando os requisitos são instáveis, pois permite:
Feedback contínuo: o usuário valida cada incremento, reduzindo o risco de retrabalho.
Adaptação a mudanças: novas determinações podem ser incorporadas nos ciclos seguintes.
Redução de incerteza: protótipos ajudam a clarificar requisitos ambíguos.
A alternativa D sintetiza exatamente essa abordagem: "processo incremental com ciclos curtos, utilizando técnicas como prototipação e validação contínua com os usuários para capturar requisitos instáveis e que podem mudar frequentemente". É a prática mais alinhada aos princípios da engenharia de software moderna para lidar com requisitos voláteis.
As demais alternativas propõem abordagens inadequadas: requisitos fixos sem participação do usuário (A), priorizar desenvolvimento técnico sobre levantamento (B), modelo cascata com análise congelada (C) e modelo Big Bang (E) — todas ignoram a natureza dinâmica dos requisitos no contexto descrito.
1Elicitação de requisitos
2Prototipação
3Validação com usuários
4Incremento entregue
5Feedback realimenta ciclo
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Trabalhar com requisitos fixos definidos exclusivamente com o setor de TI, evitando interferência de usuários, contraria o princípio fundamental da engenharia de requisitos: os requisitos devem ser elicitados a partir dos stakeholders, especialmente dos usuários finais. Ignorar os usuários em um cenário de requisitos instáveis agravaria o problema, pois o sistema não atenderia às necessidades reais e as mudanças seriam ainda mais difíceis de gerenciar.
Alternativa B — ❌ Incorreta
Priorizar o desenvolvimento técnico sobre o levantamento de requisitos, usando refatoração contínua como principal mecanismo de adaptação, é uma abordagem reativa e insuficiente. A refatoração melhora a estrutura interna do código, mas não substitui a elicitação e validação de requisitos — que são a base para saber o que construir. Sem requisitos bem compreendidos, a refatoração apenas reorganiza um sistema que pode estar atendendo às necessidades erradas.
Alternativa C — ❌ Incorreta
O modelo em cascata com levantamento extensivo de requisitos no início e análise congelada é inadequado para requisitos instáveis. O cascata pressupõe que os requisitos são bem compreendidos e estáveis, o que não é o caso. Congelar a análise impediria a adaptação às mudanças frequentes, levando a um produto desalinhado com as necessidades atuais.
Alternativa D — ✅ Correta ⟵ GABARITO
A alternativa descreve exatamente a prática recomendada: processo incremental com ciclos curtos, prototipação e validação contínua com os usuários. Essa abordagem é projetada para lidar com requisitos instáveis, permitindo feedback frequente e adaptação a mudanças. A prototipação auxilia na elicitação e validação, enquanto os ciclos curtos garantem entregas parciais que podem ser avaliadas e ajustadas.
Alternativa E — ❌ Incorreta
O modelo Big Bang, que entrega uma versão única e final após a coleta inicial de requisitos, é o oposto do que se recomenda para requisitos instáveis. Ele assume que todos os requisitos são conhecidos e estáveis desde o início, o que não se aplica ao cenário. Além disso, a entrega única aumenta o risco de falhas e retrabalho, pois não há feedback intermediário.