

Seu próximo nível começa aqui
Com a Assinatura Ilimitada, você tem tudo que precisa para sua aprovação.
Com a Assinatura Ilimitada, você combina prática, teoria e método em uma única assinatura com tudo que você precisa para sua aprovação.
Técnicas de investigação (elicitação de requisitos) são essenciais para compreender as necessidades das partes interessadas.
Observe a figura abaixo que representa o ciclo de uma técnica de investigação:

Assinale a alternativa que indica corretamente a técnica que melhor segue esse ciclo de investigação
Entrevista estruturada com roteiro predefinido, coleta de informações diretas, análise das respostas, apresentação dos requisitos aos stakeholders e documentação final.
Observação passiva e não estruturada do ambiente organizacional, sem interação com os usuários, seguida de análise imediata e documentação dos resultados sem validação junto às partes interessadas.
Envio de questionários eletrônicos por e-mail, com posterior análise automática das respostas e publicação direta dos requisitos, sem etapas formais de revisão ou feedback dos stakeholders.
Realização de uma única reunião com todos os stakeholders, baseada em discussões livres e não guiadas, resultando em documentação informal e sem consolidação sistemática das informações coletadas.
Leitura de documentação histórica de projetos anteriores, sem contato direto com stakeholders atuais, utilizando a reutilização integral de requisitos como principal fonte de levantamento.
No contexto da Engenharia de Requisitos, uma equipe de desenvolvimento identifica que o sistema de pagamentos de uma funcionalidade da prefeitura “deve ser capaz de processar 1.000 transações por segundo sob carga máxima” e que “o sistema deve ser desenvolvido obrigatoriamente na linguagem Java, seguindo o padrão de arquitetura de microserviços do município”.
Com base nas definições clássicas de requisitos, as duas sentenças acima classificam-se, respectivamente, como:
Regra de Negócio e Requisito Não Funcional (Confiabilidade).
Requisito de Usuário e Requisito Funcional.
Requisito Não Funcional (Performance) e Restrição de Design/Implementação.
Requisito Não Funcional (Usabilidade) e Requisito de Sistema.
Requisito Funcional e Requisito de Regra de Negócio.
A análise de requisitos é uma atividade fundamental da Engenharia de Software, responsável por identificar, analisar e documentar os serviços que o sistema deve fornecer e as restrições sob as quais ele deve operar.
Assinale a alternativa correta considerando a abordagem apresentada pelo autor.
Os requisitos de usuário e de sistema possuem o mesmo nível de detalhamento, diferenciando-se apenas pelo público ao qual se destinam.
A análise de requisitos tem como objetivo principal transformar requisitos não funcionais em requisitos funcionais, garantindo que todos sejam implementados diretamente no código.
A atividade de análise de requisitos envolve necessariamente a detecção e resolução de conflitos, ambiguidades e inconsistências, sendo um processo iterativo e fortemente dependente da interação com os stakeholders.
A análise de requisitos deve ser concluída integralmente antes do início do projeto do sistema, uma vez que alterações posteriores comprometem a qualidade do software.
Os requisitos funcionais são mais importantes que os requisitos não funcionais, pois estes não afetam a arquitetura ou o desempenho do sistema.
A prefeitura municipal de Florianópolis pretende modernizar seu sistema de gestão de processos. O analista de requisitos percebe que os diversos setores envolvidos (Jurídico, Administrativo e TI) possuem visões conflitantes sobre as prioridades do novo software. Para resolver esses conflitos e obter um consenso rápido sobre os requisitos, o analista sugere a realização de sessões de trabalho estruturadas, facilitadas por um moderador neutro, envolvendo tanto os usuários finais quanto a equipe técnica.
Essa abordagem de elicitação, que visa acelerar o levantamento e reduzir erros de interpretação por meio de reuniões intensivas, é tecnicamente conhecida como:
Prototipação Evolucionária, focada na entrega de versões incrementais para teste.
Benchmarking, por comparar o sistema atual com soluções de mercado.
Entrevista Estruturada, pois foca na coleta de dados com roteiro rígido.
JAD (Joint Application Design) ou Design em conjunto de Aplicações, que utiliza sessões colaborativas para definir requisitos.
Etnografia, baseada na observação direta do comportamento do usuário no ambiente de trabalho.
O IFCE iniciará o desenvolvimento de um sistema para gestão de estágios. O analista de tecnologia da informação identificou que existem diferentes perfis envolvidos (alunos, coordenadores de curso, setor de convênios e empresas parceiras), com necessidades distintas e pouco documentadas. Para compreender expectativas, conflitos e regras implícitas do processo, o profissional optou por reunir representantes desses grupos em sessões estruturadas de discussão coletiva, conduzidas por facilitador, com objetivo de levantar requisitos de forma colaborativa.
Considerando as técnicas de elicitação de requisitos, é correto afirmar que a técnica descrita se refere
à prototipação evolutiva, pois o sistema é implementado diretamente para validação posterior.
à análise de documentos, pautada na extração de requisitos a partir de regulamentos institucionais e normas vigentes.
ao questionário estruturado aplicado individualmente aos usuários, sem interação entre eles.
ao workshop de requisitos (JAD – Joint Application Development), com participação colaborativa dos stakeholders.
ao teste de sistema, pois os requisitos são identificados durante a execução do software já implementado.


