Grátis: A elicitação de requisitos é o processo de identificar, compreender e documentar as necessidades, expectativas e restrições dos stakeholders em rel... – Questões Respondidas

Gestão de Custos

Outros

A elicitação de requisitos é o processo de identificar, compreender e documentar as necessidades, expectativas e restrições dos stakeholders em relação a um sistema de software. É uma etapa crucial na engenharia de requisitos, pois estabelece a base para o desenvolvimento de um sistema que atenda às demandas dos usuários finais.
Com base nas informações apresentadas, avalie as asserções a seguir e a relação proposta entre elas:

I. O desenvolvimento de software é uma área transversal e integralizadora em qualquer ramo de negócios, não existe apenas por existir.

PORQUE

II. As necessidades do usuário surgem de suas rotinas e problemas levantados na ponta, nas áreas e processos de negócio.

A respeito dessas asserções, assinale a opção correta:
I. O desenvolvimento de software é uma área transversal e integralizadora em qualquer ramo de negócios, não existe apenas por existir.
II. As necessidades do usuário surgem de suas rotinas e problemas levantados na ponta, nas áreas e processos de negócio.
A As asserções I e II são verdadeiras, mas a II não é uma justificativa correta da I.
B As asserções I e II são verdadeiras, e a II é uma justificativa correta da I.
C A asserção I é uma proposição verdadeira e a II é uma proposição falsa.
D A asserção I é uma proposição falsa e a II é uma proposição verdadeira.

Questões para o Sucesso

há 3 dias

Questões para o Sucesso

há 3 dias

Avaliação I - Individual 2

UNIASSELVI

Respostas

Ed

há 3 dias

Vamos analisar as asserções: I. O desenvolvimento de software é uma área transversal e integralizadora em qualquer ramo de negócios, não existe apenas por existir. Verdadeiro. O desenvolvimento de software está presente em diversos setores e é fundamental para integrar processos e atender demandas específicas. II. As necessidades do usuário surgem de suas rotinas e problemas levantados na ponta, nas áreas e processos de negócio. Verdadeiro. As necessidades dos usuários realmente emergem do dia a dia, das rotinas e dos problemas enfrentados nas áreas de negócio. Agora, a relação entre elas: A asserção II justifica a I, pois o fato de as necessidades surgirem das rotinas e problemas das áreas de negócio explica por que o desenvolvimento de software é transversal e integralizador, pois ele deve atender essas demandas específicas. Portanto, a alternativa correta é: B) As asserções I e II são verdadeiras, e a II é uma justificativa correta da I.

Essa resposta te ajudou?

0

0

Ainda não achou a resposta?

Integrado com os principais modelos de IA do mercado
Respostas em segundos
IA treinada para estudantes brasileiros.

Evolua sua forma de estudar

Cadastre-se ou realize login

Ainda com dúvidas?

Envie uma pergunta e tenha sua dúvida de estudo respondida!

Essa pergunta também está no material:

Avaliação I - Individual 2

UNIASSELVI

Mais perguntas desse material

A análise das partes interessadas é realizada a partir do momento que a necessidade de negócio é identificada, e será uma atividade contínua durante o processo de análise de requisitos. O primeiro passo do processo de análise das partes interessadas é identificar as partes interessadas, os papéis, responsabilidades e autoridade sobre os requisitos que cada parte detém ou é afetada.
Com base nas informações apresentadas, avalie as asserções a seguir e a relação proposta entre elas:
I. Não há necessidade de se identificar a influência ou autoridade de cada uma das partes interessadas.
II. Nem todas as validações e aprovação de requisitos são realizadas pela equipe de desenvolvimento e partes interessadas.
A As asserções I e II são verdadeiras, mas a II não é uma justificativa correta da I.
B As asserções I e II são falsas.
C A asserção I é uma proposição verdadeira e a II é uma proposição falsa.
D A asserção I é uma proposição falsa e a II é uma proposição verdadeira.

O design thinking segue uma lógica dedutiva, partindo de princípios fundamentais para chegar a conclusões específicas. Ao observar e entender as necessidades e desafios dos usuários, os designers podem definir problemas de forma clara e identificar oportunidades de melhoria. Uma das etapas fundamentais do design thinking é a imersão no contexto do usuário. Isso envolve empatia, através da observação direta e do diálogo com os usuários, a fim de compreender suas necessidades reais. Ao obter insights valiosos sobre as experiências e perspectivas dos usuários, os designers podem deduzir quais são os problemas-chave que precisam ser resolvidos.
De acordo com a abordagem pautada em Design Thinking e a Elicitação de Requisitos, analise as afirmativas a seguir:
I. A prototipagem rápida e a experimentação são elementos essenciais do design thinking, permitindo que os designers testem e refinem suas soluções com base no feedback dos usuários.
II. A imersão no contexto do usuário é uma etapa fundamental do design thinking, que envolve empatia e compreensão das necessidades reais dos usuários, buscando entender suas dores, necessidades e comportamentos.
III. A fase de ideação no design thinking estimula a geração de um grande volume de ideias sem restrições, pois é importante que seja encorajado o uso de métodos para explorar a criatividade dos participantes e estimular o pensamento criativo.
IV. O design thinking é capaz de resolver qualquer problema, pois ele extrapola qualquer escopo e delimitação de necessidade, do mais simples ao mais complexo, visando trazer a solução mais inovadora, independentemente de seu custo ou de seu escopo.
A II e III, apenas.
B I, II e III, apenas.
C II, III e IV, apenas.
D III e IV, apenas.

