Os diagramas de casos de uso da UML descreve...

Os diagramas de casos de uso da UML descrevem os requisitos funcionais de um sistema sob a perspectiva dos atores externos que interagem com ele. Para expressar rel...

Q1099904 • Engenharia de Software • Engenharia de Requisitos • Instituto Legalle • BADESUL RS • Analista de Sistemas Ênfase em Analista de Negócios • 2026

Os diagramas de casos de uso da UML descrevem os requisitos funcionais de um sistema sob a perspectiva dos atores externos que interagem com ele. Para expressar relações de dependência e reuso entre casos de uso, a UML define os estereótipos <<include>> e <<extend>>, que possuem semânticas distintas. Diante disso, assinale a alternativa que descreve CORRETAMENTE a diferença entre essas duas relações.

a) A relação <<include>> indica que um caso de uso base pode invocar outro caso de uso, dependendo de uma condição avaliada durante a execução.
b) A relação <<extend>> indica que um caso de uso base sempre incorpora o comportamento de outro caso de uso, sendo essa incorporação obrigatória.
c) A relação <<include>> indica que o caso de uso base incorpora obrigatoriamente o comportamento de outro caso de uso, enquanto <<extend>> representa uma extensão condicional e opcional ao comportamento base.
d) As relações <<include>> e <<extend>> possuem semântica equivalente e são usadas de forma intercambiável para representar reuso de comportamento entre casos de uso.
e) A relação <<extend>> indica que o caso de uso estendido passa a substituir completamente o caso de uso base, eliminando a necessidade de executá-lo de forma independente.

Questões sobre Engenharia de Requisitos

1

Q110419 • Engenharia de Software • Engenharia de Requisitos • FCC • TCE AM • Analista de Controle Externo Tecnologia da Informação
A gestão de requisitos é um conjunto de atividades que tem como principal objetivo ajudar a equipe de projeto a
- a) utilizar ferramentas de engenharia de software para modelar os requisitos do sistema, através da UML.
- b) identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue.
- c) construir um modelo técnico refinado de funções, características e restrições do software.
- d) negociar com os clientes os conflitos de prioridade de requisitos e identificar e analisar os riscos associados a cada requisito.
- e) avaliar os requisitos quanto à qualidade, garantindo que ambiguidades, inconsistências, omissões e erros tenham sido detectados e corrigidos.
Carregando informações...
2

Q108980 • Engenharia de Software • Engenharia de Requisitos • CESPE CEBRASPE • SAD PE • Analista de Controle Interno – Tecnologia da Informação
Um requisito de software expressa as necessidades e restrições colocadas em um produto de software que contribuem para a solução de algum problema do mundo real. Acerca desse assunto, assinale a opção correta.
- a) Os contratantes ou clientes são os principais colaboradores envolvidos no fornecimento de informações para o processo de levantamento ou elicitação de requisitos de software, os demais grupos de pessoas que podem fornecer informações são considerados de importância secundária.
- b) As necessidades dos usuários a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restrições mencionadas na definição de requisitos constituem a classe de requisitos não funcionais.
- c) Entre as fontes de informação para a elicitação de requisitos, destacam-se, além dos colaboradores, o conhecimento do domínio de aplicação em que o software funcionará, o ambiente operacional do software e o ambiente organizacional.
- d) A negociação de requisitos, de forma similar à observação do ambiente organizacional, é uma atividade típica da fase de elicitação de requisitos.
- e) A técnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, é mais aderente à construção de cenários durante a construção de protótipos que durante a elicitação de requisitos.
Carregando informações...
3

Q114182 • Engenharia de Software • Engenharia de Requisitos • FCC • BAHIAGÁS • Analista de Processos Organizacionais Análise de Sistemas
É uma restrição sobre os serviços ou as funções oferecidos pelo sistema. Pode ser uma restrição de timing, sobre o processo de desenvolvimento, sobre o desempenho ou sobre a confiabilidade do sistema, entre outras. Trata-se de
- a) requisito não funcional.
- b) requisto funcional.
- c) especificação de risco.
- d) iteração de processo.
- e) etnografia.
Carregando informações...
4

Q117180 • Engenharia de Software • Engenharia de Requisitos • FCC • INFRAERO • Analista de Sistemas Desenvolvimento e Manutenção
A engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui um conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software. A função de negociação no processo de engenharia de requisitos
- a) especifica, revisa e valida o problema de modo a garantir que seu entendimento e o entendimento do cliente sobre o problema coincidam.
- b) refina e modifica os requisitos. É uma ação de modelagem de análise composta de várias tarefas de modelagem e refinamento.
- c) define quais são as prioridades, o que é essencial, o que é necessário. Clientes, usuários e outros interessados são solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade.
- d) ajuda o cliente a definir o que é necessário.
- e) define o escopo e a natureza do problema a ser resolvido.
Carregando informações...
5