Seu próximo nível começa aqui

Seu próximo nível começa aqui
Destrave a preparação completa para sua aprovação. Com a Assinatura Ilimitada, você estuda com os melhores professores do Brasil e todos os recursos Gran.
Dentre as principais técnicas de elicitação (ou levantamento de requisitos, ou elicitação de requisitos - ER) podem ser identificadas as técnicas onde pessoas participam de encontros (Interação Humana), presenciais ou virtuais.
Relacione as técnicas de elicitação de requisitos no desenvolvimento de software com as suas características:
1. Brainstorming.
2. Workshop.
3. Feedback.
4. Focus Group
( ) Discussão objetiva que introduz um tópico a um grupo de participantes e direciona sua discussão sobre o tema, de uma maneira não-estruturada.
( ) Técnica colaborativa para definir os requisitos de um software e pode ser utilizado para esclarecer ambiguidades
( ) Técnica que propicia aos participantes a sensação de que suas ideias são importantes e pode levar à convergência de opiniões.
( ) Reunião na qual cada participante pode expressar livremente os requisitos do sistema, sendo uma maneira de sintonizar a mente do usuário em relação aos requisitos.
Assinale a opção que indica a relação correta na ordem apresentada.
1 – 2 – 3 – 4.
4 – 3 – 2 – 1.
3 – 4 – 1 – 2.
4 – 2 – 3 – 1.
2 – 1 – 4 – 3.
Em um projeto de desenvolvimento de um sistema de controle de frotas para uma empresa de logística, o Analista de Sistemas precisa garantir que os requisitos levantados junto aos motoristas e gerentes sejam claros e consistentes antes de iniciar a fase de design. O Analista descobriu que há requisitos contraditórios sobre a forma como o rastreamento deve ser feito em tempo real versus por paradas programadas.
Assinale a opção que apresenta a tarefa da Engenharia de Requisitos primariamente responsável por identificar e resolver inconsistências ou contradições como a descrita, transformando a informação bruta dos stakeholders em um modelo coerente.
Elicitação de Requisitos, pois a contradição foi descoberta durante a coleta de dados.
Validação de Requisitos, pois é a tarefa final que aprova formalmente a coerência do documento e o tratamento dos conflitos.
Gerenciamento de Requisitos, pois a contradição deve ser registrada em um log de problemas e controlada.
Análise de Requisitos, por tratar o processo de refinar, classificar e modelar os requisitos, incluindo a resolução de conflitos.
Especificação de Requisitos, pois a formalização no documento evita que as contradições e conflitos se manifestem.
A reengenharia é um processo aplicado a sistemas já existentes com o propósito de compreendê-los e aprimorá-los, podendo envolver diferentes atividades técnicas ao longo de sua execução. Durante esse processo, há uma etapa específica em que o programa é analisado e as informações são extraídas a partir dele. Isso ajuda a documentar sua organização e funcionalidade. Essa etapa é denominada
reestruturação de código.
refatoração.
engenharia reversa.
manutenção evolutiva.
modernização incremental.
Relacione as técnicas de elicitação de requisitos no desenvolvimento de software com as suas características:
1. Teste de aceitação do usuário (UAT)
2. Teste de desempenho
3. Teste de carga
4. Teste de usabilidade
( ) Testa como o software funciona sob diferentes cargas de trabalho.
( ) Avalia o funcionamento sob condições reais de balanceamento de carga.
( ) Confirma se o sistema atende às necessidades de usuários e se funciona em cenários reais.
( ) Avalia o uso da interface de usuário de um sistema para concluir uma tarefa de forma eficiente e intuitiva.
Assinale a opção que indica a relação correta na ordem apresentada.
3 – 4 – 1 – 2.
4 – 3 – 2 – 1.
2 – 3 – 1 – 4.
1 – 2 – 4 – 3.
2 – 3 – 4 – 1.
Durante o desenvolvimento de um sistema de controle acadêmico, a equipe de Engenharia de Requisitos identificou que diferentes usuários finais e gestores institucionais apresentaram necessidades divergentes quanto às regras de acesso aos históricos escolares. Enquanto um grupo solicita acesso irrestrito, outro defende restrições baseadas em perfis e prazos legais. No contexto do Processo de Engenharia de Requisitos, a etapa responsável por identificar, discutir e resolver conflitos entre requisitos provenientes de diferentes stakeholders visando um acordo é a fase de:
Validação.
Análise e Negociação.
Especificação Técnica.
Elicitação e Descoberta.


