A Equipe de Tecnologia (ETi) de um tribunal de contas está levantando as necessidades para um novo sistema junto às partes interessadas. Uma das partes interessadas solicitou que o novo sistema seja fácil de usar, como requisito não funcional. Para que o requisito não funcional “fácil de usar” seja objetivamente testado, a ETi deve considerar a métrica:
- A)eficiência;
Errada, porque eficiência se relaciona com desempenho e consumo de recursos, não com a facilidade de aprendizado do usuário.
- B)disponibilidade;
Errada, porque disponibilidade mede se o sistema está acessível quando necessário, e não se ele é fácil de usar.
- C)tempo de treinamento;
Certa, porque o tempo de treinamento é uma métrica objetiva para avaliar usabilidade e a facilidade de aprendizado do sistema.
- D)taxa de ocorrência de falhas;
Errada, porque taxa de ocorrência de falhas mede confiabilidade/robustez, e não a usabilidade.
- E)tempo de atualização de tela.
Errada, porque tempo de atualização de tela avalia tempo de resposta ou desempenho percebido, não a simplicidade de uso.
Gabarito: C
Quando a questão fala em requisito não funcional de usabilidade, a ideia é sair do campo do "acho que é fácil" e entrar no campo do "como eu provo isso?". Em Engenharia de Requisitos, requisitos não funcionais precisam ser observáveis, mensuráveis e testáveis, senão viram frase bonita de edital, mas ruim de validar na prática. No caso de "fácil de usar", a métrica mais adequada é o tempo de treinamento, porque ele mostra quanto esforço o usuário precisa para aprender a operar o sistema. Se o sistema é realmente fácil de usar, o usuário aprende rápido, com pouca orientação e menor curva de aprendizagem. As outras métricas até podem conversar com qualidade do software, mas medem outras coisas. Eficiência fala de desempenho e uso de recursos, disponibilidade trata de quanto o sistema fica acessível, taxa de falhas mede confiabilidade, e tempo de atualização de tela mede resposta do sistema, não a facilidade de uso do ponto de vista do usuário. Esse raciocínio é bem alinhado com a prática de especificação de requisitos de qualidade em Engenharia de Software: para um atributo subjetivo, você procura um indicador objetivo. Por isso, a banca quer que você traduza "fácil de usar" em algo verificável, e tempo de treinamento é exatamente esse tipo de medida.