Gerência de Requisitos de Software Avaliação II - Individual

Prévia do material em texto

Gerência de Requisitos de Software - Avaliação II 
 
1 
A UML (Unified Modeling Language) é uma poderosa ferramenta composta por 13 
tipos distintos de diagramas, amplamente utilizada para a modelagem de sistemas de 
software. Criada na década de 1990, surgiu a partir da integração de diversas notações já 
existentes, consolidando-se como uma linguagem padrão na indústria de 
desenvolvimento de software. Essa abordagem unificada permite aos profissionais da 
área visualizar, especificar, construir e documentar diferentes aspectos de um sistema, 
desde a concepção até a implementação. Cada tipo de diagrama na UML serve para 
representar aspectos específicos do sistema, como sua estrutura, comportamento, 
interações entre os componentes e muito mais. 
Fonte: Adaptado de: BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The unified 
modeling language user guide. Reading, MA: Addison-Wesley, 1999. 
Sobre UML e seus diagramas, classifique V para as sentenças verdadeiras e F para as 
falsas: 
( ) O correto uso de UML e seus diagramas necessita da importância de entender o 
contexto ao qual se aplica o projeto de software, fato observado principalmente no 
diagrama de atividade. 
( ) A pouca relevância dada ao UML deve-se ao fato de não ser um padrão 
universalmente aceito, aplicando-se apenas a poucos e restritos projetos de software em 
larga escala e manutenção. 
( ) A UML exige que seja utilizado todos os seus 13 (treze) diagramas, pois é um 
modelo recomendado apenas para projetos grandes de sistemas de software cuja 
metodologia é rígida em um ciclo de vida clássico. 
( ) A maioria dos usuários de UML acredita que podem desenvolver bons projetos de 
software utilizando apenas cinco de seus diagramas: diagrama de atividades, diagrama 
de casos de uso, diagrama de sequência, diagrama de classes e diagrama de máquinas de 
estado. 
Assinale a alternativa que apresenta a sequência correta: 
A 
V, V, F, F. 
B 
V, V, V, F. 
C 
F, V, V, F. 
D 
V, F, F, V. 
2 
O Diagrama de Classes é um dos diagramas mais importantes da Unified Modeling 
Language (UML) e desempenha um papel fundamental na modelagem orientada a 
objetos. Ele é usado para representar a estrutura estática de um sistema, mostrando as 
classes do sistema, seus atributos, métodos e as relações entre elas. 
Fonte: Adaptado de: FOWLER, M. UML Essencial: Um breve guia para a Linguagem 
de Modelagem Padrão. 3.ed. Porto Alegre: Bookman, 2004. 
Uma equipe de desenvolvimento de software está debatendo sobre qual diagrama UML 
usar para representar a estrutura de classes do sistema e suas relações. Considerando 
essa situação, analise as afirmações a seguir: 
I. O Diagrama de Classes é mais apropriado para representar a estrutura de classes do 
sistema e suas associações, permitindo visualizar as relações entre as classes de forma 
clara e concisa. 
II. O Diagrama de Objetos é mais adequado para representar a estrutura de classes do 
sistema e suas instâncias específicas em tempo de execução, exibindo atributos dos 
objetos e suas relações. 
III. Os dois diagramas, Diagrama de Classes e Diagrama de Objetos, são igualmente 
apropriados para representar a estrutura de classes do sistema, e a escolha depende das 
necessidades específicas do projeto. 
IV. O Diagrama de Classes é útil apenas na fase de projeto, pois representa quais 
objetos poderão ser implementados, enquanto o Diagrama de Objetos é mais relevante 
na fase de implementação do software, pois demonstra como serão implementados. 
É correto o que se afirma em: 
A 
I, II e III, apenas. 
B 
III e IV, apenas. 
C 
II e III, apenas. 
D 
I e IV, apenas. 
Revisar Conteúdo do Livro 
3 
Requisitos não funcionais são elementos essenciais para o desenvolvimento de sistemas 
e aplicativos, pois eles definem aspectos que vão além do simples funcionamento de um 
software. Enquanto os requisitos funcionais descrevem as funcionalidades e 
comportamentos específicos que um sistema deve possuir, os requisitos não funcionais 
estabelecem critérios de qualidade, desempenho, segurança e usabilidade. 
Fonte: Adaptado de: SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: 
Pearson Education do Brasil, 2018. 
Como mencionado no texto-base, os requisitos funcionais vão além do funcionamento 
(funcionalidades) do sistema. Identifique exemplos de Requisitos Não Funcionais nas 
afirmativas a seguir: 
I. Um sistema de vendas deverá utilizar o SGBD (Sistema de Gerenciamento de Banco 
de Dados) MySQL. 
II. Um sistema de cadastro de alunos deve coletar a fotografia do aluno em arquivos de 
no máximo 3 Megabytes. 
III. Um sistema de rede bancária, para uso de transações via PIX deverá ter 
disponibilidade de 24 horas x 7 dias por semana. 
IV. Um sistema de autoescola deverá apresentar um campo, do tipo caixa de texto, para 
coletar e armazenar o CPF do aluno no banco de dados. 
É correto o que se afirma em: 
A 
I, II e III, apenas. 
B 
I, apenas. 
C 
III e IV, apenas. 
D 
II e IV, apenas. 
4 
A UML promove uma linguagem comum que transcende barreiras técnicas e 
linguísticas, permitindo que todos os envolvidos no projeto, incluindo analistas, 
desenvolvedores, designers e gerentes, possam colaborar de maneira mais produtiva. 
Isso evita ambiguidades e mal-entendidos, resultando em um melhor alinhamento das 
expectativas e uma maior clareza nos requisitos. 
Fonte: Adaptado de: BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The unified 
modeling language user guide. Reading, MA: Addison-Wesley, 1999. 
A UML não obriga que se utilize todos os seus diagramas, pois pode ser utilizado para 
diversas finalidades, principalmente no aspecto de: 
A 
Utilizar os diagramas como forma de gerenciar o projeto, elencando inclusive custos e 
orçamento previsto. 
B 
Padronizar uma linguagem de programação, definindo a tecnologia que será utilizada 
para a implementação, pois os diagramas permitem a configuração de código 
embarcado. 
C 
Substituir, por completo, a etapa de validação de requisitos, pois os diagramas 
são intuitivos e autoexplicativos. 
D 
Documentar um sistema existente, não necessariamente todo o sistema, mas sim utilizar 
alguns diagramas para documentar as partes mais importantes. 
5 
Durante a revisão de requisitos, uma equipe multidisciplinar, incluindo analistas, 
desenvolvedores, testadores e outros stakeholders relevantes, se reúne para analisar e 
discutir os requisitos documentados. A revisão pode ser conduzida de diversas formas, 
como reuniões presenciais, revisões formais ou revisões informais. 
Fonte: Adaptado de: PRESSMAN, R.; MAXIM, B. R. Engenharia de Software: uma 
abordagem profissional. 8. ed. Porto Alegre: Amgh, 2016. 
Durante a revisão de requisitos, a equipe multidisciplinar deverá avaliar os requisitos de 
diversas formas. Sobre essas formas, classifique V para as sentenças verdadeiras e F 
para as falsas: 
( ) Quanto à rastreabilidade, a equipe deverá mapear os responsáveis pelas 
informações coletadas, como forma de responsabilizá-los por erros de projeto. 
( ) Quanto à clareza, a equipe deve identificar possíveis ambiguidades na descrição 
dos requisitos, pois isso pode ocasionar no não atendimento ou no atendimento diverso 
quanto à real necessidade do usuário. 
( ) Quanto à completude, a equipe deve analisar se os requisitos contêm somente e 
apenas a descrição necessária para atender a uma necessidade do usuário. 
( ) Quanto à verificabilidade, a equipe deverá verificar quais requisitos não foram 
elicitados. 
Assinale a alternativa que apresenta a sequência correta: 
A 
F, V, V, F. 
B 
V, V, F, F. 
C 
V, F, F, V. 
D 
F, F, V, F. 
6 
O Diagrama de Atividade é um importante componente da Unified Modeling Language 
(UML) utilizado na engenharia de software e no desenvolvimento de sistemas. Esse 
diagrama é especialmente útil para modelar o fluxo de atividades e a sequência de ações 
dentro de um processo ou método específico.Fonte: Adaptado de: SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: 
Pearson Education do Brasil, 2018. 
Com base no excerto, para o bom uso de um diagrama de atividade, num projeto de 
software, é importante ficar atento a(o): 
I. Às etapas de coleta de requisitos, que servem apenas para essa finalidade: coletar 
requisitos. 
II. Ao contexto e à finalidade do sistema, pois deve ser aplicado dentro de um contexto 
e método específico. 
III. À integração com o diagrama de caso de uso, somente após a conclusão do 
diagrama e das descrições de caso de uso. 
IV. À identificação de todas as atividades envolvidas no processo, pois melhora a 
ilustração da lógica de um fluxo de trabalho. 
É correto o que se afirma em: 
A 
I, apenas. 
B 
I, II e III, apenas. 
C 
II e IV, apenas. 
D 
III e IV, apenas. 
7 
As entrevistas são uma etapa fundamental nos processos de levantamento de requisitos 
de software. Essa prática envolve a comunicação direta entre os analistas e os 
stakeholders envolvidos no projeto, como usuários, clientes, gerentes e especialistas em 
domínio. O objetivo principal das entrevistas é obter informações valiosas sobre as 
necessidades, expectativas e restrições do sistema a ser desenvolvido. 
Fonte: Adaptado de: WIEGERS, K. E.; BEATTY, J. Software Requirements. 3. ed. 
Redmond: Microsoft Press, 2013. 
Com base nas informações apresentadas, avalie as asserções a seguir e a relação 
proposta entre elas: 
I. As entrevistas são uma etapa fundamental nos processos de levantamento de 
requisitos de software. 
PORQUE 
II. As entrevistas permitem uma comunicação direta entre os analistas e os stakeholders, 
possibilitando a obtenção de informações detalhadas sobre as necessidades e 
expectativas do sistema a ser desenvolvido. 
A respeito dessas asserções, assinale a opção correta: 
A 
A asserção I é uma proposição verdadeira e a II é uma proposição falsa. 
B 
As asserções I e II são verdadeiras, mas a II não é uma justificativa correta da I. 
C 
As asserções I e II são verdadeiras, e a II é uma justificativa correta da I. 
D 
A asserção I é uma proposição falsa e a II é uma proposição verdadeira. 
8 
Uma história de usuário advém das metodologias ágeis, e consiste em uma técnica de 
desenvolvimento de software cujo objetivo é descrever uma funcionalidade do software 
de maneira simples e compreensível para o usuário final e que represente uma 
necessidade real do negócio. 
Fonte: Adaptado de: COHN, M. User stories applied: for agile software development. 
Boston: Addison Wesley, 2004. 
Sobre histórias de usuário e os exemplos citados, classifique V para as sentenças 
verdadeiras e F para as falsas: 
( ) Um sistema para um supermercado poderá ter a técnica de história de usuário 
promovendo o uso linguagem natural ao invés de linguagens técnicas, por ser a forma 
mais clara e objetiva para se entender as reais necessidades dos usuários. 
( ) Uma abordagem de história do usuário permite à equipe de desenvolvimento 
promover um estilo mais informal de conversação como boa prática para elicitação de 
requisitos, ao invés de abordar linguagem técnica, pode-se adentrar no contexto do 
negócio, com termos comuns entre as áreas. 
( ) Uma participação ativa do cliente é fundamental, por exemplo, em um sistema para 
uma empresa de logística, podem existir muitos termos do dia a dia do cliente que 
podem ser estranhos à equipe de desenvolvimento. Daí a necessidade de utilizar uma 
linguagem natural e não técnica, entre as partes. 
( ) Ao utilizar a história de usuário, a equipe de desenvolvimento não precisa se 
preocupar com a documentação, haja visto que a própria história será utilizada para 
documentar os encontros, as pessoas reunidas e os pontos definidos, não sendo 
necessária a sua retenção e catalogação para utilização futura. 
Assinale a alternativa que apresenta a sequência correta: 
A 
V, V, V, F. 
B 
V, F, F, V. 
C 
V, V, F, F. 
D 
F, V, V, F. 
9 
A documentação adequada dos requisitos é uma prática essencial. É importante manter 
registros detalhados e atualizados dos requisitos, suas alterações, discussões e decisões 
tomadas. A documentação deve ser organizada e de fácil acesso para toda a equipe, 
permitindo a compreensão e o acompanhamento dos requisitos ao longo do ciclo de 
vida do projeto. 
Fonte: Adaptado de: ROBERTSON, S.; ROBERTSON, J. Mastering the 
Requirements Process: Getting Requirements Right. 3 ed. Addison-Wesley 
Professional, 2012. 
A documentação de um sistema consiste num contrato entre os usuários (partes 
interessadas) e a equipe de desenvolvimento, pois: 
A 
Retrata os valores acordados e as cláusulas de multa e sanções no caso do não 
cumprimento quanto a entrega do produto final. 
B 
Trata-se de todo o histórico sobre os acertos, ajustes e mudanças contidas nos requisitos 
do sistema, permitindo sua implementação, implantação, uso e manutenção. 
C 
Serve para punir os responsáveis pelas falhas de operação e uso do sistema depois de 
entregue. 
D 
É um documento que rege boas práticas para salvaguardar a empresa em casos de plágio 
ou cópia ilegal de seu sistema. 
10 
O Diagrama de Caso de Uso é uma das principais ferramentas da Unified Modeling 
Language (UML) e desempenha um papel fundamental na modelagem de sistemas. Esse 
diagrama tem como objetivo representar as interações entre atores (usuários ou outros 
sistemas) e o sistema em questão, mostrando de forma clara e concisa os principais 
cenários de uso. 
Fonte: Adaptado de: BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The unified 
modeling language user guide. Reading, MA: Addison-Wesley, 1999. 
Uma equipe de desenvolvimento de software está trabalhando em um projeto para criar 
um sistema de gerenciamento de biblioteca. Eles estão discutindo sobre a utilidade do 
Diagrama de Casos de Uso na modelagem do sistema. Considerando essa situação, 
analise as afirmações a seguir: 
I. O Diagrama de Casos de Uso representa atores por elipses, e os casos de uso são 
exibidos como figuras externas ao sistema. 
II. O Diagrama de Casos de Uso é usado para representar a interação entre atores e o 
sistema, mostrando os principais cenários de uso do sistema. 
III. A funcionalidade que deve ser fornecida aos atores, no sistema, é representada, de 
maneira específica em cada caso de uso do Diagrama de Casos de Uso. 
IV. O Diagrama de Casos de Uso é útil apenas na fase de análise de requisitos e não tem 
utilidade nas fases subsequentes do desenvolvimento de software, pois não é 
documentado. 
É correto o que se afirma em: 
A 
I e IV, apenas. 
B 
I, II e III, apenas. 
C 
II e III, apenas. 
D 
III e IV, apenas.