Seu próximo nível começa aqui
Seu desenvolvimento não pode ter limites. Garanta sua Assinatura Ilimitada e libere uma preparação completa com os melhores professores do Brasil.
Durante a fase de elicitação de requisitos para um novo sistema de informação governamental, a equipe de analistas de um órgão público federal se depara com o desafio de escolher a abordagem mais eficaz para garantir que as necessidades de todos os stakeholders sejam compreendidas e documentadas de forma clara e precisa, considerando a complexidade do ambiente público.
Analise as seguintes proposições sobre as práticas de Engenharia de Requisitos no contexto do setor público:
I. A elicitação de requisitos deve se concentrar exclusivamente em entrevistas com os gestores de alto escalão, pois eles possuem a visão estratégica completa e as necessidades dos usuários finais são secundárias no desenvolvimento de sistemas governamentais.
II. A utilização de múltiplos métodos de elicitação, como entrevistas, questionários, workshops e prototipação, tende a ser mais eficaz para capturar a diversidade de requisitos em um ambiente complexo como a administração pública, minimizando o risco de omissões.
III. A documentação de requisitos em UML, por meio de diagramas de Casos de Uso, pode ser uma prática recomendada para descrever as interações entre os atores (usuários e sistemas externos) e o sistema, facilitando a comunicação e a validação com as partes interessadas.
Está correto o que se afirma em:
III, apenas.
II e III, apenas.
II, apenas.
I, II e III.
I e II, apenas.
Durante o levantamento de requisitos para o desenvolvimento de um novo sistema de gestão de financiamentos em uma agência de fomento governamental, um Analista de Sistemas decidiu compreender melhor como os servidores executam suas atividades no dia a dia. Para isso, o Analista passou um período acompanhando diretamente o trabalho dos funcionários no ambiente em que o sistema será utilizado, observando as atividades realizadas e registrando anotações sobre as tarefas executadas. Essa abordagem permitiu identificar práticas informais e requisitos implícitos que não estavam documentados nos processos oficiais da organização, refletindo a forma real como as pessoas trabalham. Considerando as técnicas utilizadas na Engenharia de Requisitos, a técnica de elicitação descrita no caso é denominada:
Brainstorming.
Prototipação.
Joint Application Development (JAD)
Workshop de requisitos.
Etnografia.
O IFCE pretende desenvolver uma nova plataforma para atendimento digital aos estudantes. Antes da definição dos requisitos técnicos, o analista de tecnologia da informação propôs conduzir oficinas com alunos e servidores para compreender dificuldades enfrentadas no uso dos sistemas atuais, gerar ideias de solução e criar protótipos para validação inicial. Considerando os princípios do Design Thinking, é correto afirmar que essa abordagem
tem por base o desenvolvimento do sistema em requisitos previamente documentados pela área administrativa, priorizando a documentação formal em detrimento da interação direta com usuários.
conduz entrevistas e observações com usuários, define o problema com base nos insights obtidos, gera ideias, prototipa soluções e as testa de forma iterativa.
estabelece a escolha da arquitetura tecnológica como etapa prioritária, precedendo a análise das necessidades e expectativas dos usuários finais.
elabora documentação completa do sistema antes de qualquer validação com usuários finais.
efetua a implementação direta em ambiente de produção, postergando a coleta de feedback para o período posterior à implantação definitiva do sistema.
Uma agência reguladora de transporte iniciou um projeto para desenvolver um sistema de cadastro e acompanhamento de permissões de transporte intermunicipal utilizando Scrum. Durante a primeira Sprint, o time percebeu que as User Stories relacionadas aos critérios de elegibilidade para concessão de permissões estavam muito genéricas e não refletiam adequadamente as necessidades dos fiscais de transporte e dos operadores do sistema. O Product Owner precisa realizar novas sessões de elicitação antes da próxima Sprint Planning. Considerando os princípios do Scrum e as técnicas de levantamento de requisitos, a abordagem que melhor se alinha às práticas ágeis para refinar essas User Stories, mantendo o time produtivo, é:
Promover sessões de Product Backlog Refinement envolvendo Product Owner, Development Team e representantes dos fiscais de transporte, utilizando técnicas como entrevistas colaborativas e análise de documentos regulatórios para detalhar as User Stories, definir critérios de aceitação claros e manter o fluxo contínuo da Sprint.
Agendar uma reunião extraordinária de três horas com todos os stakeholders da agência, incluindo diretores e fiscais, para realizar entrevistas estruturadas e documentar especificações detalhadas em formato tradicional, suspendendo temporariamente as atividades da Sprint atual até conclusão da documentação completa.
Realizar workshops colaborativos com os fiscais utilizando técnicas de prototipação e observação direta das operações, documentar os requisitos levantados em relatórios formais e apresentar para aprovação da alta gestão antes de iniciar o refinamento das User Stories com o Development Team.
Conduzir sessões de brainstorming exclusivamente com o Development Team para identificar possíveis requisitos técnicos, criar documentação de arquitetura detalhada e, posteriormente, validar as premissas através de questionários enviados por e-mail aos usuários finais do sistema.
Organizar reuniões individuais sequenciais com cada fiscal de transporte aplicando técnicas de entrevistas não estruturadas, consolidar todas as informações coletadas em um documento de requisitos Único e solicitar que o Scrum Master priorize os itens antes de inclui-los no Product Backlog.
Durante o desenvolvimento de um sistema de informação, a equipe responsável identificou a necessidade de compreender claramente o que o sistema deve fazer e quais restrições devem ser observadas para que ele atenda às expectativas dos usuários e às condições impostas pelo ambiente organizacional. Para evitar retrabalho e falhas de entendimento ao longo do projeto, a equipe decidiu adotar uma abordagem adequada para lidar com essas necessidades.
Diante desse cenário, assinale a opção que descreve a melhor abordagem para atender às necessidades descritas.
priorizar, detalhar e validar exclusivamente requisitos não funcionais, sem especificar as funcionalidades do sistema
definir, documentar e controlar apenas os requisitos funcionais, desconsiderando-se restrições não funcionais do projeto
levantar, registrar e validar requisitos somente após a conclusão do desenvolvimento do sistema, para evitar retrabalho
registrar, ajustar e revisar requisitos de forma informal, sem processo estruturado, conforme o projeto evoluir
levantar, registrar e validar requisitos funcionais e não funcionais nas fases iniciais, considerando-se usuários e restrições