As falhas de projeto de software são problemas que ocorrem quando a concepção e a arquitetura do software não atendem aos requisitos, levando a consequências negativas no desempenho, usabilidade, segurança ou manutenibilidade do sistema. Essas falhas podem resultar em atrasos, custos adicionais e até mesmo no fracasso do projeto.
Com base nas informações apresentadas, avalie as asserções a seguir e a relação proposta entre elas:
I. O esforço de comunicação contínua entre as equipes de desenvolvimento e de negócios existe para extrair o máximo de requisitos de qualidade para o projeto, mesmo quando esses parecem muito óbvios para apenas uma das partes.
PORQUE
II. O engenheiro de requisitos, embora seja obrigado a conhecer tudo sobre todos os negócios, há sempre a necessidade de validação dos requisitos que podem ser considerados básicos demais pelas partes interessadas.
A As asserções I e II são verdadeiras, mas a II não é uma justificativa correta da I.
B A asserção I é uma proposição falsa e a II é uma proposição verdadeira.
C A asserção I é uma proposição verdadeira e a II é uma proposição falsa.
D As asserções I e II são verdadeiras, e a II é uma justificativa correta da I.

O modelo incremental é um paradigma de desenvolvimento de software que se baseia na construção e entrega de incrementos funcionais do sistema ao longo do tempo. Diferentemente do modelo em cascata, que segue uma abordagem linear e sequencial, o modelo incremental permite a entrega de valor mais cedo no processo de desenvolvimento, trazendo consigo uma série de vantagens. Uma das principais vantagens do modelo incremental é a capacidade de obter feedback dos usuários e stakeholders de forma mais rápida. Como o sistema é desenvolvido em etapas incrementais, cada incremento pode ser entregue e avaliado individualmente. Isso permite que os usuários testem e validem as funcionalidades já implementadas, fornecendo feedback valioso para orientar o desenvolvimento subsequente. Essa abordagem iterativa e interativa reduz o risco de desenvolver um sistema que não atenda às expectativas dos usuários.
Sobre o modelo incremental e seu uso, analise as afirmativas a seguir:
I. O modelo incremental é baseado em uma abordagem linear e sequencial, havendo só um produto final no projeto, para entrega às partes interessadas.
II. O modelo incremental apresenta como vantagem a capacidade de obter feedback dos usuários de forma mais rápida, entregando partes do produto a cada iteração.
III. O modelo incremental permite a adaptação às mudanças de requisitos ao longo do tempo, prevendo um “ponto de retorno” e entregando resultado de forma mais rápida ao usuário.
IV. O modelo incremental prevê que na entrega de cada incremento não existam benefícios tangíveis antes da conclusão total do projeto, pois somente com o produto por completo pode ocorrer a validação.
A II e III, apenas.
B I e IV, apenas.
C III e IV, apenas.
D I, II e III, apenas.

O International Institute of Business Analysis (IIBA) é uma organização profissional global dedicada ao avanço da disciplina de análise de negócios, que contempla, entre outras, a gerência de requisitos de software, elemento fundamental que envolve as partes interessadas, papéis e responsabilidades num projeto.
Com base no texto e nos conhecimentos sobre Engenharia de Requisitos, a lista de partes interessadas, papéis e responsabilidades que deve conter, analise as afirmativas a seguir:
I. Identificação da linguagem de programação utilizada.
II. Descrição da influência e interesse das partes interessadas.
III. Nome e cargo das partes interessadas envolvidas no processo.
A II e III, apenas.
B III, apenas.
C I e II, apenas.
D I, apenas.
E II, apenas.

