Análise de Requisitos

O projecto de interface de utilizador deve ter sempre por base uma compreensão do perfil e das tarefas do utilizador. Este ponto pretende demonstrar este principio, assim como as várias formas através das quais as características dos utilizadores e das tarefas que estes deverão desempenhar, podem ser representadas e analisadas.

Conhecer o tipo de utilizadores pode ser uma tarefa difícil, especialmente quando a população alvo é muito variada ou quando apenas pode ser descrita de uma forma geral, isto é, não é a mesma coisa projectar uma aplicação para um grupo restrito de pessoas em que todas têm um conjunto de características semelhante ou projectar uma aplicação, por exemplo, para um quiosque de informação onde é impossível saber-se quais as características dos utilizadores.

2.1.1 Perfil dos utilizadores

Numa abordagem centrada no utilizador, a primeira fase do ciclo de vida do projecto foca- se no tipo de utilizador que irá trabalhar com o sistema. Hackos afirma que “é necessário estudar os utilizadores porque são eles que decidem se querem utilizar o sistema, e não os projectistas” (Hackos, et al., 1998).

A necessidade de conhecer os utilizadores e quais as características que levam à sua compreensão é consensual. Autores como Mayhew (Mayhew, 1992), Gould (Gould, et al., 1985), Sheniderman (Shneiderman, 1998), Hackos (Hackos, et al., 1998), Nielsen (Nielsen, 1993) entre outros, afirmam que só através do estudo e compreensão das características dos utilizadores a quem se destina o produto é possível projectar uma interface usável, pois aquelas irão ser determinantes no desempenho do utilizador. As características a ter em consideração serão de ordem cognitiva, física e comportamental.

Deborah Mayhew (Mayhew, 1992) analisa em pormenor o conjunto de factores que, de algum modo, irão influenciar o desempenho do utilizador, Estes podem ser sinteticamente agrupados da foram seguinte:

-

o estilo cognitivo (verbal/analítico, espacial/intuitivo) o atitude

o motivação

- conhecimento e experiência o nível de leitura

o experiência de escrita à máquina o habilitações

o experiência em sistemas o experiência na tarefa o experiência na aplicação o língua nativa

o utilização de outros sistemas o literacia informática

- características do trabalho e da tarefa o frequência de utilização

o formação inicial (nenhuma, pelo manual, quando necessário, obrigatório)

o utilização do sistema (obrigatório, opcional)

o categoria no trabalho (executivo, operário, secretária)

o relação entre a dificuldade de aprendizagem (tempo e custo) e a importância no trabalho

o outras ferramentas (telefone, calculadora, etc.)

o importância da tarefa que se quer automatizar para a função que se desempenha

o estrutura da tarefa (operação repetitiva ou não) - característica físicas

o dificuldade em ver cores

o lateralidade (esquerda, direita, ambidestro) o sexo

Da análise das diferentes característica (obtidas por entrevistas, questionários ou pelos responsáveis dos recursos humanos) obter-se-á um conjunto de requisitos que influenciarão o projecto da interface, isto é, definirão quais os atributos de usabilidade mais importantes para o sistema.

Tendo em consideração a quantidade de características de utilizador que podem influenciar o desempenho do utilizador, pode-se afirmar que não há um estilo de interface óptima para qualquer tipo de utilizador, a optimização para um determinado tipo será sempre em detrimento de outro tipo de utilizador.

Shneidermam (Shneiderman, 1998) declara que o processo de obtenção de conhecimento sobre os utilizadores é interminável porque há muito a conhecer sobre eles e porque estão em permanente mudança (adquisição de conhecimentos), mas cada passo na compreensão dos utilizadores e o seu reconhecimento como indivíduos diferentes do próprio projectista é um passo para estar mais perto de uma interface bem sucedida.

2.1.2 Análise de tarefas

Após a definição do perfil dos utilizadores, os projectistas deverão identificar as tarefas que se pretendem implementar na nova aplicação.

“A análise das tarefas é o processo pelo qual se analisa a forma como os utilizadores desempenham os seus trabalhos: as coisas que eles fazem, as coisas sobre as quais actuam e as coisas que eles precisam de saber” (Dix, et al., 1998). Desta análise deve resultar o claro entendimento do que o sistema deve fazer.

A análise de tarefas é largamente utilizada na especificação do projecto de interface. Ao longo do tempo têm-se vindo a desenvolver diferentes técnicas de análise, algumas delas muito complexas como por exemplo: Command Language Grammar (CLG), Task Action

Grammar (TAG), Task Analysis for Knowledge Descriptions (TAKD). Uma técnica mais

simples e, também, largamente utilizada é Hierarchical Task Analysis (HTA).

A análise hierárquica de tarefas (HTA) é uma técnica que tem por base a decomposição de uma tarefa com um determinado objectivo, em sub-tarefas e procedimentos ou planos de forma hierarquizada (de cima para baixo) para se conseguir alcançar o objectivo final. Esta técnica faz uma análise empírica do desempenho das tarefas que o utilizador tem de executar.

método mais prático conhecido é a regra de p x q, que estabelece a relação entre o preço a pagar em termos de esforço requerido para levar a análise ao nível mais baixo de detalhe e o custo de um erro ser cometido no desempenho da tarefa a esse nível (Johnson, 1992). Outro ponto óbvio de paragem é onde a tarefa contem um complexo motor de resposta (como o movimento do rato) ou onde estão envolvidas decisões (Dix, et al., 1998).

Jenny Preece (Preece, et al., 1994) descreve o processo de análise hierárquica de tarefas em três etapas:

Inicio da análise:

- especificar a área de trabalho ou a tarefa principal;

- dividir a tarefa principal (de cima para baixo) entre 4 a 8 sub-tarefas; - especificar planos para cada sub-tarefa.

Progresso da análise:

- decidir qual o nível de detalhe requerido e qual o ponto de paragem na decomposição. Esta pode ir desde um nível muito detalhado de descrição (por ex. clicar com o rato) a um alto nível, no qual se descrevem as unidades básicas (por ex. apagar um parágrafo);

- decidir se se continua a analisar cada sub-tarefa de acordo com a profundidade ou de acordo com a sua ordem ou próximo nível. Na prática utilizam-se as duas estratégias;

- representar a análise de acordo com as convenções (gráfica ou textual).

Conclusão da analise:

- assegurar que a decomposição e numeração das tarefas é consistente;

- apresentar a análise a alguém que não tenha participado no processo de decomposição, mas que conheça muito bem a tarefa, por forma a verificar a sua consistência.

A hierarquia das tarefas pode ser representada de forma diagramática ou textual. Para uma melhor compreensão apresenta-se na Figura 12 o exemplo de notação apresentado por Dix (Dix, et al., 1998) para representar a hierarquia de tarefas necessárias para fazer uma chávena de chá. A linha por baixo das tarefas indica que a decomposição foi parada nesse ponto.

Figura 12 - Representação gráfica de HTA (Fonte: Dix, 1993)

A representação textual (Figura 13), que do ponto de vista do conteúdo é idêntica, pode não ser tão agradável e evidente como a representação gráfica, mas é igualmente utilizada.

Figura 13 - Representação textual de HTA (Fonte: Dix, 1993)

Na representação textual a indentação é utilizada para representar os diferentes níveis na hierarquia e é enfatizada através da numeração.