Seu próximo nível começa aqui

Seu próximo nível começa aqui
Destrave a preparação completa para sua aprovação. Com a Assinatura Ilimitada, você estuda com os melhores professores do Brasil e todos os recursos Gran.
Considere um desenvolvedor que está atuando na fase de Engenharia de Requisitos de um sistema crítico para o setor público. Para isso, ele e sua equipe estão empregando múltiplas técnicas de elicitação para garantir a completude e a consistência dos requisitos.
Diante do exposto, assinale a alternativa CORRETA.
A elicitação deve priorizar técnicas baseadas em observação e análise documental, pois métodos interativos, como entrevistas e workshops, tendem a introduzir subjetividade e dificultam a padronização dos requisitos coletados.
A combinação de entrevistas com as partes interessadas, análise de sistemas existentes, observação direta e prototipação, permite capturar diferentes tipos de requisitos, bem como facilita a identificação de conflitos entre diferentes pontos de vista.
A utilização de prototipação e brainstorming é recomendada apenas em projetos com requisitos altamente voláteis, sendo desnecessária em sistemas com escopo bem definido, em que a análise de sistemas legados é suficiente para capturar as necessidades do usuário.
Em projetos com múltiplos perfis de usuários, recomenda-se focar a elicitação nos usuários finais, evitando a inclusão de patrocinadores e gestores, já que esses raramente interagem diretamente com o sistema e tendem a distorcer os requisitos com base em expectativas estratégicas.
Suponha que seja necessário proceder à elicitação de requisitos de um dos Serviços Estruturantes da plataforma digital do PDPJ-Br. Nesse sentido, a elicitação de requisitos constitui-se em uma importante atividade quando se considera o desenvolvimento de software.
Entre as técnicas que podem ser empregadas para a elicitação de requisitos, encontram-se:
normalização e padronização.
codificação e testes.
entrevistas e etnografia.
personificação e manutenção.
criptografia e lançamento.
O levantamento de requisitos é uma etapa fundamental no processo de análise de projetos, pois visa identificar necessidades, expectativas e restrições dos stakeholders em relação ao sistema a ser desenvolvido. Durante essa fase, são mapeados os requisitos funcionais e não funcionais, que servirão de base para o projeto do sistema. A análise de requisitos permite que a equipe de desenvolvimento entenda claramente as funcionalidades desejadas, os critérios de sucesso e as condições para atender aos objetivos do negócio. Esse processo orienta o desenvolvimento de soluções eficazes e alinhadas às expectativas dos usuários e stakeholders. Considerando o exposto, assinale a alternativa que apresenta a técnica que descreve como os usuários (ou “atores”) interagem com o sistema para atingir um objetivo específico, detalhando os processos do sistema e os fluxos de eventos em cenários específicos.
Benchmarking.
Protótipo.
Análise de Documentos.
Casos de uso.
Entrevista.
Durante o Processo de Engenharia de Requisitos para o novo sistema de gestão de documentos, o Analista de Sistemas identificou que dois stakeholders importantes têm requisitos conflitantes sobre a funcionalidade de arquivamento. Um exige arquivamento imediato e o outro exige retenção por 90 dias.
A fase do Processo de Engenharia de Requisitos é responsável por resolver essas inconsistências e conflitos entre requisitos e stakeholders é
Elicitação.
Especificação.
Análise e Negociação.
Validação.
Gerenciamento.
Sobre boas práticas na identificação de demandas, assinale a alternativa correta:
Demandas não precisam de registro formal, desde que acordadas verbalmente.
Demandas devem ser priorizadas segundo impacto no negócio e alinhamento estratégico.
Demandas podem ser definidas apenas pela equipe de TI, sem consulta às áreas de negócio.
Demandas devem ser tratadas de forma igual, independentemente do valor estratégico.