O ciclo de vida de desenvolvimento de software é uma abordagem sistemática para criar, manter e aprimorar programas de computador. Ele abrange todas as etapas desde a concepção inicial até a entrega do produto final e seu subsequente suporte. O ciclo de vida do desenvolvimento de software geralmente inicia-se na fase de Engenharia de Requisitos, onde requisitos são coletados e documentados. Isso envolve entender as necessidades do cliente, definir os recursos e funcionalidades do software e estabelecer metas claras.
Sobre o ciclo de desenvolvimento de software, sendo a Engenharia de Requisitos uma das fases mais importantes, classifique V para as sentenças verdadeiras e F para as falsas:
( ) Errar no processo de requisitos pode levar a problemas significativos no desenvolvimento de software, como a entrega de um produto que não atende às necessidades dos usuários ou que possui funcionalidades incorretas.
( ) Investir tempo e esforço na atividade de engenharia de requisitos é fundamental para evitar erros e garantir que os requisitos sejam compreendidos corretamente e atendidos de forma adequada no desenvolvimento do software.
( ) Aplicar a engenharia de requisitos é um exercício de se concentrar na identificação, análise, documentação e validação das necessidades e restrições de um sistema de software.
( ) Analisar a Engenharia de Requisitos é entender que trata-se de uma abordagem linear e sequencial, em que cada fase é concluída antes de passar para a próxima.
A V, V, F, F.
B F, V, V, F.
C V, V, V, F.
D V, F, F, V.

Um engenheiro de requisitos deve ter um bom entendimento de como as organizações e seus negócios funcionam. Isso ocorre porque os requisitos de um sistema de software estão intimamente ligados aos processos e às necessidades da organização em questão. Ao compreender os objetivos, as estratégias e as operações da organização, o engenheiro de requisitos é capaz de identificar e documentar requisitos que realmente atendam às necessidades dos stakeholders. Esse conhecimento profundo das características do negócio permite ao engenheiro de requisitos tomar decisões mais informadas ao definir os requisitos funcionais e não funcionais do sistema.
Um Engenheiro de Requisitos deve tentar ao máximo se aprofundar no conhecimento de negócio de uma empresa para a qual está trabalhando para um projeto de software. No entanto, é uma tarefa muito difícil conhecer todos os detalhes e processos para o bom andamento do projeto, assim, este profissional deve contar com:
I. Contar histórias sobre como a tecnologia pode mudar os rumos da empresa, se bem utilizada e empregada.
II. Elaborar um questionário, anônimo, a ser aplicado para cada integrante da equipe de negócios, visando facilitar o seu trabalho na elicitação de requisitos.
III. Mapear as principais partes interessadas, quem aprova as mudanças de requisitos, quem tem melhor conhecimento sobre a regra de negócios e quem apenas aceita as mudanças.
IV. Entender que é a organização quem deve ter um conhecimento de suas necessidades de forma clara, cabendo ao engenheiro de requisitos a melhor forma de extrair essa informação.
A II e III, apenas.
B III e IV, apenas.
C I e IV, apenas.
D I, II e III, apenas.

O processo de desenvolvimento de software possui o caráter iterativo e adaptável do processo de desenvolvimento de software, é uma prática moderna essencial que permite que os projetos avancem com maior eficiência, respondendo de forma mais eficaz às demandas do mercado e garantindo a satisfação dos clientes e usuários ao entregar um produto alinhado com suas expectativas.
Sobre o processo de desenvolvimento de software, pode-se afirmar que o objetivo do ciclo de vida de desenvolvimento de software é:
A Fazer um software sofisticado e interativo.
B Trazer todas as funcionalidades possíveis, mesmo as não validadas.
C Garantir que o software tenha um design moderno.
D Garantir que o produto final atenda às expectativas e necessidades dos usuários.
E Adequar a substituição de um software legado.

Durante a fase de coleta de requisitos de software, é comum que a equipe de desenvolvimento interaja com diversos usuários para compreender suas necessidades e expectativas em relação ao sistema a ser desenvolvido. Nesse processo, pode surgir um usuário insistente, alguém que demonstra uma forte determinação em fazer valer suas opiniões e demandas.
Sobre algumas estratégias que um engenheiro de requisitos pode utilizar no convencimento de um usuário resistente, classifique V para as sentenças verdadeiras e F para as falsas:
( ) Ter clareza na demonstração dos benefícios do novo sistema, como por exemplo, demonstrar que a nova funcionalidade pode eliminar o uso de planilhas de controle, demonstrando as vantagens que isso gera ao usuário resistente e seu ganho e otimização de tempo.
( ) Deixar claro que será oferecido treinamento e suporte ao novo sistema, adaptando as rotinas de trabalho ao uso do sistema, demonstrando que o usuário estará amparado durante esse processo.
( ) Negar as preocupações do usuário, pois além dos requisitos levantados são uma pequena parte de todo o projeto, não sendo de grande importância.
( ) Trazer temas técnicos e complexos ao entendimento do usuário, como a linguagem de programação utilizada e os paradigmas utilizados para a implementação do código.
A F, V, V, F.
B V, V, V, F.
C V, V, F, F.
D V, F, F, V.