A Equipe de Tecnologia (ETi) de um tribunal de contas está ...

Alternativa correta: C - tempo de treinamento.

Ao lidar com a Engenharia de Requisitos, é fundamental compreender a distinção entre requisitos funcionais e não funcionais. Requisitos funcionais descrevem as funcionalidades específicas ou comportamentos do sistema, ao passo que os requisitos não funcionais abordam critérios que podem ser usados para julgar a operação de um sistema, mas não as operações específicas que ele deve executar. Esses últimos incluem aspectos como usabilidade, eficiência, confiabilidade, entre outros.

Quando falamos em "fácil de usar", estamos nos referindo à usabilidade, que é um requisito não funcional. Para avaliar objetivamente se um sistema é fácil de usar, podemos considerar várias métricas, como o número de erros que os usuários cometem, a satisfação do usuário, e o tempo necessário para que os usuários se familiarizem com o sistema.

A alternativa C, tempo de treinamento, é a correta porque reflete de forma direta a facilidade de uso do sistema. Se um sistema é intuitivo e bem projetado, o tempo necessário para treinar alguém em como usá-lo deve ser mínimo. Uma métrica de tempo de treinamento reduzido sugere uma alta usabilidade, pois indica que o sistema pode ser aprendido com facilidade e rapidez.

As outras opções não são tão diretamente relacionadas à usabilidade ou facilidade de uso quanto o tempo de treinamento:

• Eficiência se refere ao desempenho do sistema sob determinadas condições e não necessariamente reflete a facilidade de uso.
• Disponibilidade está ligada à capacidade do sistema de estar acessível quando necessário e não ao quão fácil ele é de ser usado.
• Taxa de ocorrência de falhas indica a confiabilidade do sistema e não a facilidade com que os usuários podem aprender e operá-lo.
• Tempo de atualização de tela pode influenciar a percepção de responsividade, mas não é um indicador claro de facilidade de uso.

Portanto, para avaliar objetivamente a facilidade de uso do sistema, o tempo de treinamento é uma métrica adequada e, por isso, a alternativa C é a correta.

Resposta: C

Requisitos Não Funcionais

Requisitos não funcionais são aqueles que não estão diretamente relacionados à funcionalidade de um sistema. O termo requisitos não funcionais é também chamado de atributos de qualidade. Os requisitos não funcionais têm um papel de suma importância durante o desenvolvimento de um sistema, podendo ser usados como critérios de seleção na escolha de alternativas de projeto, estilo arquitetural e forma de implementação. Desconsiderar ou não considerar adequadamente tais requisitos é dispendioso, pois torna difícil a correção uma vez que o sistema tenha sido implementado. Suponha, por exemplo, que uma decisão tenha sido feita de modularizar a arquitetura de um sistema de modo a facilitar sua manutenção e adição de novas funcionalidades. Entretanto, modularizar um sistema adicionando uma camada a mais pode comprometer um outro requisito, o de desempenho. Portanto, faz-se necessário definir logo cedo quais requisitos não funcionais serão priorizados na definição de uma arquitetura.

Os requisitos não funcionais abordam aspectos de qualidade importantes em sistemas de software. Se tais requisitos não são levados em consideração, então o sistema de software poderá ser inconsistente e de baixa qualidade, conforme discutido acima. Para tanto, quanto mais cedo forem definidos os critérios arquiteturais, mais cedo o projetista pode identificar o estilo, ou combinação de estilos, mais apropriado ao sistema considerado.

Ao desenvolver um novo sistema de software bem como sua arquitetura, os projetistas ou engenheiros de software apresentam um conjunto de atributos de qualidade ou requisitos não funcionais que o sistema deveria suportar. Exemplo destes requisitos são desempenho, portabilidade, manutenibilidade e escalabilidade.

A arquitetura de software deveria oferecer suporte a tais requisitos. sto resulta da associação existente entre arquitetura de software e requisitos não funcionais. Importante observar que cada estilo arquitetural (isto é, a forma na qual o código do sistema é organizado) suporta requisitos não funcionais específicos. A estruturação de um sistema é determinante no suporte oferecido a um requisito não funcional. Por exemplo, o uso de camadas permite melhor separar as funcionalidades de um sistema, tornando-o mais modular e facilitando sua manutenção.

Embora haja um conjunto de propostas, consideradas como complementares, concentraremos nossas atenções num conjunto de requisitos diretamente associados a um sistema de software e, especificamente, à arquitetura de software. Este conjunto é baseado numa classificação apresentada por Sommerville, onde é feita a distinção entre requisitos externos, de produto, e de processo [Sommerville 2007].

Fonte: https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-funcionais/9525

Classificação dos Requisitos Não Funcionais:

Requisitos de produtos:

Requisitos que especificam o comportamento do produto.

Ex. portabilidade; tempo na execução; confiabilidade, usabilidade, mobilidade, etc.

Possuem a subdivisão em:

Requisitos de usabilidade (facilidade de uso).

Ex.: usuários deverão operar o sistema após um determinado tempo de treinamento.

Resposta:

"Fácil de usar" = Usabilidade = Tempo de Treinamento

Cada uma dessas propriedades possuem algumas métricas a serem consideradas, vejamos:

Velocidade → Transações processadas/segundo; Tempo de resposta do usuário/evento; Tempo de atualização da tela (letra E); 

Tamanho → Megabytes/número de chips de ROM; 

Facilidade de uso → Tempo de treinamento (letra C); Número de quadros de ajuda; 

Confiabilidade → Tempo médio até a falha; Probabilidade de indisponibilidade; Taxa de ocorrência de falhas (letra D); Disponibilidade (letra B) 

Robustez → Tempo para reiniciar após a falha; Porcentagem de eventos causando falhas; Probabilidade de corromper dados em uma falha; 

Portabilidade → Porcentagem de declarações dependentes do sistema-alvo; Número de sistemas-alvo.

TOTVS .. rsrsrs

só que não