Q120945 • Engenharia de Software • Engenharia de Requisitos • CESGRANRIO • Petrobras • Analista de Sistemas Pleno Processos
Sobre a Análise e o Gerenciamento de Requisitos, é FALSO afirmar que:
- a) quanto mais tarde for identificado um problema na análise de requisitos, maior será o custo com o retrabalho.
- b) a elicitação é o processo de identificação e entendimento das necessidades e restrições dos usuários, enquanto que a especificação é o processo de formalização das necessidades e restrições dos usuários em requisitos funcionais de software.
- c) na análise de requisitos o cliente utiliza as melhores práticas de engenharia de requisitos na tarefa de descrever suas necessidades.
- d) o gerenciamento de requisitos corresponde ao conjunto de atividades que auxilia a equipe do projeto a identificar, controlar e rastrear os requisitos, bem como a fazer as alterações nos requisitos durante o projeto.
- e) o gerenciamento de requisitos implica a alteração, inclusão e/ou exclusão de requisitos ao produto de software, o que pode levar a alterações de prazos, de recursos humanos, de equipamentos e de tecnologia.
Carregando informações...
6

Q120215 • Engenharia de Software • Engenharia de Requisitos • UFF • UFF • Analista de Tecnologia da Informação
Na engenharia de requisitos, a etapa em que a equipe de revisão examina a especificação do sistema, procurando erros de conteúdo ou interpretação, áreas em que esclarecimentos podem ser necessários, informação omissa, inconsistências, requisitos conflitantes ou requisitos não realísticos, é conhecida como:
- a) análise e negociação de requisitos;
- b) modelagem do sistema;
- c) gestão de requisitos;
- d) especificação de requisitos;
- e) validação de requisitos.
Carregando informações...
7

Q185846 • Engenharia de Software • Engenharia de Requisitos • FCC • DPE SP • Agente de Defensoria Programador
No contexto da Engenharia de Requisitos, considere:

I. O sistema deve fornecer uma entrada de dados que possibilite a inclusão de atributos de permissão de acesso às dependências da corporação por técnicos, supervisores e chefes.

II. Algumas permissões de acesso deverão ter tratamento especial para a entrada de atributos. Para este tipo de permissão, atributos excedentes a uma faixa predeterminada só poderão ser incluídos por chefes de seção.

Em relação às assertivas acima, é correto afirmar:
- a) o item I trata de um requisito funcional e a ele está associado o requisito não funcional, contido no item II.
- b) o item I trata de um requisito não funcional e a ele está associado o requisito funcional, contido no item II.
- c) ambos referem-se a requisitos funcionais.
- d) a assertiva contida no item II é uma condição restritiva do requisito não funcional do item I. Por si só, não constitui um requisito, tanto funcional quanto não funcional.
- e) a assertiva contida no item II é uma condição restritiva do requisito funcional do item I. Por si só, não constitui um requisito, tanto funcional quanto não funcional.
Carregando informações...
8

Q115676 • Engenharia de Software • Engenharia de Requisitos • FGV • BADESC • Analista de Sistemas
Analise o fragmento a seguir:

"a base de dados deve ser protegida para acesso apenas de usuários autorizados".

O fragmento acima apresenta um exemplo do seguinte requisito:
- a) funcional.
- b) de usuário.
- c) de sistema.
- d) de domínio.
- e) não-funcional.
Carregando informações...
9

Q263705 • Engenharia de Software • Engenharia de Requisitos • FCC • TRT 23a REGIÃO • Técnico Judiciário Tecnologia da Informação
Detalhes técnicos desnecessários especificados pelos usuários podem confundir os objetivos globais do sistema. No levantamento de requisitos, trata-se de um problema de
- a) complexidade.
- b) detalhamento.
- c) entendimento.
- d) escopo.
- e) volatilidade.
Carregando informações...
10

Q118770 • Engenharia de Software • Engenharia de Requisitos • AOCP • BRDE • Analista de Sistemas Desenvolvimento de Sistemas
Sobre a Obtenção de requisitos de um sistema proposto, abaixo analise as assertivas e assinale a alternativa que aponta a(s) correta(s).

I. Fontes de informações durante a fase de obtenção de requisitos incluem documentação, stakeholders de sistema e especificações de sistemas similares.

II. A interação com os stakeholders neste processo de dá por meio de entrevistas e observações, podendo ser utilizado senário e até mesmo protótipos para auxiliar nesta obtenção.

III. Os stakeholders variam de usuários finais do sistema a gerentes e envolvidos externos.

IV. Fontes de requisitos como stakeholders, domínios e outros sistemas podem ser representados como pontos de vista do sistema, em que cada ponto de vista apresenta um subconjunto de requisitos do novo sistema.
- a) Apenas I e II.
- b) Apenas I e III.
- c) Apenas II e III.
- d) Apenas II, III e IV.
- e) I, II, III e IV.
Carregando informações...

Mais questões de Engenharia de Software →

Os diagramas de casos de uso da UML descreve...

Os diagramas de casos de uso da UML descrevem os requisitos funcionais de um sistema sob a perspectiva dos atores externos que interagem com ele. Para expressar rel...

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Reportar erro em questao

Busca no Site