Interação Humano-Computador

Prévia do material em texto

1 Introdução à IHC
Este capítulo trata do entendimento do termo IHC, a visão histórica
desta área, descreve as diferenças entre interface e interação,
apresenta as áreas relacionadas à IHC e que tipo de profissionais
são encontrados nesta área.
1. Os termos associados e o seu Histórico
IHC é a abreviação para INTERAÇÃO HOMEM­COMPUTADOR,
que no inglês é encontrado sob a sigla HCI– Human­Computer
Interface. IHC também pode ser interpretado como INTERFACE
HOMEM­COMPUTADOR, mas este equívoco de comparação
ocorre por causa do histórico dos termos interface e interação.
Mesmo assim o termo IHC possui afinidade com as questões de
‘interface com o usuário’ (Preece, 1994).
O termo ‘interface’ foi inventado por volta de 1880, mas a palavra
não teve muita repercussão até 1960quando começou a ser
utilizada pela indústria computacional. A partir de então começa a
ter um emprego mais amplo significando, inclusive, interações entre
departamentos e organizações ou campos de estudo. Mas até ser
realmente aceito, o termo sofre desaprovação por parte da
comunidade científica que alega possuir uma conotação ostensiva
(jargão). Parte desta comunidade de oposição oferece, então, a
substituição do termo ‘interface’ por palavras de uso comum como
“cooperação, transação, troca de informação, interação ou até
mesmo trabalho”, as quais são recusadas. O termo interface cai em
desuso.
INTERAÇÃO: Enfoque mais amplo com novos campos de estudo envolvendo a
comunicação entre usuários e computadores ou outros tipos de produtos.
INTERFACE: Termo pioneiro que estabelece o conceito de ponto de interação entre
um computador e outra entidade.
Mesmo com tantas barreiras o termo interface é absorvido e seu
uso generalizado, designando o ponto de interação entre um
computador e outra entidade, tais como impressoras ou
operadores humanos. Isso ocorre na década de 1970, quando
pesquisadores da área computacional passam a se preocupar com
estudos sobre a ‘interface com o usuário’ (UI – user interface)
também conhecida por ‘interface homem máquina (MMI – man­
machine interface).
A definição de interface está associada a ‘uma linguagem de
entrada de dados para o usuário, uma saída de dados para a
máquina e um protocolo de interação’(Chi, 1985 citado em Preece,
1994 p. 7). Com a sofisticação dos sistemas computacionais
novos atributos são acrescentados aos sistemas
computacionais, servindo de trampolim para a criação de um
novo termo – IHC.
Meados dos anos 80 o termo IHC é adotado por possuir um
enfoque mais amplo e, por isso, exigir novos campos de estudo.
Preece (1994) esclarece que, mais do que o projeto de interface, a
área de IHC se preocupa com as comunicações ou interações entre
usuários e computadores. Sua definição da área confere
responsabilidades como elaboração do
projeto, avaliação e implementação de sistemas
computacionais interativos para uso humano, além de estudos
suplementares sobre fenômenos relevantes que envolvam os
aspectos de interação.
Os esforços em estabelecer procedimentos de interação nos
sistemas computacionais semelhantes àqueles utilizados em
situações reais resultam em várias propostas de melhoria para
Interfaces Gráficas com o Usuário (GUI, do inglês Graphical User
Interface), novos dispositivos e paradigmas de interação que
encontramos nos equipamentos mais modernos. Estas pesquisas
concentram­se em estudos de Interação entre Homem e
Computador (IHC). Os benefícios destas pesquisas e práticas da
IHC vão além da melhoria das condições de uso dos sistemas,
adentra questões comerciais que definem a aceitabilidade e
permanência dos produtos no mercado. A evolução da área de IHC
segundo Amyris (2007) se apresenta da seguinte forma:
Anos 1950: Interface de hardware “para engenheiros” com
diversos botões de interação
Anos 1960­1970: Interface de programação (COBOL,
FORTRAN)
Anos 1970­1990: Interface de terminais (linguagens de
comando)
Anos 1980: Interface de interação para diálogo (GUIs,
multimídia)
Anos 1990: Interface para realizar trabalho (redes e grupos)
A partir de 2000: Interface torna­se onipresente (Aparelhos
celulares, bluetooth, dispositivos móveis, eletrônicos, por toda a
parte, telas interativas e muitas tecnologias embarcada)
O PROJETO DE INTERAÇÃO DETERMINA O SUCESSO OU
FRACASSO DO PRODUTO OU DA COMPANHIA.
O sucesso de produtos interativos chama a atenção de
departamentos de marketing que compreendem que a usabilidade
afeta fatores como marca, número de acessos aos sites, índice de
retorno nos sites e a satisfação do usuário e potencial cliente. “A
interação com a interface afeta a percepção de
marca”(Fernandez, 2005).
Listas com exemplos de boas e más práticas são publicadas a toda
hora. Na lista de más práticas são encontrados produtos que, se
chegaram a ser conhecidos por seu público alvo, caíram no
esquecimento pela frustração causada ou pelo aparecimento de
soluções mais adequadas. Serviços na Internet, por exemplo,
acabam perecendo pela negligência de aspectos de usabilidade ou
atualização de informações. Estes aspectos podem estar ligados
até mesmo a evolução de novas soluções tecnológica que
oferecem processos e resultados mais eficazes ao usuário. O Alta
Vista, por exemplo, tão utilizado como serviço de busca ficou
ultrapassado quando novas tecnologias ofereciam processos de
buscas mais elaborados.
O número de profissionais e especialistas na área de projeto de
interação cresce na medida em que a demanda por produtos mais
usáveis é solicitada por usuários.
Com a abertura deste mercado
multidisciplinar vários profissionais como sociólogos,
antropólogos, dramaturgos combinam habilidades para encontrar
as melhores soluções de interação. Isso gera custos, causa
confusão, desentendimento e até mesmo falhas de comunicação.
Mas o resultado tem sido satisfatório uma vez que os projetos
começam a pensar mais no usuário.
O DESIGN DE INTERAÇÃO JÁ É UM GRANDE NEGÓCIO.
2. Interface e Interação são coisas diferentes
Em determinado momento da história chegou­se a conclusão que a
Interação é um termo mais amplo em conceitos do que a Interface.
Imagine um grande conjunto chamado interação que, para existir,
necessita de um elemento que permita a comunicação – a
interface. O resultado disso é que, entendendo a interação, será
mais fácil projetar a interface (Figura 1).
 
Figura 1 ­ Representação simplificada do processo de interação e sua relação com a
interface
 
A interface é responsável por promover estímulos de interação
para que o usuário obtenha respostas relacionadas às suas
atividades. De um lado ela funciona como dispositivo de entrada de
dados e de outro  ela é responsável por enviar as respostas aos
usuários. Ou seja, o estímulo promovido fará com que o usuário
desenvolva um processo de interação que significa a execução de
ações para a realização das tarefas. Para cada ação uma nova
resposta é esperada por ambos os lados: sistema e usuário.
“Vemos, pois, que a interface é tanto um meio para a interação
usuário­sistema, quanto uma ferramenta que oferece os
instrumentos para este processo comunicativo. Desta forma a
interface é um sistema de comunicação.”(de Souza, 1999)
Em um sistema computacional a interface com o usuário é o
conjunto completo de aspectos que torna explícito o processo de
interação e inclui de forma resumida os seguintes elementos:
dispositivos de entrada e saída de dados;
informação apresentada ao usuário ou enviada pelo usuário;
retorno oferecido pelo sistema ao usuário;
comportamento do sistema; e
ações do usuário com respeito a todos estes aspectos.
Os componentes de interface possibilitam a comunicação entre
usuário e equipamentos ou dispositivos; eles permitem elaborar
os processos de entrada e saída de dados. Em sistemas
computacionais e afins (estações de jogos, celulares, DVDs, etc)
estes componentes de interface servem para identificar objetos
virtuais como caixasde checagem, barras de rolagem, botões,
etc., mas também existem os componentes físicos de interface
como mouse, teclado, controle remoto entre muitos outros (Figura
2).
Interação é, portanto, a troca que ocorre entre usuários e
equipamentos, a exemplo dos sistemas computacionais. Isso
acontece por meio de ações básicas e habituais, que são
as tarefas de interação. Diferentes estilos de interação podem
enriquecer o processo de comunicação, mas esta decisão de
especificação do comportamento da interface pode aumentar o
grau de dificuldade de interação. Em sistemas computacionais a
configuração dos processos de interação com especificações
personalizadas podem oferecer ao usuário experientes flexibilidade
durante a interação.
 
Figura 2 ­ Qualquer objeto possui uma interface que permite processos de
interação
 
