Na UML,

Minhas considerações.

• a) As atividades descritas são, essencialmente, pertencentes à análise de projeto, e não de requisito. (falsa)
• b) As classes enumeradas na questão são classes gerais de sistemas, e não próprias do domínio do problema. (falsa)
• c) Diagramas de casos de uso são usados, principalmente, durante levantamento de requisitos. (correta)
• d) A fase em questão se refere à anlálise de requisitos, e não de projeto. (falsa)
• e) Não existe ator interno. (falsa)

 

Pra mim, todas as afirmativas estão falsas.

Na letra c, os atores não exercem papel fundamental sobre o que deverá existir no software.
Os atores são pessoas, hardware ou software que irão interagir com o sistema que será desenvolvido.
No meu ponto de vista, os requisitos ou casos de uso irão exercer papel fundamental sobre o que deverá existir no sistema.

Quando o termo entidades é utilizado ele pode referenciar qualquer entidade externa, usuários do sistema, fornecedores ao sistema, sistemas externos, e qualquer ENTIDADE que interaja com o sistema. 

Análise de requisitos

O levantamento de requisitos deve ser a primeira etapa a ser desenvolvida, uma vez que reunirá os subsídios necessários para as etapas seguintes. Na análise de requisitos se verificam quais são os problemas e desejos do usuário com relação ao software que será desenvolvido. À medida que o levantamento de requisitos é realizado, pode-se fazer uma modelagem das atividades encontradas, empregando-se para isso o diagrama usecase.

Análise sistêmica

Durante a análise sistêmica será feito um estudo de todos os dados e processos verificados na fase anterior (levantamento de requisitos), de maneira que se façam abstrações para identificação de classes, seus atributos e métodos. As classes deverão ser apresentadas em um modelo de maneira que se visualize a estrutura e a forma em que elas deverão interoperar, para tanto, poderá ser empregado o diagrama de classes. Na análise sistêmica só serão modeladas classes que pertençam ao domínio principal do problema, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação, concorrência e outros que não estarão presentes nesse diagrama.

Projeto

Nesta etapa extrapola-se o domínio principal do problema do software. Outras classes podem ser adicionadas ao modelo existente para propiciar uma infraestrutura tecnológica, como a interface do usuário e dos periféricos, o gerenciamento de banco de dados, a comunicação com outros sistemas etc. Trata-se de um aprimoramento da etapa anterior, cujo resultado será um detalhamento das especificações para que seja possível a programação do software.

Implementação

[...]

Testes e implantação

[...]

Fonte: http://www.noginfo.com.br/arquivos/LM_T_Parte_02.pdf

c)

use cases são parte dos diagramas comportamentais em UML. Os diagramas comportamentais mostram como o processo reage às ou se altera com as mudanças do tempo. Além do use case diagrams temos diagramas de maquinas & diagramas de atividades.

Gabarito: C. A alternativa correta é a que descreve o uso dos diagramas de casos de uso (use-case) na UML como ferramentas para modelar as funcionalidades do sistema através das interações entre os usuários (atores) e o sistema. Estes diagramas são essenciais durante a fase de levantamento de requisitos, ajudando a identificar as funcionalidades necessárias e a maneira como os usuários finais irão interagir com o sistema. Os atores representam entidades externas que interagem com o sistema, podendo ser pessoas, outros sistemas ou hardware. Estes são fundamentais para o entendimento do comportamento externo do sistema e do que será esperado dele.

A justificativa para a alternativa C ser a correta está na sua alusão direta à identificação e modelagem inicial das necessidades de interação entre o sistema e o mundo externo, tarefa inicial crucial no desenvolvimento de sistemas. Em UML, os casos de uso são uma representação visual das relações entre os atores (usuários ou outros sistemas) e os processos ou funcionalidades do sistema, servindo como uma poderosa ferramenta de comunicação e entendimento entre stakeholders e desenvolvedores.