Com respeito ao processo de Engenharia de Requisitos de Soft...

Alternativa correta: D - I, III, IV e V, somente.

Para resolver esta questão, é necessário ter um conhecimento sólido sobre Engenharia de Requisitos de Software e suas práticas. A Engenharia de Requisitos é uma parte fundamental do processo de desenvolvimento de software, pois lida com a identificação, documentação e manutenção dos requisitos que o software deve atender.

Afirmativa I: O Diagrama de Classes e o Diagrama de Atividades são ferramentas da Unified Modeling Language (UML) que podem ser utilizadas tanto no processo de elicitação e modelagem de requisitos quanto na fase de design arquitetural. O Diagrama de Classes ajuda a representar a estrutura estática do sistema, enquanto o Diagrama de Atividades ilustra o fluxo de trabalho do sistema. Portanto, essa afirmativa está correta.

Afirmativa II: Está incorreta porque, mesmo em projetos dinâmicos, a especificação de requisitos é crucial e não pode ser substituída completamente por protótipos evolutivos. Os protótipos são uma ferramenta útil para explorar ideias e requisitos, mas não substituem a necessidade de uma especificação bem definida que aborde aspectos funcionais e não funcionais do produto.

Afirmativa III: Os processos de gerenciamento de requisitos e gerenciamento de projetos devem realmente atuar de forma integrada em uma organização de desenvolvimento de software. A integração assegura que os requisitos sejam geridos de acordo com o plano do projeto e que as mudanças nos requisitos sejam refletidas no planejamento e execução do projeto. Essa afirmativa está correta.

Afirmativa IV: Etnografia, prototipação, entrevistas e questionários são de fato técnicas utilizadas na identificação de requisitos de software. Essas técnicas ajudam a entender o contexto de uso, as necessidades dos usuários e outros stakeholders, e são uma parte importante do processo de Engenharia de Requisitos. Isso faz com que esta afirmativa esteja correta.

Afirmativa V: Casos de uso descrevem as interações entre os usuários (atores) e o sistema para alcançar um objetivo específico. Por definição, eles se concentram em requisitos interativos. No entanto, processos internos complexos não se enquadram como casos de uso, pois não envolvem interação direta com o usuário. Portanto, essa afirmativa está correta.

Com base nas análises acima, chegamos à conclusão de que as afirmativas I, III, IV e V estão corretas, o que corresponde à alternativa D.

Diagrama de atividades pode ser usado na descrição de arquitetura??

Fala colega Rodrigo, como está? Respondendo sua pergunta.

     Sim diagramas de atividades podem ser usados na descrição de arquitetura, já que esse diagrama é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra.

    Acredito eu, que você pensa na arquitetura como a parte estrutural do sistema, ou seja, somentes os aspectos estáticos do sistema,  É UM ERRO PENSAR ASSIM!

Trecho retirado do Guia do Usuário UML -  BOOCH, RUMBAUCH, JACOBSON;

  "A arquitetura é o conjunto de decisões significativas acerca dos seguintes itens:

               - A organização do sistema de software;

              - A seleção dos elementos estruturais e suas interfaces, que compõem o sistema;  (diagramas estruturais)

              - Seu comportamento, conforme especificado nas colaborações entre esses elementos; (diagramas comportamentais)

              - A composição desses elementos estruturais e comportamentais em subsistemas progressivamente maiores."

Complementando...

      " A arquitetura de software não está relacionada somente com a estrutura e o comportamento, mas também com a utilização, funcionalidade, desempenho, flexibilidade, reutilização, abrangência, restrições e ajustes econômicos e tecnológicos e questões estéticas"   

Bom, espero ter esclarecido sua dúvida!

Diagrama de classes para requisitos?

A afirmativa I está errada, porque a questão informa que o diagrama de classes e atividades podem ser usados tanto no processo de requisitos quanto na descrição de arquitetura (design) de um software. Ou seja, informa que cada um serve para os dois propósitos, o que não é verdadeiro. Essas bancas pegam textos soltos espalhados pela internet e não pesquisam a veracidade da informação em literaturas consagradas.