Há quem diga que o conceito de interação teria vindo da física,
incorporado pela sociologia, psicologia social e só então passa a
fazer parte da informática transformando­se em interatividade
(Silva, 1998). É comum encontrar, também, definição de interação
como sendo a comunicação que ocorre entre duas pessoas quando
mediado por algum tipo de sistema, como bate papo (chat) ou
fórum, por exemplo. Ou ainda um blog que permite que visitantes
insiram comentários e que a interação tenha acontecido entre dois
humanos. Embora isso represente um conjunto mais complexo de
interação esta apostila manterá seu foco no cenário que representa
o diálogo entre máquina e ser humano e suas relações com as
condições de projeto que envolvem outros seres humanos.
METÁFORAS E MODELOS MENTAIS: Seja qual for a atividade a ser
desempenhada no processo de interação, a facilidade de comunicação dependerá da
utilização conceitos baseados em metáfora e modelos mentais adquiridos pelos
usuários. Metáforas são semelhança ou analogias que podem ser utilizadas no
projeto de interação sugerindo um relacionamento entre objetos ou processos reais
conhecidos pelo usuário. As metáforas na interação são muito estudadas em
sistemas de realidade virtual onde a interação pode definir o grau de realismo de um
sistema. A metáfora é utilizada para que o usuário compreenda, com mais facilidade,
a relação dos componentes de interface e as atividades a serem desempenhadas.
Um exemplo simples é a utilização de cenários para a apresentação do conteúdo
caracterizando um domínio familiar de processos e elementos como se fossem no
mundo real.Modelos mentais são suposições criadas pelas pessoas para
desempenhar atividades que tenham relação com algo que ela já tenha tido contato,
mesmo que o procedimento imaginado não seja o mais adequado.
Recursos de interação
Os muitos recursos de interação permitem combinação diversas de
interfaces e ações. Teclado, monitor, elementos virtuais, entre
outros motivam pesquisas de todo tipo. A interface gráfica com o
usuário GUIs (Graphical User Interface) oferece soluções para o
uso de elementos gráficos como menus, janelas, paletas, ícones,
etc. As pesquisa sobre o projeto do produto tecnológico envolvem
conceitos de ergonomia – que sugere capacidades humanas para a
utilização de interfaces físicas – processo de projeto, testes entre
outros. Na década de 1980 e 1990 novos recursos surgiam e o
mercado para a pesquisa multidisciplinar ampliava com
descobertas de interface e interativas como reconhecimento de
voz,multimídia, realidade virtual, ambientes de aprendizagem
(treinamento e educação) e rede sem fio.
3. Interfaces e o projeto de interação
O projeto de interação é a geração de soluções para implementar o
uso prático de algo que permita um diálogo, seja um sistema ou
equipamento. A interface, um dos elementos responsáveis pelo
processo de interação, pode ser dividida em dois aspectos de
comunicação:
INTERFACE FÍSICA (ou de hardware) – meio de contato
predominantemente físico empregando materiais como cabos,
fios, placas, mouses, teclado.
INTERFACE LÓGICA (ou de software) – meio de contato
predominantemente cognitivo que faz uso de aspectos léxicos
(funcionais), sintáticos (estruturais) e semânticos (conteúdo).
Exemplos de comunicação entre máquina e máquina, software e
software, homem e máquina e GUIs.
Porque duas interfaces?
São numerosos os dispositivos que dependem da junção de
uma interface física pela qual o usuário alcança elementos
gráficos de um sistema ou aplicativo. Estes elementos gráficos
determinam a interface gráfica.
Para a grande maioria das pessoas o mouse e o teclado
representam parte importante do processo de interação – são
exemplos de interface física. A ausência do mouse pode deixar
qualquer um apavorado, mesmo que seja um usuário experiente. A
utilização de programas para editar imagens, texto ou até mesmo o
processo para desligar o computador são atividades que
dificilmente são realizadas sem o mouse. Aí você diz; “mas é
possível fazer estas atividades utilizando apenas o teclado!”. De
fato, a condição de flexibilização do sistema operacional ou dos
aplicativos permite que o usuário tenha mais de um tipo de acesso
ou formato de interação com muitas atividades no computador –
são os atalhos.
 
Figura 3 ­ O telefone celular é um
exemplo de equipamento que
interface física e gráfica. Aparelhos
touchscreen minimizam o uso de
interface física, mas não as excluem.
A caneta por exemplo representa
uma interface que permite a
comunicação.
 
A interface lógica é mais conhecida pelos gráficos e suas regras
determinadas pela GUIs – Graphical User Interface. Este tipo de
interface faz parte de praticamente qualquer novo dispositivo
tecnológico encontrado no mercado e deveremos conviver com
eles ainda por muito tempo. Novas tecnologias tendem, inclusive, a
minimizar o uso de interfaces física para a realização da
comunicação, como já ocorre em equipamentos touchscreen. Mas
ainda assim é possível identificar a interface física. A tela, o
próprio  dedo do usuários, um mouse de botão, a caneta, por
exemplo, são meio de estabelecer contatos para entrada de dados.
A tela gráfica e os auto­falantes comunicam a realização de tarefas.
A combinação de interfaces física e gráfica ou lógica em
celulares exige um projeto de interação que leve em conta uma
relação compreensível entre o aplicativo do aparelho e seus botões
e teclado. Em avaliações feitas por alunos da disciplina de TASI
utilizando princípios de projeto, metas de usabilidade, heurísticas
entre outros conceitos foi possível verificar que o parelho Nokia é
dos mais simples de operar, enquanto o Motorola está entre os
mais complicados.
O desenvolvimento de interfaces de qualidade pode consumir algo perto de 50%
do tempo e dosrecursos alocados para o projeto (Filho, 2005). O grau de
dificuldade para implementar bons projetos pode aumentar conforme a quantidade de
formatos e elementos de interação envolvidos no projeto.
Congruência de interfaces
Com a evolução de tecnologia por meio de estudos científicos que
apontam novas soluções de interface e interação os novos
produtos começam a combinar interfaces físicas e gráficas. Entre
os veteranos e mais conhecido está o computador com aplicações
que funcionam com saída gráfica (monitor) e sonora (caixas de
som) + mouses, teclados, joysticks, dentre outros. Os telefones
celulares também oferecem aplicação com saída gráfica na tela e
som normalmente manipulados por interfaces física na forma de
teclado alfanumérico e botões diversos. Outras máquinas como de
comprar refrigerante, salgadinhos, bilhetes de transporte possuem
painel de comando com botões e tela com instruções.
O que é importante entender a respeito da combinação de
interfaces é a relação entre ambos os elementos gráficos e físicos
que precisa ser efetiva, clara e consistente para que, por meio dos
dispositivos ou interfaces físicas, a interface gráfica reaja de acordo
com as expectativas do usuários. Em resumo,qualquer coisa que
seja projetadaprecisa considerar os seguintes aspectos:
atender o tipo de atividade esperada pelo usuário;
estudar a interface mais apropriada para entrada e saída de
dados; e
oferecer funcionalidades complementares como forma de
flexibilizar o processo de interação.
Os elementos de interface mais comuns e conhecidos que
permitem a interação em sistemas computacionais são menus,
comandos, formulários, ícones, botões e combinações de
dispositivos físicos.
Áreas relacionadas à IHC
Esta área do conhecimento é definida pela multidisciplinaridade que
envolve especialista e profissionais de diversas áreas como:
psicologia;
sociologia;
antropologia;
sistemas de informação;
ciências da computação;
design gráfico;
ergonomia.
Como assim? Considerando que os primeiros sistemas
computacionais tenham sido desenvolvidos por engenheiros de
hardware, que tipo de experiências eles poderiam ter sobre as
condições humanas como habilidades e limitações para utilizarem
os primeiros sistema desenvolvidos por eles? Como o processo de
interação seria visto pelo usuário?
 
Figura 4 ­ Ilustração sobre o início da área de IHC
 
Com o advento do monitor na década 1970 profissionais curiosos
com as novidades tecnológicas e buscavam soluções para a
realização de tarefas envolvendo a cognição humana. Isso
mobilizou cientistas da computação e psicólogos. Depois
disso novos desafios levam ao desenvolvimento de novas
soluções.
Com isso nasce o profissional que desafia as novas tecnologias em
busca de soluções para o usuário. Oprojetista de interação – ou
designer de interação – passa então a ser responsável pela
geração de idéias que ofereçam o máximo de conforto ao usuário
durante a realização das atividades de interação.
4. O projetista de interação
Para entender melhor a atuação do profissional responsável pela
geração de projetos de interação é interessante utilizar a analogia
proposta por Preece (2005) sugerindo um contraste entre áreas.
 
Correlação de atuação profissinal
 
