Gerência de Requisitos de Software avaliação I

Prévia do material em texto

Gerência de Requisitos de Software - Avaliação I - 
Individual 
 
1 
O modelo incremental é uma abordagem de desenvolvimento de software que divide o 
projeto em incrementos ou partes menores. Cada incremento é planejado, projetado, 
desenvolvido, testado e implantado independentemente, adicionando funcionalidades ou 
aprimorando o sistema gradualmente. 
Fonte: Adaptado de: SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: 
Pearson Addison Wesley, 2007. 
Com base no excerto, qual das seguintes opções descreve corretamente o modelo 
incremental de desenvolvimento de software? 
A 
No modelo incremental, o feedback dos usuários não é considerado, uma vez que o 
software é desenvolvido em etapas separadas 
B 
O modelo incremental divide o projeto em partes menores, entregando funcionalidades 
utilizáveis em incrementos sucessivos, visando uma entrega mais rápida ao cliente e 
permitindo maior flexibilidade nos ajustes decorrentes de mudanças. 
C 
No modelo incremental, o software é desenvolvido de forma sequencial, sem a 
possibilidade de ajustes ou melhorias ao longo do processo, sendo um exemplo claro a 
aplicação desse modelo em softwares do tipo ERP (recursos empresariais), onde se 
entrega projeto para uma área ou setor por vez. 
D 
O modelo incremental envolve a entrega de todo o software de uma só vez, após um 
longo período de desenvolvimento, onde uma etapa só começa após o término da outra, 
como ocorre num grande sistema para gestão financeira de uma multinacional. 
2 
A identificação e a mitigação precoce de falhas de requisitos são fundamentais para 
garantir o sucesso de um projeto de software, reduzindo riscos e aumentando a 
satisfação do cliente. Detectar e corrigir falhas nos requisitos logo no início do processo 
de desenvolvimento é crucial para evitar problemas que possam surgir nas fases 
posteriores do projeto. Quando os requisitos não são bem compreendidos, ou quando há 
ambiguidades ou inconsistências, podem ocorrer retrabalhos dispendiosos e atrasos 
significativos. 
Fonte: JÚNIOR, Glória. A Identificação e Mitigação de Riscos em Projetos de 
Desenvolvimento Rápidos de Jogos Digitais. Revista Gestão e Projetos. v. 6, n. 1, p. 
79-94, 2015. Disponível em: https://dialnet.unirioja.es/descarga/articulo/5178232.pdf . 
Acesso em: 14 jun. 2023. 
As falhas nos processo de engenharia de requisitos podem ocasionar diversos problemas 
na entrega e no uso de um software. Assinale a alternativa correta que caracteriza uma 
falha de requisitos refletida no software: 
A 
Em um software de cadastro de usuários de uma empresa de transporte rodoviário de 
pessoas (ônibus), há a opção de selecionar o assento indicando se é corredor ou janela. 
B 
Em um software de controle de frequência de alunos há a opção de registrar “presença”, 
“falta” ou “falta justificada”, sendo que é necessário um mínimo de 70% de 
comparecimento como critério de aprovação, cujo cálculo desconsidera o computo das 
faltas justificadas. 
C 
Em um software de uma loja de varejo, na opção carrinho de compras, o cliente só 
consegue efetuar a compra de um único item de um produto por vez, não permitindo a 
inclusão de dois ou mais itens caso ele deseje uma quantidade maior do produto. 
D 
Em um software de uma grande rede de hospitais há a opção para que o registro do 
paciente conste, de maneira opcional, uma pessoa de contato em caso de notificações e 
avisos sobre seu estado de saúde. 
3 
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. 
Fonte: Adaptado de: POHL, K.; RUPP, C. Requirements Engineering Fundamentals: 
A Study Guide for the Certified Professional for Requirements Engineering Exam – 
Foundation Level. Santa Barbara: Rocky Nook Inc., 2011. 
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. 
É correto o que se afirma em: 
A 
III e IV, apenas. 
B 
II e III, apenas. 
C 
I, II e III, apenas. 
D 
I e IV, apenas. 
4 
O risco de negócios é uma realidade inerente a qualquer organização e refere-se à 
possibilidade de ocorrerem eventos ou circunstâncias que podem afetar negativamente 
seus objetivos e resultados. Esses riscos podem surgir de diversas fontes, como 
incertezas econômicas, mudanças no mercado, falhas operacionais, eventos imprevistos 
ou falta de conformidade com regulamentações. 
Fonte: Adaptado de: DRUCKER, P. F. O gestor eficaz. 9. ed. São Paulo: Editora 
Elsevier, 2011. 
Gerenciar requisitos também envolve riscos, principalmente os de negócio. Conforme 
Pressman e Maxim, (2016), quanto aos cinco principais riscos de negócios, classifique 
V para as sentenças verdadeiras e F para as falsas: 
( ) Um risco de orçamento é aquele refletido no alto tempo para se desenvolver um 
projeto de software cujos requisitos não estão bem definidos. 
( ) Um risco gerencial pode se caracterizar quando a parte interessada (Stakeholder) 
responsável por aprovar mudanças de requisitos já não não possui alinhamento e 
harmonia com os demais integrantes da área negocial. 
( ) Um risco estratégico é refletido num software que não entrega valor de acordo com 
a estratégia de negócios global da empresa. 
( ) Um risco de mercado pode se caracterizar num sistema que atende aos requisitos 
coletados e aos interesses da empresa, gerando grande aceitação. 
Assinale a alternativa que apresenta a sequência correta: 
A 
V, V, V, F. 
B 
F, V, V, F. 
C 
V, F, F, V. 
D 
V, V, F, F. 
5 
As partes interessadas em um projeto de software desempenham um papel fundamental 
em sua concepção e sucesso. Essas partes podem incluir clientes, usuários finais, 
gerentes de projeto, desenvolvedores, analistas de negócios e especialistas em domínio. 
Cada uma dessas partes interessadas traz perspectivas únicas e objetivos específicos 
para o projeto. 
Fonte: Adaptado de: SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: 
Pearson Addison Wesley, 2007. 
Dada a importância das partes interessadas (Stakeholders) num projeto de software, 
analise as afirmativas a seguir: 
I. As partes interessadas (Stakeholders) devem ser envolvidas de forma plena para 
aumentar as chances de sucesso em projetos de software. 
II. A importância de validar e verificar os requisitos coletados existe, podendo aumentar 
ainda mais o envolvimento das partes interessadas (Stakeholders). 
III. A garantia de clareza e qualidade dos requisitos depende de uma comunicação 
constante entre a equipe de desenvolvimento de software eas partes interessadas 
(Stakeholders). 
IV. As partes interessadas (Stakeholders), muitas vezes, não fornecem detalhes óbvios 
para fazer parte do seu dia a dia de trabalho, mas que são de fundamental importância 
para o Engenheiro de Requisitos. 
É correto o que se afirma em: 
A 
I, II, III e IV. 
B 
I, II e III, apenas. 
C 
III e IV, apenas. 
D 
II e IV, apenas. 
6 
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. 
Fonte: Adaptado de: BROWN, T. Design Thinking: uma metodologia poderosa para 
decretar fim às velhas ideias. Rio de Janeiro: Alta Books, 2018. 
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. 
É correto o que se afirma em: 
A 
I, II e III, apenas. 
B 
III e IV, apenas. 
C 
II, III e IV, apenas. 
D 
II e III, apenas. 
7 
O gerenciamento de requisitos é uma atividade essencial durante o ciclo de vida de um 
projeto de software. Consiste em identificar, documentar, analisar, priorizar e controlar 
os requisitos do sistema, garantindo que eles sejam compreendidos e atendidos 
adequadamente. No entanto, é importante reconhecer que os requisitos podem mudar ao 
longo do tempo devido a diversos fatores, como mudanças nas necessidades dos 
usuários, evolução do mercado ou avanços tecnológicos. 
Fonte: Adaptado de: SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: 
Pearson Education do Brasil, 2018. 
O processo de gerenciamento de mudanças de requisitos é responsável por lidar com 
essas alterações, e envolve os seguintes processos no gerenciamento de requisitos: 
I. Desenvolver um projeto à parte com o único objetivo de atender às mudanças. 
II. Mapear os melhores desenvolvedores e implementar as mudanças antes da validação 
dos requisitos. 
III. Identificar quem será consultado e quem será apenas comunicado quanto às 
mudanças dos requisitos. 
IV. Identificar quem são as partes interessadas (Stakeholders) que têm o poder de 
propor e aprovar as mudanças. 
É correto o que se afirma em: 
A 
I, apenas. 
B 
II e IV, apenas. 
C 
I, II e III, apenas. 
D 
III e IV, apenas. 
8 
BPMN (Business Process Model and Notation) é uma notação gráfica padrão que foi 
desenvolvida para representar processos de negócios de forma clara e compreensível. É 
uma linguagem visual que permite aos analistas de negócios, engenheiros de software e 
outras partes interessadas descrever, modelar, analisar e documentar processos de 
negócios de uma maneira padronizada. 
Fonte: Adaptado de: BALDAM, R. L. Gerenciamento de processos de negócios - 
BPM: uma referência para implantação prática. 1. ed. Rio de Janeiro: Elsevier, 2014. 
Com base no texto, os principais elementos de BPMN, entre outros, são: 
I. Raias. 
II. Atividades. 
III. Conectores. 
É correto o que se afirma em: 
A 
I, II e III. 
B 
I, apenas. 
C 
I e II, apenas. 
D 
III, apenas. 
9 
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. 
Fonte: Adaptado de: IIBA. Um guia para o corpo de conhecimento de análise de 
negócios: Guia BABOK®. versão 2.0. Toronto: theiiba.org, 2011. 
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. 
PORQUE 
II. Nem todas as validações e aprovação de requisitos são realizadas pela equipe de 
desenvolvimento e partes interessadas. 
A respeito dessas asserções, assinale a opção correta: 
A 
As asserções I e II são falsas. 
B 
A asserção I é uma proposição falsa e a II é uma proposição verdadeira. 
C 
As asserções I e II são verdadeiras, mas a II não é uma justificativa correta da I. 
D 
A asserção I é uma proposição verdadeira e a II é uma proposição falsa. 
10 
O Design Thinking é uma poderosa abordagem centrada no ser humano que busca 
resolver problemas de maneira criativa e inovadora. É um processo iterativo e dinâmico 
que coloca a empatia, a colaboração e a experimentação em destaque. Essa abordagem 
coloca as necessidades e desejos dos usuários no centro do processo de design, 
permitindo uma compreensão profunda de suas experiências e pontos de vista. A 
empatia é a base para a criação de soluções que atendam verdadeiramente às suas 
demandas. 
Fonte: Adaptado de: BROWN, T. Design Thinking: uma metodologia poderosa para 
decretar fim às velhas ideias. Rio de Janeiro: Alta Books, 2018. 
Os pilares do Design Thinking são fundamentais na elicitação de requisitos. Com base 
nestes pilares, classifique V para as sentenças verdadeiras e F para as falsas: 
( ) A criatividade ajuda a manter a inspiração gerando formas ousadas de executar o 
projeto e implementar o código mesmo que não alinhado aos requisitos. 
( ) A inspiração consiste em um entendimento inicial do problema, fazendo com que a 
equipe de desenvolvimento esteja atenta e disposta a mergulhar nas possibilidades 
envolvidas. 
( ) A experimentação é o aprendizado com erros, onde estes erros são aceitáveis (por 
serem inevitáveis), pois geram conhecimento e são aprimorados continuamente. 
( ) A empatia trata de se conectar com o outro, com as partes interessadas, buscando 
propor uma solução técnica que não foi evidenciada durante a elicitação de requisitos 
apenas para evitar desapontamentos. 
Assinale a alternativa que apresenta a sequência correta: 
A 
V, F, F, V. 
B 
F, F, V, F. 
C 
F, V, V, F. 
D 
V, V, F, F.