A preocupação do arquiteto em seus projetos é com a pessoa que
utilizará o espaço construído prevendo conforto para morar,
trabalhar, formulando circulações adequadas, janelas que permita a
entrada de luz natural e ventilação… em resumo: PREOCUPAÇÃO
COM O USUÁRIO DA EDIFICAÇÃO OU DO SISTEMA!
A preocupação do engenheiro civil em seus projetos é que a
estrutura seja resistente para suportar pessoas, equipamentos,
intempéries… em resumo: PREOCUPAÇÃO COM A EDIFICAÇÃO
OU CÓDIGO!
O engenheiro de software se preocupa com a produção de
soluções robustas para os sistemas que projeta e desenvolve. Em
resumo: PREOCUPAÇÃO COM A EDIFICAÇÃO OU CÓDIGO!
O projetistas de interação se preocupa com o processo de
utilização do sistema e o desempenho das atividades realizadas
pelo usuário. Em resumo:  PREOCUPAÇÃO COM O USUÁRIO DA
EDIFICAÇÃO OU DO SISTEMA!
As profissões decorrentes da área de IHC
Esta área incentivou o aparecimento de uma série de novos
profissionais que tentam se estabelecer em um mercado ainda em
implantação, ou mesmo em definição, que tentam acompanhar uma
área que ainda está em fase de estabelecer atividades e
competências. Dentre elas destacam­se os seguintes profissionais
com suas atividades:
Analista com especialidade em projeto centrado no
usuário: Ele saberá conduzir as primeiras atividades de
entrevista com os usuários e clientes.Fará a identificação das
necessidades e as transformará em requisitos.
Arquiteto de informação: Trabalha junto com analistas ou
imediatamente após finalização destas atividades  de
levantamento de requisitos para entender as regras de negócio
e estruturar informações necessárias. Com os requisitos
levantados ele se encarrega de definir processos para a
estruturação, organização e distribuição de informações e
atividades do sistema ou do site em estruturas que possam ser
compreendidas para a realização de tarefas interativas.. Ele
poderá desenvolverwireframes para a identificação dos espaços
destinados aos blocos de elementos. Este profissional pode,
ainda, trabalhar na elaboração de textos objetivos e definição de
rótulos (webwriting).
WebDesigner: Ele dará continuidade às atividades do arquiteto
de informação elaborando, a partir  doswireframes e mock upIs,
detalhes que darão identidade ao produto. São definidos
elementos como tipo e tamanhos de fontes, paletas de cores,
logomarcas, ícones entre outros. A alocação dos componentes
de interface podem ser reestruturadas caso sejam identificadas
tais necessidades. Owebdesigner tem a responsabilidade,
também, de tomar decisões de apresentação das informações
quando existe a necessidade de estimular os sentidos do
usuário para a realização das interações (como são
apresentados links, por exemplo).
Especialista em usabilidade: possui competências e
conhecimento de conceitos para elaborar análises de sistemas
que devam sofrer melhorias, de protótipos, de produtos
concorrentes para entender pontos fracos e fortes e realizar
avaliações heurísticas.
Testador/Avaliador: o profissional de testes possui
conhecimento de processos que ajudam na utilização de
sistemas em produção para verificação de problemas como
erros de lógica, de implementação, cosméticos. Os resultados
são descritos em relatórios utilizados ao longo do processo de
testes. Possui conhecimento, também, para planejar outros
meios de avaliação com a utilização de usuários representativos
– atividade que também pode ser dominada pelo especialista em
usabilidade. O testador possui conhecimento de técnicas e
processos de avaliação mais elaborados para as várias fases de
desenvolvimento.
desenvolvimento.
Encontram­se muitas outras funções e denominações de
profissionais nesta área que ainda tentam se adequar  ao mercado.
O fato é que alguns deles são mais necessários que outros, ou
mais “utilizados” que outros. Alguns profissionais aparecem com
foco tão específico que dificilmente seriam contratados para fazer
parte de equipes de desenvolvimento. O profissional de
usabilidade, por conta da notoriedade que o nome vem ganhando,
chama a atenção de alguns gerentes de projeto que passam a
contratar este profissional para integrar suas equipes  de
desenvolvimento. O motivo desta procura decorre da necessidade
que o mercado e seus exigentes usuários vêm impondo. Ainda
assim, embora as atividades deste profissional sejam específicas,
em algumas equipes este profissional pode passa a desempenhar
atividades diversas.
5. Atividades
1. Discuta, em equipe de 3, sobre como seriam os procedimentos
de interação para um celular de pulso. Quais seriam as
dificuldades, facilidades, modos de interação e de uso do
equipamento se apenas uma das mãos pudesse ser utilizada.
2. Faça uma pesquisa e descubra quais outros profissionais
podem ser identificados na área que permeia IHC, usabilidade, AI,
Design e outros relacionados.
3. Como nasce a área de IHC e quais são as figuras importantes
(os profissionais e áreas relacionadas) associadas a sua
estabilização?
4. Defina quem é o projetista de interação e qual sua relação entre
o engenheiro de software. Qual analogia pode ser definida com a
engenharia civil e a arquitetura.
5. Quais são as diferenças entre interface e interação?
6. Quais tipos de interfaces podem ser identificados em
dispositivos que permitam a interação?
7. Quais profissionais atuais podem ser identificados decorrente
das demandas de IHC?
8. O  quê são interface lógica e interface física?
2 Projetando interações
Este capítulo apresenta as definições sobre o projeto de interação
com o usuário (PIU), o que é e para que servem os processos de
interação e as atividades do projeto de interação. Apresenta ainda
as questões práticas do PIU que inclui  necessidades e requisitos,
projetos alternativos, versões interativas, avaliação e as diversa
condições envolvidas no processo de documentação dos artefatos
nas etapa de desenvolvimentodo projeto de interação com o
usuário. São tratadas ainda considerações emergenciais para o
projeto de interação e modelos de ciclo de vida na área de IHC e
uma forma de projetar a interação por meio da engenharia
semiótica.
1. Contextualização
É comum encontrar o termo “Design de Interação”, mas prefiro não
entrar em detalhes sobre o significado de termo Design[1] e utilizar
uma tradução mais objetiva para o termo: Projeto. Sendo assim,
quando falarmos de Projeto de Interação estaremos falando de
Design de Interação.
Na interação homem computador os processos que caracterizam
diálogos são formados por ações empregadas por uma entidade
comunicativa na qualidade de usuário ou computador. O objetivo é
provocar uma troca de informações: respostas às reações geradas
por estímulo. A isto se denomina interação. Dentro deste
escopo, garantir um processo efetivo e com sucesso para o
diálogo passa pelo Projeto de Interação com o Usuário, o PIU.
O que é e de onde vem o projeto de interação?
Segundo Saffer (2007) esta disciplina é proveniente de raízes do
design industrial, fatores humanos, interação homem computador,
experiência do usuário dentre outras áreas que ainda ajudam a
definir os limites desta nova disciplina. Mas independente de suas
raízes o projeto de interação possui um caráter essencialmente
comportamental. Este comportamento está associado com algo
praticamente intangível e invisível, algo difícil de ser definido como
ideal. Diferente da aparência, por exemplo, que pode causar
reações imediatas. O comportamento está associado a reação
onde, por exemplo, dois produtos diferentes que fazem a mesma
coisa  causam impactos diferentes no uso, mas isso só pode ser
reconhecido somente depois da experiência de manipulação ou
uso.
Qual é o objetivo do projeto de interação?
De forma simples é tornar simples a vida de quem usa alguma
coisa. É definir processos para comunicação e interação humana
com os artefatos ou produtos interativos, o que inclui decisões
sobre detalhes dos procedimentos da comunicação de ordem
lógica ou física e comportamental. Mas ainda se discute sobre os
objetivos desta disciplina. Dentro deste escopo são definidos os
processos de um produto interativo que fornecem suporte às
atividades cotidianas das pessoas, seja no lar, no trabalho ou no
entretenimento. Os produtos mais associados ao projeto de
interação, no entanto, são produtos tecnológicos como softwares e
equipamentos que favoreçam a utilização de um sistema lógico.
O que se pode projetar com interação?
O projeto de interação oferece a um determinado produto todo um
sistema de uso para usas funcionalidades. Em resumo o projeto de
interação se aplica a QUALQUER COISA USÁVEL! Mais
especificamente, é possível projetar uma variedade de
equipamentos e produtos que permitam a troca de
informações entre as partes.
Para entender melhor o objeto do projeto de interação é preciso
entender que podem ser utilizadas uma série de elementos nas
interações que oferecem saída e entrada de dados para a geração
de estímulos permitindo, assim, um diálogo fluido. Saídas e
entradas de dados acontecem por meio de INTERFACESque
são compostas por artefatos como gráficos, sons, superfícies
que estimulam o tato, sinestesia[1], cheiros (Figura 5), os
próprios equipamentos que recebem respostas do ambiente
ou de humanos, entre outros.
Figura 5 ­ Interfaces em realidade virtual, com estímulo sinestésico e olfativo, apresentadas no Laval Virtual
em 2004 na França. O sistema sinestésico oferece manipulação de objetos virtuais com retorno físico que
permite identificar dimensões e peso dos objetos virtuais. O estímulo olfativo do jogo “Fragra” (Visual­
Olfactory VR Game) permite explorar relações interativas entre visão e olfato. É um jogo de erro e acerto onde
os cheiros podem não corresponder a fruta fazendo o jogador dizer qual é o cheiro da vez. O sistema pede
que uma fruta seja selecionada utilizando a luva com sensores, levando­a próximo ao nariz o usuários
revelado em voz alta o nome da fruta correspondente ao cheiro que é exalado pela luva. Ao pronunciar o
nome da fruta o usuário pode acertar ou errar. O terceiro equipamento é um Phantom, dispositivo que permite
usar a força para esculpir objetos virtuais.
Os estímulos computacionais estão associado às entradas dos
dados que podem acontecer via voz (ou sons), via apontadores
sensíveis à movimentação e controlados por dispositivos variados
(mouse, olho, caneta, etc) ações de seleção (clique por exemplo)
em formato mecânico (mouse) ou manual (touch screen), dentre
outros que envolvem tecnologias ainda em pesquisa como o
aproveitamento de impulsos neurais.
Não importa a quantidade de elementos de interface de entrada ou
saída utilizados – embora quanto maior o  número de elementos
mais complicado e complexo pode ser o processo de interação. O
importante é projetar os processos de troca de informação com o
usuário de forma a usável. A facilidade de uso é a base do
princípio de usabilidade. Mas só a base. Ser agradável é
também algo que determinará a satisfação do usuário.
Esta condição básica nos leva a entender o termo USABILIDADE.
Os vários conceitos da usabilidade, no entanto, estão associados a
diversos fragmentos que permitem a condição de “COISA
USÁVEL”. Estes conceitos serão vistos mais a frente em forma de
metas e princípios de um projeto de interação.
Nos concentraremos agora em entender melhor o que é o projeto
de interação, quais são seus processo e as questões práticas do
projeto de interação, para, então, entender como acontece o ciclo
de vida de desenvolvimento do projeto de interação.
2. O que é projeto de interação?
O projeto de interação é uma atividade prática e criativa que tem
por objetivo final o desenvolvimento de um produto que ajude
os usuários a atingirem suas metas.
Segundo Verplank (2003) o projeto de interação deve responder
sobre como o usuário fará alguma coisa, como ele se sente e como
ele sabe fazer esta coisa. Verplank ilustra este cenário descrevendo
que até o mais simples dispositivo requer manipulação,
conhecimento e sentimento como acontece com o apertar de um
botão luminoso e ver (ou sentir) a luz acender. Mas, mas para isso
é preciso entender como funciona o mapeamento deste controle.
Quanto mais afastados estiverem controles de entrada (botão) e
saída (luz), mais complexo e demorado será o modelo de
compreensão do usuário sobre o fazer e sentir.
Faz parte deste processo compreender aspectos relacionados à
interação em tarefas que dão suporte às atividades
cotidianas. O envolvimento do usuário no processo
interativo por meio de métodos centrado no usuário é, também, de
igual importância. Outros modelos de projeto com outros “centros”
também podem ser considerados, mas o usuário é nosso cliente e
como cliente, ‘quase’ sempre tem razão. Para que tudo isso seja
possível é importante iniciar bem, e para isso temos as conhecida
técnica delevantamento de necessidades e requisitos.
MAS… será que os usuários sabem o querem?
Bom, as estratégias para a criação de um projeto de interação
envolvem procedimentos que ajudam a responder questões deste
tipo. Mas, tão importante quanto isso é entender se existe uma
forma eficiente de comunicar um projeto ao usuário e fazê­lo
integrar­se à equipe de desenvolvimentotransformando­o num
colaborador durante o desenvolvimento do produto. Isso se aplica
de forma diferente para produtos novos ou atualização tecnológica.
Um produto novo ou um novo modelo conceitual pode
realmente ser visualizado e compreendido pelo usuário?
O projeto de interação trata da construção de um conhecimento
lógico apresentado e comunicado de formas diversas tanto à
equipe de desenvolvimento quanto ao usuário final. Soluções
triviais popularizadas são mais fáceis de serem absorvidas e
entendidas pelos usuários. O que talvez dê mais trabalho são
modelos conceituais inovadoresque exigem mais esforço do
usuário para aprender o processo de interação. O sucesso desses
produtos inovadores dependerá de aspectos como necessidade de
mercado, grau de desafio de uso e satisfação proporcionado ao
usuário. Ah! Inclua nesta fórmula estratégia de marketing. Você tem
acompanhado as críticas do iPhone da Apple?
iPhone se comporta muita mais como um computador do que
qualquer outro tipo de gadget – com exceção do celular Pocket
PC/Windows. Ele compete com o PPC, mas mantém a vista
somente o que é necessário para se tornar uma dispositivo
amigável. Lembrando minha experiência com o PPC, quem  na
terra deveria ver “DLL” ou EXE   no seu celular?! Resposta:
ninguém, com exceção dos desenvolvedores. A Apple entende o
que a Microsoft não entende.
A ausência de teclado não é a melhor coisa do iPhone, mas ao
mesmo tempo, como você poderia ter um dispositivo tão pequeno
que permitisse assistir filmes e que inclui um teclado Tivemos que 
ceder em algumas coisas. Brinquei um pouco com o teclado e
achei mais ou menos. Ouvi falar que leva horas para desligá­lo.
Gostei quando tive que escrever “what the heck” (que diabos) e ele
pensou que eu escrevi “what the jedi”. Isso é bom. Ficou contente
que alguém na Apple colocou “Jedi” no dicionário do iPhone, pro
caso de eu ter uma emergência no SMS durante uma conversa
sobre Star Wars.Talvez o pessoal da Apple saiba mais sobre meus
dados demográficos do que eu mesmo.
Trimb. Disponível na
URL: http://trimbo.blogspot.com/2007/06/apple­critic­iphone­
review.html
3. Processos do projeto de interação
Projetar a interação é tão importante quanto realizar os casos de
uso,  os diagramas de seqüência e todos os outros elementos
relacionados à documentação tradicional de sistema.  O PIU,
Projeto de Interação com o Usuário, envolve uma série de
processos e instrumentos relacionados a forma como o
usuário irá se comportar quando estiver utilizando o sistema.
Por isso envolve uma série de artefatos e procedimentos.
Não existe um processo ou modelo mais correto, existem, sim,
aqueles mais adequados levando­se em conta os fatores decisivos
para o desenvolvimento do produto, tais como dimensão do projeto,
cronograma, orçamento, equipe, etc.
O projeto de interação, no entanto, não é visto como uma técnica
isolada e diferente dos processos conhecidos na engenharia de
software e outras áreas comuns.
Uma forma de estabelecer uma relação detalhada do processo de
interação é  descrever o processo rico em detalhes com descrição
de objetivo, ação, resultado e detalhes (Quadro 1). Os resultados
levam ao desenvolvimento de protótipos de telas
(wireframes ou templates) que esclarecem o procedimento passo a
passo de forma visual, minimizando as barreiras que possam gerar
dúvidas aos desenvolvedores e aos usuários.
Quadro 1 – Exemplo simplificado que detalha a atividade de fechar
um programa
Objetivo Ação esperada Resultado Detalhes
Fechar o
programa
Localizar elemento
visual e levar o
cursor do mouse
até o símbolo,
botão, rótulo e
clicar.
Se houver arquivo
aberto com alterações a
serem salvas oferecer
mensagem permitindo a
ação de salvar ou
fechar sem salvar.
Deve existir
mensagem
específica para
quando houver
mais de um arquivo
aberto.
Uma solução agregada ao UML
Conhecida e utilizada por profissionais da área de computação,
a Unified Modeling Language (UML) baseada num processo
unificado de desenvolvimento de software oferece condições de
detalhamento das atividades de interação de um sistema. O
problema é que, quando utilizada para a documentação de projeto,
dificilmente entra em detalhes tão importantes da interação.
Como o próprio modelo evidencia, não se observa a natureza
iterativa e incremental do processo de desenvolvimento para
manutenção e ajustes de problemas. Além disso não oferece
destaque para a interface com o usuário. Diante disto Hudson
(2000) propõe uma extensão do processo unificado que incorpora
as 10 técnicas mais populares em projeto de interfaces (Figura 6).
O objetivo é centrar o processo ainda mais no usuário para obter
sistemas mais usáveis.
Figura 6 ­ Processo UML alterado para suportar as atividades do projeto de
interação. Em vermelho as etapas inseridas que auxiliam no projeto de interação.
(Hudson, 2000)
Na Figura 6, em vermelho, observam­se os pontos em que este
processo sofreu alterações destacando a adição das atividades de:
Identificação e desenvolvimento de cenários de
uso: Técnicas relevantes: cenários de uso (com base em dados
colhidos em observações de potenciais usuários na realização
de trabalho, por exemplo) e avaliação de sistemas existentes.
Análise de contexto: Técnicas relevantes: análise de
Análise de contexto: Técnicas relevantes: análise de
usuário/identificação de perfis, identificação de tarefas e
estabelecimento de requisitos de usabilidade.
Projeto da interface: Técnicas relevantes: projeto de
navegação, projeto visual da interface e protótipos de baixa
fidelidade.
Avaliação de usabilidade: Técnicas relevantes: avaliação de
usabilidade por especialistas e teste informal de usabilidade.
4. Atividades do projeto de interação
De forma geral podem ser observadas quatro atividades
básicas que definem o processo do projeto de interação (Preece et
al, 2005):
1. IDENTIFICAR NECESSIDADES E
ESTABELECER REQUISITOS: Trata­se da base dos requisitos
do produto. Esta atividade sustenta o design e o desenvolvimento.
O objetivo desta etapa é conhecer o usuário alvo e o tipo de
suporte útil que o produto deve oferecer. Para isso é fundamental
iniciar uma abordagem centrada no usuário.
2. DESENVOLVER PROJETOS ALTERNATIVOS QUE VÃO DE
ENCONTRO AOS REQUISITOS:Atividade central do projeto de
interação. É quando surgem as idéias que devem atender aos
requisitos, as quais devem ser geradas com base em algum tipo de
suporte. São as sub­atividades da geração de idéias. O projeto
conceitual ou o modelo conceitual do produto ganha forma
juntamente com a descrição sobre o que o produto fará, como se
comportará e parecerá. O projeto físico pode, então, ser iniciado
com detalhes de interação e de interfaces, o que pode incluir o
estudo de cores, sons, imagens, menus, animações, ícones, etc.
3. CONSTRUIR VERSÕES INTERATIVAS DE MANEIRA QUE
POSSAM SER COMUNICADAS E ANALISADAS: Fornecer meios
de simular o processo de interação. Afinal, como os usuários
saberão e verificarão se as necessidades estão sendo atendidas?
As versões prototipadas são os meios mais conhecidos para
mostrar ao usuário como um produto está sendo modelado e
verificar a primeira reação de aceite. Mas isso não significa que
deva ser uma versão funcional. Protótipos em papel podem ser
desenvolvidos e aplicados com rapidez, são baratos e eficazes na
busca de problemas nas primeiras fases do projeto. O usuário tem
uma noção real de como será a interação.
4. AVALIAR O QUE ESTÁ SENDO CONSTRUÍDO E MEDIR SUA
ACEITABILIDADE: São formas dedeterminar a usabilidade e
aceitabilidade do produto utilizando vários critérios, tais como
número de erros cometidos pelo usuário, atratividade,
preenchimento dos requisitos, etc. Não substitui testes de
qualidade que certificam o produto final. Mas ajudam a verificar se
todo ou parte do produto encontra­se em condição de uso.
Estas 4 atividades (Figura 7), que ainda veremos com mais
detalhes, podem se repetir em etapas diferentes do
desenvolvimento do projeto. Prototipagem, por exemplo, pode
acontecer tanto na fase inicial de documentação como no decorrer
da programação. A exemplo do UML proposto para o projeto de
interação, pode­se identificar que as atividades de interação
precisam ser reconsideradas em diferentes etapas do processo.
Mas a etapa crítica, a que precisa de muita atenção, é o
levantamento ou elicitação de requisitos.
Figura 7 ­ Atividades básicas do PIU
Independente do momento do projeto devem ser consideradas
algumas características­chaveno PIU:usuários envolvidos no
desenvolvimento do projeto, identificação ou especificação
de metas de usabilidade no início do
projeto e complementação e iteração (repetição) nas atividades
básicas com ênfase nos processos de avaliação. Considere,
portanto:
1. Foco no usuário: Se não for possível garantir seu envolvimento
considere o desenvolvimento de soluções voltadas para o usuário e
contexto de uso específico. Em outras palavras, projetar e avaliar
pensando como o usuário, focar nas tarefas como se estivessem
sendo realizadas para o usuário e dar atenção aos processos e
mensagens de retorno.
2. Critérios específicos de usabilidade: Os objetivos específicos
devem ser claramente documentados, pois isso ajuda na
idealização de diferentes alternativas de projeto. Desta forma é fica
mais fácil identificar metas de usabilidade e, posteriormente,
verificar o atendimento dos princípios de usabilidade.
3. Iteração: Significa repetição, que neste caso, se refere aos
processos de testes e avaliações para o refinamento do projeto,
ainda com base no retorno do usuário.
O envolvimento do projetista e do usuário ajuda a definir uma série
de critérios para o desenvolvimento do projeto (domínio, requisitos,
necessidades, desejos, aspirações e muitos outros direcionadores).
Este processo conduz ao entendimento da necessidade da
interação, muito importante quando se trata de um produto inovador
onde as idéias precisam ser revisadas à luz do retorno do usuário.
_____________________
ALGUMAS QUESTÕES PRÁTICAS DO PIU
É possível encontrar diferentes listas de atividades para o processo
de interação. Também é fácil encontrar uma série de propostas e
modelos de como atuar em cada fase ou etapa proposta para o
projeto. Mas em linhas gerais devemos entender que o projeto de
interação com o usuário é baseado em duas abordagem:
FERRAMENTAS DE NEGOCIAÇÃO: elas propiciam a
1. FERRAMENTAS DE NEGOCIAÇÃO: elas propiciam a
comunicação de idéias por meio de reuniões, discussão em
grupos, serviços de fóruns, entrevistas participativas. O
importante  desta abordagem é gerar resultados de forma
documentada.
2. PRODUÇÃO DE ARTEFATOS: são passos mais objetivos para
o desenvolvimento do projeto de interação que inclui atividades
de:
Conceitualização: É produzido com o auxílio das primeiras
atividade de levantamento de requisitos e resulta na produção
de:
mapa mental dos conceitos para o usuário;
lista dos aspectos de requisitos eleitos como importantes de
forma a adequá­los à curva de aprendizado do usuário; e
definição dos contextos de uso para condições culturais,
sociais, simbólicas e tecnológicas;
Estruturação: Diagrama de interação social, fluxograma de
interação, wireframes, protótipos de baixa fidelidade;
Apresentação: Detalhes estéticos, definição de aspectos
visuais como a identidade visual do produto, leiaute e
protótipos de alta fidelidade.
Perceba a conexão entre as atividades da “produção de artefatos” e
3 das 4 atividades que estabelecem o processo do projeto de
interação:
CONCEITUALIZAÇÃO: Está associada ao levantamento de
requisitos
ESTRUTURAÇÃO: Está associada aos projetos alternativos.
Embora possa gerar discussões intermináveis, oferecer mais de
uma solução de interface, quando o cronograma permite,
permite visualizar tarefas, elementos de interface e processos de
diferentes pontos de vista.
APRESENTAÇÃO: São as versões interativas que permitem
iniciar avaliação mais detalhadas.
_____________________
(1) Necessidades e requisitos
Para entender as questões práticas envolvidas no projeto de
interação não precisa ir muito longe. Estas atividades também
acontecem em outras áreas. Por exemplo, na arquitetura é
necessário conhecer o cliente, futuro utilizador do espaço
construído. Para isso é necessário definir uma lista de
necessidades (o que o cliente quer, quantos filhos tem, se gosta de
receber visitas, parentes para ficar por mais tempo, etc) além de
viabilidades legais que ajudarão, por exemplo, a identificar o
zoneamento possível (organização dos espaços para alocação da
edificação no terreno), dando início ao partido do projeto (primeiro
protótipo visual dos espaços a serem edificados) e prosseguindo
com os detalhamentos do projeto. As atividades iniciais estão
baseadas no estudo e envolvimento do usuário e legislação. Em
projetos urbanos, por exemplo, estes usuários são em maior
número e tão diversificado quanto na utilização de sistemas
computacionais, e por isso devem ser consideradas questões
sociais e costumes e rotinas da população para o projeto de
espaços urbanos. Tudo isso só é possível com a realização de
etapas de entrevistas envolvendo, dentro das possibilidades,
aqueles que farão uso do espaço.
Na engenharia de produto são feitas pesquisas de satisfação com
relação a produtos no mercado. Clientes potenciais também são
chamados para oferecer sugestões sobre novos propostas de
produtos. Os profissionais envolvidos são de áreas como design
gráfico, arquitetura, urbanismo, engenharias (industriais de
produção, de software) entre muitos outras.
Cada disciplina apresenta sua própria interpretação e processos
para desenvolvimento do projeto. Mas podemos entender a tarefa
de projetar a interação como sendo um (1) plano ou esquema
concebido na mente de alguns, (2) idealizado por uma equipe
de profissionais especializados que desenvolvem artefatos
que permitam a (3) execução prática do produto.
De qualquer forma, não importa a área. Cada uma delas trata, do
seu jeito, questões similares, tais como:
conhecimento sobre o uso e domínio­alvo do produto;
investigação sobre o uso de artefatos;
entender as restrições práticas quanto
ao material, custo e viabilidade; e
solução do problema antes da execução levando em conta os
usuários.
Diante de uma série de considerações é importante notar, ainda,
possíveis compensações em que devem ser pesadas a habilidade
do usuário e o equilíbrio de necessidades conflitantes.
As necessidades e requisitos para o projeto de interação não são
diferentes daqueles conhecidos pelo analista de sistema definidos
para realizar o documento técnico de sistemas computacionais.
Mas no projeto de interação é comum encontrar o usuário como
foco de qualquer atividade. Embora outros[1]modelos de centros
de projeto possam ser encontrados na literatura, o centro no
usuário é o mais explorado. Os processos mais comuns para o
desenvolvimento de projeto são baseados no USUÁRIO,
naATIVIDADE e na AÇÃO.
Esta atividade deve ser realizada em parceira direta com
usuários e clientes. As atividades definidas por processos
como RUP (Rational Unified Process) e UML (Unified Model
Language) são os procedimentos conhecidos e comumente
adotados. Eles oferecem muitos recursos para a tarefa de
documentação das necessidades e estabelecimento dos requisitos.
EM TEMPO!
Qual a diferença entre Necessidade e
Requisito? Primeiro, requisito é um derivado de necessidade. Veja
o exemplo para as diferenças para um produto do tipo telefone:
Engenharia de requisitos
A engenharia de requisitos é um processo criterioso de
identificação do que deve ou pode ser desenvolvido e das
tecnologias e insumos envolvidos. É objetivo da engenharia de
requisitos evitar problemas de desenvolvimento de sistemas que
levem ao não atendimento das expectativas do usuário. Para isso é
necessário realizar uma exaustiva e criteriosa fase de definição de
requisito. Os níveis de abstração dos requisitos são (Figura 8):
de negócios (objetivos do usuário): documento de escopo ou de
visão;
de usuários (descreve as atividades que os usuários deverão
desempenhar); e
funcionais (o que o sistema deve possuir para que os usuários
possam executar suas atividades para alcançar os objetivos de
negócio).
Figura 8 ­ Níveis de abstração dos requisitos
Outros requisitos necessários sugeridos por Blaschek (2002):
requisitos não funcionais (padrões e regulamentoscom os
quais o sistema precisa ter conformidades, como por exemplo,
descrição de interfaces externas e requisitos de desempenho);
restrições (limites de recursos e infra estrutura); e
atributos de qualidade de software (ISO 9126).
A maioria dos processos de Engenharia de Requisitos pode ser
descrita por meio de um macro­modelo de atividades (Figura
9) composto de atividades como elicitação, análise e negociação,
documentação, validação e gerência de requisitos, conforme
mostrado na Figura 9. Mas muitas outras atividades podem ser
encontradas na literatura com o objetivo de identificar requisitos.
Ribeiro (sem data)  realizou uma pesquisa onde apresenta uma
lista de processos sugeridas por quatro diferentes autores. Algumas
das atividades encontradas são repetidas, a exemplo dos requisitos
apresentados por Blaschek (2002), que determinam apenas quatro
etapas incluindo elicitar os requisitos, analisá­los, gerar a
documentação e a realizar a validação. As outras atividades são:
Análise de domínio (considerada apenas por 1 autor)
Elicitação de requisitos (considerada por 4 autores)
Modelagem (considerada por 1 autor)
Análise de requisitos (considerada por 3 autores)
Negociação (considerada por 2 autores)
Documentação (considerada por 1 autor)
Especificação de requisitos (considerada por 2 autores)
Análise da Especificação (considerada por 1 autor)
Verificação (considerada por 1 autor)
Comunicação (considerada por 1 autor)
Concordância (considerada 2 autores)
Validação (considerada por 1 autor)
Documentação do processo, das decisões e das fontes dos
requisitos (considerada por 1 autor)
Gerência de requisitos (considerada 2 autores)
Evolução de requisitos (considerada 2 autores)
Macro­modelo de atividades do processo de engenharia de requisitos
Como não existe um processo único que contemple todas estas
fases também não existem limites definidos entre as atividades.
Mas cada uma delas pode ser utilizada na prática com
interpolações entre elas. A idéia é que o processo seja realizado
até que o grau de satisfação de todos os usuários seja
alcançado ou até que a pressão do cronograma precipite o
início da fase de projeto do software(indesejável). As atividades
mais importantes, no entanto – elicitação, análise de requisitos,
documentação, validação e gerência de requisitos – são
aquelas destacadas em negrito e serão discutidas a seguir com
mais detalhes.
40% a 60% de todos os problemas encontrados em um projeto
de software são causados por falhas na fase de levantamento
de requisitos (Leffingell, 1997).
Perguntar às pessoas o que elas precisam, pode não ser suficiente.
Muitas vezes elas não sabem necessariamente o que é possível e,
até mesmo, o que realmente querem. É necessário, portanto,
chegar no usuário compreendendo:
suas características *;
suas capacidades *;
o que estão tentando alcançar;
como fazem isso atualmente; e
questionar se elas atingirão o objetivo com mais eficiência com
outro tipo de suporte.
* As características e capacidades podem variar e, neste caso,
temos os grupos de usuários por perfil.
Exemplo que influencia nas decisões e que nem sempre são
pensadas para os usuários típico:
tamanho das mãos podem afetar no tamanho e posição dos
botões;
capacidades motoras podem afetar a adequação de certos
dispositivos de entrada e saída;
o uso da força deve ser considerada em um equipamentos para
crianças (tipo de usuário – criança/adulto tempo de vida do
equipamento); e
nervosismo, questões culturais, outros.
Antes de continuar reforcemos o entendimento sobre Engenharia
de Requisito e Elicitação de Requisito.
Engenharia de Requisito: Macromodelo composto de uma
série de atividades para tratamento de requisitos.
Elicitação de Requisito: Uma das atividades da Engenharia de
Requisitos.
Elicitação de Requisitos
Elicitar requisitos é a tarefa de descobrir, identificar, deduzir,
extrair, evocar ou obter dados que contribuam com uma análise
de qualidade (Blaschek, 2002).
É importante ter boa redação, declaração de visão e escopo do
sistema.
Usuários, clientes e especialistas de domínio são identificados e
trabalham junto com os engenheiros de requisitos para descobrir,
articular e entender a organização como um todo. São
consideradas atividades para entender o domínio da aplicação, os
processos de negócio específicos, as necessidades que o software
deve atender, os problemas e deficiências dos softwares atuais, os
diferentes pontos de vista dos participantes do processo, bem como
as oportunidades e restrições existentes, os problemas a serem
resolvidos, os serviços e o desempenho requeridos, as restrições
de hardware, dentre outros.
A atividade não se resume a perguntar às pessoas o que
desejam. Também não é uma simples transferência de
conhecimento. Existem várias técnicas de elicitação, sendo que a
escolha depende do tempo e dos recursos disponíveis além do tipo
de informação que necessita ser elicitada. As técnicas de
elicitação de requisitos podem ser classificadas em (Batista,
2003):
técnicas tradicionais: englobam técnicas genéricas, tais como
o uso de questionários e pesquisas, investigação de
documentos e entrevistas;
técnicas de elicitação em grupo: exploram as dinâmicas de
grupo, tais como técnicas de grupos focados – focus
groups, workshops RAD – Rapid Application Development e JAD
– Joint Application Development;
prototipação: tem sido usada quando existe incerteza sobre os
requisitos ou quando se torna necessário ter um retorno inicial
dos usuários, podendo ser combinada com outras técnicas;
técnicas dirigidas a modelos: fornece um modelo específico
para o tipo de informação a ser obtido e conduz o processo de
elicitação englobando os métodos baseados em objetivos e
métodos baseados em cenários;
técnicas cognitivas: incluem técnicas desenvolvidas
originalmente para aquisição de conhecimento em sistemas
baseados em conhecimento. Dentre elas, pode­se citar análise
de protocolo e classificação de cartões (card sorting).
técnicas contextuais: surgiram nos anos 90 como uma
alternativa às técnicas tradicionais e cognitivas e incluem o uso
de técnicas de etnografia, tais como observação dos
participantes e análise de conversação.
A escolha da técnica dependerá do foco que se quer dar ao
processo. As abordagens tradicionais e cognitivas baseiam­se no
uso de modelos abstratos independentes do contexto. Por outro
lado as abordagens contextuais levam o contexto local como
premissa básica para o entendimento do comportamento
organizacional e social. Embora exista incompatibilidade entre
estes formatos as abordagens podem ser complementares.
As técnicas mais práticas baseiam­se
em entrevistas, brasinstorms, prototipação, JAD e método JK.
1. Entrevistas: Dificilmente deixam de ser utilizadas, pois trata­se
da forma mais natural de comunicação entre as pessoas. Mas
embora pareçam simples elas exigem procedimentos mais
específicos do que apenas perguntar. A técnica se torna mais
eficaz quando é estruturada e quando a equipe passa a dominar o
processo. Ajuda descobrir como o processo atual acontece e
entender quais são as expectativas para o novo processo ou
sistema. As perguntas podem ser feitas por um ou mais
entrevistadores e podem ser divididas em 3 tipos:
estruturadas – segue uma estrutura rígida e seqüencial.
semi estruturadas – utiliza uma lista estruturada mas permite a
ocorrências de questões extra ou são anotadas observações
extra mencionadas pelo entrevista.
não estruturadas – parte de um ponto estabelecido  (ou não) e
anda de acordo com a motivação do entrevistado.
2. Brainstorm: É bastante utilizada e conhecida, mas não envolve,
necessariamente, o usuário. Ela serve para gerar idéias a partir de
discussões realizadas por um conjunto de especialistas onde todos
colaboram com as idéias de todos, com a liberdade que só a
criatividade pode fornecer. Neste processo são feitascríticas e
julgamentos. Esta técnica pode ser aplicada no início da fase do
desenvolvimento quando pouco do projeto é conhecido e são
necessárias idéias novas. Os resultados de uma sessão bem
estabelecida contribuem com boas soluções para todas as
questões exploradas.
3. Prototipação: Este processo é utilizado para detalhar requisitos
de software definidos pelo cliente. Este técnica pode ser utilizada
para avaliação ou verificação dos possíveis procedimentos de
interação entre o homem e a máquina. O modelo permite ainda
refinar os requisitos identificados na fase de concepção, sejam eles
funcionais ou não.
4. Joint Application Design – JAD: Desenvolvida pela IBM no fim
dos anos 70 esta técnica tem base na criação de sessões de
trabalho estruturadas utilizando dinâmica de grupo e recursos
visuais. Participam analistas e usuários para, juntos, projetarem um
sistema com a compreensão adequada dos requisitos básicos e
podendo chegar, inclusive, no desenvolvimento de leiaute de telas
e relatórios. A idéia é manter a cooperação e o entendimento entre
os participantes. O papel dos desenvolvedores é ajudar os usuários
a formular problemas e explorá­los com o objetivo de indicar
possíveis soluções. Os usuários se sentem parte integrante da
equipe de desenvolvimento. O JAD é baseado em quatro princípios
básicos:
dinâmica de grupo com técnicas que possam aumentar a
capacidade dos indivíduos;
uso de técnicas audiovisuais para aumentar a comunicação e o
entendimento;
manutenção do processo organizado e racional; e
utilização de documentação­padrão, que é preenchida e
assinada por todos os participantes.
A técnica JAD tem duas grandes etapas: PLANEJAMENTO, cujo
objetivo é elicitar e especificar requisitos; e PROJETO, em que se
lida com o projeto do software. Os participantes de uma sessão de
JAD desempenham seis diferentes papéis:
líder da sessão;
representantes do usuário;
especialista;
analista;
representantes dos sistemas de informação; e
patrocinador executivo.
A técnica ajuda a identificar os assuntos que podem necessitar de
rastreamento e fornece uma perspectiva multifacetada dos
requisitos. Sessões JAD permitem aos analistas coletar simultânea
e eficientemente uma grande quantidade de requisitos do sistema
junto a uma gama de usuários­chave. São úteis por considerar
necessidades específicas dos usuários.
O JAD também pode ser usado em conjunto com outra técnica de
elicitação como, por exemplo, a prototipação. À medida que os
requisitos são obtidos nas sessões pode­se construir protótipos que
demonstrem alguma funcionalidade destes requisitos.
5. Método KJ (Kawakita Jiro): É uma atividade que ajuda a
realizar uma lista de requisitos por investigação contextual ou de
afinidades onde a observação dos envolvidos ajuda a estabelecer e
reunir prioridades para se chegar em um consenso de grupo. O
método KJ foi desenvolvido pelo japonês Kawakita Jiro que
buscava reduzir o tempo da realização da tarefa de elicitação de
requisitos. Para elaborar o processo deve­se ter o foco claro em
cada uma das rodada que estabelece o processo que se utiliza de
uma pergunta. Os principais focos para o levantamento de
necessidades costumam ser:
quem é o seu público­alvo;
quais tarefas ele deve estar apto a realizar ao final do programa
de formação;
o que este público já sabe;
em quanto tempo estas pessoas devem formar o conhecimento;
e
quais sãos os recursos disponíveis para realizar este programa.
Uma equipe experiente consegue realizar duas rodadas por hora
da dinâmica. Isso significa que em até 3 horas seria possível
realizar a análise. É um processo de análise de necessidades com
consenso em tempo recorde. Veja um exemplo do processo em
Ideários.com (Lopez, 2006) para a elaboração de um programa de
formação com KJ­Method.
Análise e negociação de requisitos
É onde os requisitos elicitados são compreendidos e
detalhadamente analisados por todos os interessados no sistema
(Blaschek, 2002). Esta atividade auxilia na descoberta de
problemas nos requisitos levantados e na obtenção de
concordância sobre as alterações. Como resultado a satisfação de
todos os envolvidos deve ser atingida. Se na etapa anterior houve
uma elicitação dos requisitos mais importante, nesta fase é
necessário estabelecer um conjunto acordado de requisitos
completos, consistentes e sem ambigüidades, que possa ser usado
como base para o desenvolvimento do software.
Como resultado deve ser gerado um documento rascunho que será
levado aos engenheiros e arquitetos de informação. Eles
manipularão os requisitos de forma que possam agrupá­los de
acordo com regras estabelecidas (funcionalidade, por exemplo),
farão explorações e classificações que estabelecerão prioridades.
Assim os requisitos são examinados em relação à sua
necessidade, completeza, consistência, riscos, viabilidade técnica,
operacional e econômica, bem como em busca de omissões,
ambigüidades, sobreposições e conflitos.
Problemas e conflitos encontrados nos requisitos são ressaltados.
Todos os indivíduos (stakeholders) classificam os requisitos com
problemas e negociam até chegarem a um acordo sobre as
modificações a serem feitas. Esta atividade pode ser direcionada
por necessidades pré­estabelecidas, por requisitos específicos para
os diferentes usuários, por restrições de projeto e de
implementação e pelo orçamento e cronograma disponíveis.
Documentação de Requisitos
Requisitos compreendidos, analisados e aceitos. Agora é só
documentar. A proposta de integração do processo associado ao
projeto de interação ao UML ajuda a identificar o momento em que
o projeto de interação deve ser realizado (Blaschek, 2002). É a
representação dos resultados obtidos até agora, em um documento
oficial e formal que contém os requisitos do software com
descrições detalhadas sobre o que ele fará, mas ainda sem
descrever como fazer o software em termos de tecnologia ou
linguagem de programação a ser adotada, por exemplo. Esse
documento deve estar correto, sem ambigüidades, completo,
consistente, classificado por importância e/ou estabilidade dos
requisitos, verificável, modificável e rastreável, além de ser
entendível pelos usuários, organizado e conciso. Não há um nome
padrão para esse documento, podendo ser adotado, dentre outros,
“Especificação de Requisitos de Software (ERS)”, “Documento de
Requisitos” ou “Especificação Funcional”.
Este documento descreve:
o escopo e os objetivos do software;
os serviços e as funções que o software deve fornecer;
as informações sobre o domínio de aplicação do software;
as restrições sob as quais o software deve operar;
as propriedades gerais do software, tais como atributos de
qualidade e desempenho;
as definições de outros softwares com os quais deve interagir; e
as restrições ao processo de desenvolvimento adotado.
Uma informações importante neste documento é indicar a fonte dos
requisitos, seja uma pessoa, um grupo ou documento. Outras
informações importantes são os problemas que se pretende
resolver, além das razões e justificativas da escolha de cada
solução ou decisão tomada, as demais alternativas consideradas,
os fatores avaliados e as argumentações que guiaram cada
decisão ou solução. Estes dados adicionais enriquecem a visão do
software.
O documento pode ser descrito em linguagem natural, em notações
e linguagens semi­formais ou formais. Combinações também são
possíveis.
A linguagem natural facilita a comunicação, pois é expressiva e
A linguagem natural facilita a comunicação, pois é expressiva e
flexível, mas é pobre para capturar as semânticas do modelo,
possibilita ambigüidades. Permite um fácil entendimento pelos
usuários, mas a ausência de semântica possibilita a livre
interpretação.
Uma notação semi­formal reflete a estrutura e utiliza semântica
com alguma verificação de consistência – é o caso da UML
(Unified Modeling Language) com diagramas e relacionamentos.
Os métodosformais descrevem artefatos de software de forma
difícil de compreensão e, por isso, requerem maior tempo de
aprendizado, pois não são legíveis para usuários não técnicos.
Não existe um limite claro entre a engenharia de requisitos e o
início da fase de projeto do softwaredando margem ao dilema “o
que” versus “como”. Os requisitos são obtidos na engenharia de
requisitos (“o que”) ao passo em que são organizados, agrupados e
documentados na hierarquia proposta para o projeto de arquitetura
(“como”), de forma a organizar uma estrutura de sub­sistemas para
o projeto.
Algumas diretrizes propostas ajudam a melhorar a estrutura e
organização do documento:
definir uma estrutura padrão para o documento, contendo, em
geral, uma parte comum, mas permitindo algumas variantes e
seções opcionais;
explicar como cada classe de leitores deve usar o documento;
incluir um sumário de requisitos;
incluir uma seção explicando por que o software é necessário e
como irá contribuir para os objetivos gerais de negócio da
organização;
definir termos especializados em um glossário;
organizar o leiaute do documento para facilitar a leitura;
auxiliar os leitores a encontrar a informação, incluindo recursos
tais como listas de conteúdo e índices e organizando os
requisitos em capítulos, seções e sub­seções identificadas; e
tornar o documento fácil de alterar.
Validação de Requisitos
Depois de documentados os requisitos devem ser validados quanto
à consistência e à completude. Fase ideal para a correção de erros
antes do desenvolvimento (Blaschek, 2002). Validar significa avaliar
o software durante ou ao final do processo de desenvolvimento. O
objetivo é verificar se o resultado satisfaz o usuário, se foram
solucionadas todas as demandas e se existem falhas. A validação
se cumpre quando os requisitos e modelos documentados atendem
às reais necessidades e requisitos dos usuários. A meta é garantir
que este documento possa ser aprovado antes de ser usado como
base para o desenvolvimento do software.
A verificação ou validação é executada por clientes, usuários,
especialistas de domínio, engenheiros de requisitos, gerentes do
projeto, projetistas do software e pelos gerentes de testes.
Processos como o modelo CMM – Capability Maturity Model e o
padrão ISO/IEC TR 15504 podem ajudar na verificação e a
validação contribuindo inclusive com a garantia de qualidade do
software.
Várias técnicas complementares de verificação e validação dos
requisitos têm sido propostas, tais como análise dos
requisitos, revisão técnica formal, análise de rastreabilidade,
prototipação, validação, ou não, de modelos automática,
inspeção, testes de requisitos e planejamento inicial do teste
do software.
Apesar das atividades de análise de requisitos e validação de
requisitos serem abordadas em separado, elas têm muito em
comum, pois envolvem julgar se as necessidades dos usuários
estão descritas de forma apropriada e se estão sendo verificados
os problemas nos requisitos. Ambas podem ser executadas em
paralelo, mas existem diferenças importantes entre elas. A análise
de requisitos preocupa­se em investigar os requisitos elicitados
junto aos usuários e ainda não discutidos com eles, que muitas
vezes estão incompletos e expressos de forma não estruturada e
informal. A validação de requisitos deve ter, idealmente, um
conjunto completo e acordado de requisitos como ponto de partida.
Na Engenharia de Requisitos, a validação leva a uma revisão e
aprovação da documentação por todos os envolvidos no processo,
que se torna um contrato de desenvolvimento de software.
Mudanças de requisitos solicitadas depois que a documentação
estiver aprovada poderão ser consideradas. No entanto, o cliente
deve estar ciente de que cada mudança posterior pode ser uma
extensão do escopo do software e, por conseguinte, pode aumentar
o custo e/ou alongar o prazo de entrega.
Gerência de Requisitos
Freqüentemente usuários e especialistas propõem mudanças nos
requisitos, resultantes de fatores como a descoberta de erros,
omissões, conflitos e inconsistências nos requisitos, melhor
entendimento por parte dos usuários de suas necessidades, entre
outros. Isso pode originar novos requisitos, problemas técnicos, de
cronograma ou de custo, mudança nas prioridades do cliente
devido a mudanças no ambiente de negócios, o aparecimento de
novos competidores, mudanças econômicas, mudanças na equipe,
mudanças no ambiente onde o software será instalado e, ainda,
mudanças organizacionais ou legais.
Essas solicitações de mudanças podem surgir durante o processo
de engenharia de requisitos, ao longo do processo de software ou,
ainda, após a implantação do produto de software. Diante deste
cenário destaca­se a atividade de gerência de requisitos.
A gerência de requisitos apóia as demais atividades abordadas e
se preocupa em gerenciar as mudanças nos requisitos já
acordados.
Outra atividade associada é a manutenção de uma trilha de
mudanças identificando o gerenciamento dos relacionamentos
entre os requisitos e as dependências entre o documento de
requisitos e demais artefatos produzidos.
Existe uma preocupação com os procedimentos, processos e
padrões a serem usados para gerenciar as mudanças. Ela deve
permitir o registro das solicitações de mudança e a identificação
dos requisitos afetados pela mudança solicitada, além de avaliar o
impacto das mudanças, os riscos, os custos e benefícios, os
recursos e alterações no cronograma, obter a aprovação dos
clientes e, então, documentar, projetar e implementar a mudança.
Se as mudanças não forem controladas, alterações com baixa
prioridade podem ser implementadas antes de outras de alta
prioridade e modificações com custo alto, que não são
realmente necessárias, podem ser aprovadas. A rastreabilidade
também é importante, pois garante descrições da vida de um
requisito por todo o ciclo de vida de desenvolvimento do software.
(2) Projetos alternativos
Projetistas de interação não costumam ser treinados para criar
projetos alternativos. O resultado é que poucas soluções
alternativas são geradas. Ter muitas idéias e gerar opções diversas
para poder então extrair uma boa idéia é uma prática que deveria
ser mais comum dentro das equipes de desenvolvimento. Isto pode
ser feito em diferentes etapas do processo de criação ou geração
de soluções.
Reuniões de Brainstorms, por exemplo, contribuem para o
levantamento de requisitos, mas também oferecem idéias
alternativas de interação no início do projeto. Existem outras forma
de manter esta prática em outros pontos do desenvolvimento do
projeto. Técnicas emprestadas de outras áreas podem ajudar,
como por exemplo, os aspectos do design tradicional que ajudam
em situações já estabelecidas de compreensão e entendimento do
produto.
Mas tudo isso precisa ser comunicado, afinal foi gerado um plano
que deverá ser expresso de forma que permita ser revisto,
revisado e melhorado. Este plano utilizará formas diversas de
apresentação, tais como esboços preliminares, diagramas,
protótipos, entre outros. A combinação de técnicas será mais
efetiva na comunicação. Outros dois aspectos importantes na
comunicação do plano é o cuidado no uso de jargões e notações
técnicas e a qualidade da redação dos documentos.
Escolher um design alternativo implica tomar decisões acerca
dos procedimentos de interação pensados e dos dispositivos para
entrada e saída de dados, além do formato da informação. Além
disso devem ser considerados o fácil acesso, a eficiência no uso, o
retorno adequado, o tempo de resposta, a qualidade e quantidade
de informação. Qualidade pode ser a chave para a escolha do
melhor protótipo, mas  isso depende da definição do critério de
qualidade que precisa ser estabelecido.
Produzir projetos alternativos depende do pré­requisito sobre
a compreensão das necessidades, dos usuários e das
tecnologias disponíveis para elaborar soluções e determinaras
melhores soluções dentre as diversas alternativas. Os protótipos de
projetos alternativos podem ser não funcionais ou funcionais, mais
ou menos elaborados e devem ser desenvolvidos por meio
de wireframes, mockups de telas e protótipos de papel para testes
iniciais com o usuário.
(3) Versões interativas
Embora protótipos não funcionais ofereçam uma boa idéia do
comportamento dos procedimentos de interação, são as versões
interativas que fornecerão uma sensação mais realística do
processo. A escolha do protótipo dependerá do tempo e orçamento
destinado ao projeto. O importante é que existam formas de
comunicar os processos e condições para poder analisá­los como
se fossem o produto final.
O protótipo de papel é uma solução de baixa fidelidade, mas
barata e simples de ser realizada também nesta
etapa. Ela ajuda a verificar as condições de interação do sistema
com desenhos simples das telas e dos processos.
(4) Avaliação
No processo de avaliação centrada no usuário é dito que o usuário
se torna o co­designer do projeto.  Sua participação normalmente
aponta alterações de melhoria nos sistemas, mas este
envolvimento pode acontecer ao longo de todo o desenvolvimento
do projeto com participações do usuário. Ele é envolvido em
processos de observação, conversas, entrevistas, mas o objetivo é
sempre testar o sistema e seus processos de interação – e não o
usuário. Falaremos mais sobre isso nos últimos capítulos onde
veremos técnicas  e procedimentos adequados à esta atividade.
Projetos alternativos são utilizados nas primeiras avaliações e
também podem utilizar usuários. Independente do formato da
avaliação a qualidade do protótipo direciona os objetivos da
avaliação conforme abordagens de baixa, média e alta fidelidade
(Reis, 2004).
MAS NÃO TEMOS TEMPO DE DOCUMENTAR!
Em projetos em que o cronograma é definido com data de entrega
“para ontem”, qualquer atividade de projeto e documentação acaba
sendo prejudicada. Os procedimentos mínimos para a elaboração
de documentos exigem tempo, principalmente as atividades de
entrevistas e ajustes. Mas pelo menos a regra de negócio precisa
estar claramente estabelecida.
Bom! A fórmula da solução rápida NÃO EXISTE! A entrevista
e/ou outra abordagem de reconhecimento do processo do negócio
e das condições de envolvimento dos usuários são de extrema
necessidade. Se isso não puder ser feito por uma equipe alocada
par este fim, utilize qualquer outro recurso para entender a
atividade, o processo e seus usuários. A resolução do problema
poderá não ser a ideal, mas os problemas decorrentes poderão ser
minimizados para o usuário e cliente do produto.
Como fazer isso então? Tente criar estratégias rápida de
definição de processos de interação por meio de entrevistas
rápidas com o cliente e, se possível, com algum usuário
representativo. A documentação pode acontecer de forma não
estruturada durante as entrevistas. Uma dica é fazer o maior
número de questionamentos possível para não errar na hora do
desenvolvimento. DOCUMENTE O MÁXIMO QUE PUDER,
mas OBJETIVE O MÍNIMO para viabilizar a CONSTRUÇÃO DE
TELAS.
Uma boa opção para um projeto com prazo apertado é tocar as
atividades de projetos alternativos em paralelo. Assim,
alguns wireframes, ou mesmo telas, podem ser iniciadas para
colaborar na construção de uma documentação. As telas poderão
apresentar o produto na forma de um protótipo não funcional antes
da implementação – e das decisões tomadas por programadores
(preservadas as exceções, programadores costumam tomar
decisões voltadas à estrutura da programação e seus bancos de
dados, desconsiderando usuários e processos de interação
usáveis). Protótipos só são possíveis após o levantamento de
requisitos. Mas se o cenário exigir, tente viabilizar os passos 1
(Necessidades) e 2 (projetos alternativos) em paralelo.
Considere o uso de diagramas estruturais para entender o
escopo geral e, se houver tempo, explorar tarefas críticas. Muitas
ferramentas ajudam na criação de diagramas para estruturar uma
seqüência lógica de atividades em diferentes níveis de abstração
(caneta e papel, MS­Visio, Axure, Morae, PowerMapper, Word,
Open Office, etc). Detalhamentos podem ser gerados de acordo
com o tempo disponível. Quanto mais detalhado mais claro se torna
o processo que deverá ser desempenhado pelos diferentes atores
do sistema.
Uma solução descomplicada de documentação
Pagani (2008) oferece uma forma de documentação rápida, prática
e de fácil entendimento pelo desenvolvedor e cliente. Elabore uma
macro­arquitetura de informação do sistema ou website com um
diagrama da estrutura de navegação, faça os wireframes das telas
e os diagramas estruturais. Naturalmente isso não pode ser feito
sem uma conversa para entendimento das necessidades, mas
acelera e simplifica o processo de documentação. Saiba mais
em http://blog.talitapagani.com.
Figura 10 – Diagramas propostos por Pagani (2008) em modelo de documentação
descomplicada
5. Modelagem do desempenho das tarefas
A engenharia semiótica oferece uma visão mais detalhada do
processo de design de forma que o designer tenha uma variedade
maior de visões do usuários na utilização de algo. Ela difere do IHC
pois abrange um enfoque maior da comunicação designer–sistema­
usuário. Segundo Prates (2006) a modelagem de interação em
engenharia semiótica permite prever a interação entre usuário e
sistema a partir do que seriauma conversa predefinida pelo
designer. Esta conversa é representa os possíveis passos do
usuários e as possíveis respostas e processamentos do sistema. A
modelagem da interação é a especificação de todas as
possíveis conversas que os usuários poderão travar com o
sistema. Dentre deste contexto deve ser modelado:
O conteúdo de uma conversa; e
A forma como acontece esta conversa.
A modelagem do desempenho da tarefa é a tradução das
interações de um produto. Isto pode ser apresentado formalmente,
com uso de métodos tradicionais (TAG – task­action grammars ou
UAN – user action notation) utilizando ou não dicionário de termos
ou pode ser feito informalmente. As tarefas devem ser
consideradas sem a influência de elementos de interface, mas
devem levar em conta o comportamento do usuário e do sistema ao
longo do processo de utilização do produto. Isso pode ser feito por
meio de qualquer esquema que permita o reconhecimento do fluxo
de tarefa como mostra a Figura 11, e pode ser utilizada qualquer
ferramenta que permita o desenho deste esquema. Existem, no
entanto, algumas ferramentas que se propõe a facilitar este
processo.
Figura 11 ­ Exemplo de um projeto de interação na forma de mapa conceitual de
sistema com relações das tarefas associadas à três perfis de usuários
desenvolvido em Visio.
Na engenharia semiótica existem técnicas que permite a
modelagem do desempenho das tarefas realizadas pelos usuários.
Uma delas é o modelo de interação MoLIC proposto na PUC­Rio
(BARBOSA; PAULA, 2003). Este processo é muito prático de ser
utilizado em sistemas com funcionalidades limitadas. Pode ser
utilizado em avaliações preditiva (feitas por especialistas que
observam, por meio da modelagem de interação, se o projeto é
adequado e viável) ou para, somente modelar com clareza e
detalhes as tarefas do usuário. O resultado obtido por esta
modelagem é gráfico e podem ser obtidos com o uso software
desenvolvido especificamente para este fim (SANGIORGI;
BARBOSA, 2009 e SILVA, 2004).
MoLIC é linguagem para modelagem da interação com o usuário
que permite construir diagramas que simulam uma conversa entre
os usuários e o projetista do software. A linguagem é baseada na
engenharia semiótica e utiliza diagramas para a construção destes
diálogos. Para suportar o desenvolvimento destes projetos foi
desenvolvido o MoLIC Designer, uma ferramenta que ajuda na
construção destes diagramas. A pessoa que o utiliza precisa,
apenas, ter o mínimo de conhecimento sobre a engenharia
semiótica.