2 PROJETANDO INTERAES

Este captulo apresenta as definies sobre o projeto de interao com o usurio (PIU), o que e para que servem os processos de interao e as atividades do projeto de interao. Apresenta ainda as questes prticas do PIU que inclui necessidades e requisitos, projetos alternativos, verses interativas, avaliao e as diversa condies envolvidas no processo de documentao dos artefatos nas etapa de desenvolvimento do projeto de interao com o usurio. So tratadas ainda consideraes emergenciais para o projeto de interao e modelos de ciclo de vida na rea de IHC e uma forma de projetar a interao por meio da engenharia semitica.

1. Contextualizao comum encontrar o termo Design de Interao, mas prefiro no entrar em detalhes sobre o significa do de termo Design[1] e utilizar uma traduo mais objetiva para o termo: Projeto. Sendo assim, quando falarmos de Projeto de Interao estaremos falando de Design de Interao. Na interao homem computador os processos que caracterizam dilogos so formados por aes empregadas por uma entidade comunicativa na qualidade de usurio ou computador. O objetivo provocar uma troca de informaes: respostas s reaes geradas por estmulo. A isto se denomina interao. Dentro deste escopo, garantir um processo efetivo e com sucesso para o dilogo passa pelo Projeto de Interao com o Usurio, o PIU. O que e de onde vem o projeto de interao? Segundo Saffer (2007) esta disciplina proveniente de razes do design industrial, fatores humanos, interao homem computador, experincia do usurio dentre outras reas que ainda ajudam a definir os limites desta nova disciplina. Mas independente de suas razes o projeto de interao possui um carter essencialmente comportamental . Este comportamento est associado com algo praticamente intangvel e invisvel, algo difcil de ser definido como ideal. Diferente da aparncia, por exemplo, que pode causar reaes imediatas. O comportamento est associado a reao 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 experincia de manipulao ou uso. Qual o objetivo do projeto de interao? De forma simples tornar simples a vida de quem usa alguma coisa. definir processos para comunicao e interao humana com os artefatos ou produtos interativos, o que inclui decises sobre detalhes dos procedimentos da comunicao de ordem lgica ou fsica e comportamental. Mas ainda se discute sobre os objetivos desta disciplina. Dentro deste escopo so 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 interao, no entanto, so produtos tecnolgicos como softwares e equipamentos que favoream a utilizao de um sistema lgico. O que se pode projetar com interao? O projeto de interao oferece a um determinado produto todo um sistema de uso para usas funcionalidades. Em resumo o projeto de interao se aplica a QUALQUER COISA USVEL! Mais especificamente, possvel projetar uma variedade de equipamentos e produtos que permitam a troca de informaes entre as partes. Para entender melhor o objeto do projeto de interao preciso entender que podem ser utilizadas uma srie de elementos nas interaes que oferecem sada e entrada de dados para a gerao de estmulos permitindo, assim, um dilogo fluido. Sadas e entradas de dados acontecem por meio de INTERFACES que so compostas por artefatos como grficos, sons, superfcies que estimulam o tato, sinestesia[1], cheiros (Figura 5), os prprios equipamentos que recebem respostas do ambiente ou de humanos, entre outros.

Figura 5 - Interfaces em realidade virtual, com estmulo sinestsico e olfativo, apresentadas no Laval Virtual em 2004 na Frana. O sistema sinestsico oferece manipulao de objetos virtuais com retorno fsico que permite identificar dimenses e peso dos objetos virtuais. O estmulo olfativo do jogo Fragra (Visual-Olfactory VR Game) permite explorar relaes interativas entre viso e olfato. um jogo de erro e acerto onde os cheiros podem no 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 prximo ao nariz o usurios revelado em voz alta o nome da fruta correspondente ao cheiro que exalado pela luva. Ao pronunciar o nome da fruta o usurio pode acertar ou errar. O terceiro equipamento um Phantom, dispositivo que permite usar a fora para esculpir objetos virtuais.

Os estmulos computacionais esto associado s entradas dos dados que podem acontecer via voz (ou sons), via apontadores sensveis movimentao e controlados por dispositivos variados (mouse, olho, caneta, etc) aes de seleo (clique por exemplo) em formato mecnico (mouse) ou manual (touch screen), dentre outros que envolvem tecnologias ainda em pesquisa como o aproveitamento de impulsos neurais. No importa a quantidade de elementos de interface de entrada ou sada utilizados embora quanto maior o nmero de elementos mais complicado e complexo pode ser o processo de interao. O importante projetar os processos de troca de informao com o usurio de forma a usvel. A facilidade de uso a base do princpio de usabilidade. Mas s a base. Ser agradvel tambm algo que determinar a satisfao do usurio. Esta condio bsica nos leva a entender o termo USABILIDADE. Os vrios conceitos da usabilidade, no entanto, esto associados a diversos fragmentos que permitem a condio de COISA USVEL. Estes conceitos sero vistos mais a frente em forma de metas e princpios de um projeto de interao. Nos concentraremos agora em entender melhor o que o projeto de interao, quais so seus processo e as questes prticas do projeto de interao, para, ento, entender como acontece o ciclo de vida de desenvolvimento do projeto de interao.

2. O que projeto de interao? O projeto de interao uma atividade prtica e criativa que tem por objetivo final o desenvolvimento de um produto que ajude os usurios a atingirem suas metas. Segundo Verplank (2003) o projeto de interao deve responder sobre como o usurio far alguma coisa, como ele se sente e como ele sabe fazer esta coisa. Verplank ilustra este cenrio descrevendo que at o mais simples dispositivo requer manipulao, conhecimento e sentimento como acontece com o apertar de um boto 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 (boto) e sada (luz), mais complexo e demorado ser o modelo de compreenso do usurio sobre o fazer e sentir. Faz parte deste processo compreender aspectos relacionados interao em tarefas que do suporte s atividades cotidianas. O envolvimento do usurio no processo interativo por meio de mtodos centrado no usurio , tambm, de igual importncia. Outros modelos de projeto com outros centros tambm podem ser considerados, mas o usurio nosso cliente e como cliente, quase sempre tem razo. Para que tudo isso seja possvel importante iniciar bem, e para isso temos as conhecida tcnica de levantamento de necessidades e requisitos. MAS ser que os usurios sabem o querem?

Bom, as estratgias para a criao de um projeto de interao envolvem procedimentos que ajudam a responder questes deste tipo. Mas, to importante quanto isso entender se existe uma forma eficiente de comunicar um projeto ao usurio e faz-lo integrar-se equipe de desenvolvimento transformando-o num colaborador durante o desenvolvimento do produto. Isso se aplica de forma diferente para produtos novos ou atualizao tecnolgica.

Um produto novo ou um novo modelo conceitual pode realmente ser visualizado e compreendido pelo usurio? O projeto de interao trata da construo de um conhecimento lgico apresentado e comunicado de formas diversas tanto equipe de desenvolvimento quanto ao usurio final. Solues triviais popularizadas so mais fceis de serem absorvidas e entendidas pelos usurios. O que talvez d mais trabalho so modelos conceituais inovadores que exigem mais esforo do usurio para aprender o processo de interao. O sucesso desses produtos inovadores depender de aspectos como necessidade de mercado, grau de desafio de uso e satisfao proporcionado ao usurio. Ah! Inclua nesta frmula estratgia de marketing. Voc tem acompanhado as crticas do iPhone da Apple? iPhone se comporta muita mais como um computador do que qualquer outro tipo de gadget com exceo do celular Pocket PC/Windows. Ele compete com o PPC, mas mantm a vista somente o que necessrio para se tornar uma dispositivo amigvel. Lembrando minha experincia com o PPC, quem na terra deveria ver DLL ou EXE no seu celular?! Resposta: ningum, com exceo dos desenvolvedores. A Apple entende o que a Microsoft no entende. A ausncia de teclado no a melhor coisa do iPhone, mas ao mesmo tempo, como voc poderia ter um dispositivo to 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 algum na Apple colocou Jedi no dicion rio do iPhone, pro caso de eu ter uma emergncia no SMS durante uma conversa sobre Star Wars.Talvez o pessoal da Apple saiba mais sobre meus dados demogrficos do que eu mesmo. Trimb. Disponvel na URL: http://trimbo.blogspot.com/2007/06/apple-critic-iphone-review.html

3. Processos do projeto de interao Projetar a interao to importante quanto realizar os casos de uso, os diagramas de seqncia e todos os outros elementos relacionados documentao tradicional de sistema. O PIU, Projeto de Interao com o Usurio, envolve uma srie de processos e instrumentos relacionados a forma como o usurio ir se comportar quando estiver utilizando o sistema . Por isso envolve uma srie de artefatos e procedimentos. No 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 dimenso do projeto, cronograma, oramento, equipe, etc. O projeto de interao, no entanto, no visto como uma tcnica isolada e diferente dos processos conhecidos na engenharia de software e outras reas comuns. Uma forma de estabelecer uma relao detalhada do processo de interao descrever o processo rico em detalhes com descrio de objetivo, ao, resultado e detalhes (Quadro 1). Os resultados levam ao desenvolvimento de prottipos de telas (wireframes ou templates) que esclarecem o procedimento passo a passo de forma visual, minimizando as barreiras que possam gerar dvidas aos desenvolvedores e aos usurios. Quadro 1 Exemplo simplificado que detalha a atividade de fechar um programa
Objetivo Fechar o programa Ao esperada Localizar elemento visual e levar o cursor do mouse at o smbolo, boto, rtulo e clicar. Resultado Se houver arquivo aberto com alteraes a serem salvas oferecer mensagem Detalhes Deve existir mensagem

especfica para quando houver mais de um arquivo aberto.

permitindo a ao de salvar ou fechar sem salvar.

Uma soluo agregada ao UML Conhecida e utilizada por profissionais da rea de computao, a Unified Modeling Language (UML) baseada num processo unificado de desenvolvimento de software oferece condies de detalhamento das atividades de interao de um sistema. O problema que, quando utilizada para a documentao de projeto, dificilmente entra em detalhes to importantes da interao. Como o prprio modelo evidencia, no se observa a natureza iterativa e incremental do processo de desenvolvimento para manuteno e ajustes de problemas. Alm disso no oferece destaque para a interface com o usurio. Diante disto Hudson (2000)

prope uma extenso do processo unificado que incorpora as 10 tcnicas mais populares em projeto de interfaces (Figura 6). O objetivo centrar o processo ainda mais no usurio para obter sistemas mais usveis.

Figura 6 - Processo UML alterado para suportar as atividades do projeto de interao. Em vermelho as etapas inseridas que auxiliam no projeto de interao. (Hudson, 2000)

Na Figura 6, em vermelho, observam-se os pontos em que este processo sofreu alteraes destacando a adio das atividades de: Identificao e desenvolvimento de cenrios de uso: Tcnicas relevantes: cenrios de uso (com base em dados colhidos em observaes de potenciais usurios na realizao de trabalho, por exemplo) e avaliao de sistemas existentes. Anlise de contexto: Tcnicas relevantes: anlise de usurio/identificao de perfis, identificao de tarefas e estabelecimento de requisitos de usabilidade. Projeto da interface: Tcnicas relevantes: projeto de navegao, projeto visual da interface e prottipos de baixa fidelidade. Avaliao de usabilidade: Tcnicas relevantes: avaliao de usabilidade por especialistas e teste informal de usabilidade.

4. Atividades do projeto de interao De forma geral podem ser observadas quatro atividades bsicas que definem o processo do projeto de interao (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 usurio alvo e o tipo de suporte til que o produto deve oferecer. Para isso fundamental iniciar uma abordagem centrada no usurio. 2. DESENVOLVER PROJETOS ALTERNATIVOS QUE VO DE ENCONTRO AOS REQUISITOS: Atividade central do projeto de interao. quando surgem as idias que devem atender aos requisitos, as quais devem ser geradas com base em algum tipo de suporte. So as sub-atividades da gerao de idias. O projeto conceitual ou o modelo conceitual do produto ganha forma juntamente com a descrio sobre o que o produto far, como se comportar e parecer. O projeto fsico pode, ento, ser

iniciado com detalhes de interao e de interfaces, o que pode incluir o estudo de cores, sons, imagens, menus, animaes, cones, etc. 3. CONSTRUIR VERSES INTERATIVAS DE MANEIRA QUE POSSAM SER COMUNICADAS E ANALISADAS: Fornecer meios de simular o processo de interao. Afinal, como os usurios sabero e verificaro se as necessidades esto sendo atendidas? As verses prototipadas so os meios mais conhecidos para mostrar ao usurio como um produto est sendo modelado e verificar a primeira reao de aceite. Mas isso no significa que deva ser uma verso funcional. Prottipos em papel podem ser desenvolvidos e aplicados com rapidez, so baratos e eficazes na busca de problemas nas primeiras fases do projeto. O usurio tem uma noo real de como ser a interao. 4. AVALIAR O QUE EST SENDO CONSTRUDO E MEDIR SUA ACEITABILIDADE: So formas de determinar a usabilidade e aceitabilidade do produto utilizando vrios critrios, tais como nmero de erros cometidos pelo usurio, atratividade, preenchimento dos requisitos, etc. No substitui testes de qualidade que certificam o produto final. Mas ajudam a verificar se todo ou parte do produto encontra-se em condio 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 documentao como no decorrer da programao. A exemplo do UML proposto para o projeto de interao, pode-se identificar que as atividades de interao precisam ser reconsideradas em diferentes etapas do processo. Mas a etapa crtica, a que precisa de muita ateno, o levantamento ou elicitao de requisitos.

Figura 7 - Atividades bsicas do PIU

Independente do momento do projeto devem ser consideradas algumas caractersticas-chave no PIU: usurios envolvidos no desenvolvimento do projeto, identificao ou especificao de metas de usabilidade no incio do projeto e complementao e iterao (repetio) nas atividades bsicas com nfase nos processos de avaliao. Considere, portanto: 1. Foco no usurio: Se no for possvel garantir seu envolvimento considere o desenvolvimento de solues voltadas para o usurio e contexto de uso especfico. Em outras palavras, projetar e avaliar pensando como o usurio, focar nas tarefas como se estivessem sendo realizadas para o usurio e dar ateno aos processos e mensagens de retorno. 2. Critrios especficos de usabilidade: Os objetivos especficos devem ser claramente documentados, pois isso ajuda na idealizao de diferentes alternativas de projeto. Desta forma fica mais fcil identificar metas de usabilidade e, posteriormente, verificar o atendimento dos princpios de usabilidade. 3. Iterao: Significa repetio, que neste caso, se refere aos processos de testes e avaliaes para o refinamento do projeto, ainda com base no retorno do usurio. O envolvimento do projetista e do usurio ajuda a definir uma srie de critrios para o desenvolvimento do projeto (domnio, requisitos, necessidades, desejos, aspiraes e muitos outros direcionadores). Este processo conduz ao entendimento da necessidade da interao, muito importante quando se trata de um produto inovador onde as idias precisam ser revisadas luz do retorno do usurio. _____________________ ALGUMAS QUESTES PRTICAS DO PIU possvel encontrar diferentes listas de atividades para o processo de interao. Tambm fcil encontrar uma srie 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 interao com o usurio baseado em duas abordagem: 1. FERRAMENTAS DE NEGOCIAO: elas propiciam a comunicao de idias por meio de reunies, discusso em grupos, servios de fruns, entrevistas participativas. O importante desta abordagem gerar resultados de forma documentada.

2.

PRODUO DE ARTEFATOS: so passos mais objetivos para o desenvolvimento do projeto de interao que inclui atividades de: Conceitualizao: produzido com o auxlio das primeiras atividade de levantamento de requisitos e resulta na produo de: o o o o o mapa mental dos conceitos para o usurio; lista dos aspectos de requisitos eleitos como importantes de forma a adequ-los curva de aprendizado do usurio; e definio dos contextos de uso para condies culturais, sociais, simblicas e tecnolgicas; Estruturao: Diagrama de interao social, fluxograma de interao, wireframes, prottipos de baixa fidelidade; Apresentao: Detalhes estticos, definio de aspectos visuais como a identidade visual do produto, leiaute e prottipos de alta fidelidade.

Perceba a conexo entre as atividades da produo de artefatos e 3 das 4 atividades que estabelecem o processo do projeto d e interao: CONCEITUALIZAO: Est associada ao levantamento de requisitos ESTRUTURAO: Est associada aos projetos alternativos. Embora possa gerar discusses interminveis, oferecer mais de uma soluo de interface, quando o cronograma permite, permite visualizar tarefas, elementos de interface e processos de diferentes pontos de vista. APRESENTAO: So as verses interativas que permitem iniciar avaliao mais detalhadas.

_____________________ (1) Necessidades e requisitos Para entender as questes prticas envolvidas no projeto de interao no precisa ir muito longe. Estas atividades tambm acontecem em outras reas. Por exemplo, na arquitetura necessrio conhecer o cliente, futuro utilizador do espao construdo. Para isso necessrio 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) alm de viabilidades legais que ajudaro, por exemplo, a identificar o zoneamento possvel (organizao dos espaos para alocao da edificao no terreno), dando incio ao partido do projeto (primeiro prottipo visual dos espaos a serem edificados) e prosseguindo com os detalhamentos do projeto. As atividades iniciais esto baseadas no estudo e envolvimento do usurio e legislao. Em projetos urbanos, por exemplo, estes usurios so em maior nmero e to diversificado quanto na utilizao de sistemas computacionais, e por isso devem ser consideradas questes sociais e costumes e rotinas da populao para o projeto de espaos urbanos. Tudo isso s possvel com a realizao de etapas de entrevistas envolvendo, dentro das possibilidades, aqueles que faro uso do espao. Na engenharia de produto so feitas pesquisas de satisfao com relao a produtos no mercado. Clientes potenciais tambm so chamados para oferecer sugestes sobre novos propostas de produtos. Os profissionais envolvidos so de reas como design grfico, arquitetura, urbanismo, engenharias (industriais de produo, de software) entre muitos outras. Cada disciplina apresenta sua prpria interpretao e processos para desenvolvimento do projeto. Mas podemos entender a tarefa de projetar a interao 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) execuo prtica do produto. De qualquer forma, no importa a rea. Cada uma delas trata, do seu jeito, questes similares, tais como: conhecimento sobre o uso e domnio-alvo do produto; investigao sobre o uso de artefatos; entender as restries prticas quanto ao material, custo e viabilidade; e soluo do problema antes da execuo levando em conta os usurios. Diante de uma srie de consideraes importante notar, ainda, possveis compensaes em que devem ser pesadas a habilidade do usurio e o equilbrio de necessidades conflitantes. As necessidades e requisitos para o projeto de interao no so diferentes daqueles conhecidos pelo analista de sistema definidos para realizar o documento tcnico de sistemas computacionais. Mas no projeto de interao comum encontrar o usurio

como foco de qualquer atividade. Embora outros[1] modelos de centros de projeto possam ser encontrados na literatura, o centro no usurio o mais explorado. Os processos mais comuns para o desenvolvimento de projeto so baseados no USURIO, na ATIVIDADE e na AO. Esta atividade deve ser realizada em parceira direta com usurios e clientes. As atividades definidas por processos como RUP (Rational Unified Process) e UML (Unified Model Language) so os procedimentos conhecidos e comumente adotados. Eles oferecem muitos recursos para a tarefa de documentao das necessidades e estabelecimento dos requisitos.

Qual a diferena entre Necessidade e Requisito? Primeiro, requisito um derivado de necessidade. Veja o exemplo para as diferenas para um produto do tipo telefone:

Engenharia de requisitos A engenharia de requisitos um processo criterioso de identificao 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 no atendimento das expectativas do usurio. Para isso necessrio realizar uma exaustiva e criteriosa fase de definio de requisito. Os nveis de abstrao dos requisitos so (Figura 8): de negcios (objetivos do usurio): documento de escopo ou de viso; de usurios (descreve as atividades que os usurios devero desempenhar); e funcionais (o que o sistema deve possuir para que os usurios possam executar suas atividades para alcanar os objetivos de negcio).

Figura 8 - Nveis de abstrao dos requisitos

Outros requisitos necessrios sugeridos por Blaschek (2002): requisitos no funcionais (padres e regulamentos com os quais o sistema precisa ter conformidades, como por exemplo, descrio de interfaces externas e requisitos de desempenho); restries (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 elicitao, anlise e negociao, documentao, validao e gerncia 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 so repetidas, a exemplo dos requisitos apresentados por Blaschek (2002), que determinam apenas quatro etapas incluindo elicitar os requisitos, analis-los, gerar a documentao e a realizar a validao. As outras atividades so: Anlise de domnio (considerada apenas por 1 autor) Elicitao de requisitos (considerada por 4 autores) Modelagem (considerada por 1 autor) Anlise de requisitos (considerada por 3 autores) Negociao (considerada por 2 autores) Documentao (considerada por 1 autor) Especificao de requisitos (considerada por 2 autores) Anlise da Especificao (considerada por 1 autor) Verificao (considerada por 1 autor) Comunicao (considerada por 1 autor) Concordncia (considerada 2 autores) Validao (considerada por 1 autor) Documentao do processo, das decises e das fontes dos requisitos (considerada por 1 autor) Gerncia de requisitos (considerada 2 autores) Evoluo de requisitos (considerada 2 autores)

Macro-modelo de atividades do processo de engenharia de requisitos

Como no existe um processo nico que contemple todas estas fases tambm no existem limites definidos entre as atividades. Mas cada uma delas pode ser utilizada na prtica com interpolaes entre elas. A idia que o processo seja realizado at que o grau de satisfao de todos os usurios seja alcanado ou at que a presso do cronograma precipite o incio da fase de projeto do software (indesejvel). As atividades mais importantes, no entanto elicitao, anlise de requisitos, documentao, validao e gerncia de requisitos - so aquelas destacadas em negrito e sero discutidas a seguir com mais detalhes.

40% a 60% de todos os problemas encontrados em um projeto de software so causados por falhas na fase de levantamento de requisitos (Leffingell, 1997). Perguntar s pessoas o que elas precisam, pode no ser suficiente. Muitas vezes elas no sabem necessariamente o que possvel e, at mesmo, o que realmente querem. necessrio, portanto, chegar no usurio compreendendo: suas caractersticas *; suas capacidades *; o que esto tentando alcanar; como fazem isso atualmente; e questionar se elas atingiro o objetivo com mais eficincia com outro tipo de suporte.

* As caractersticas e capacidades podem variar e, neste caso, temos os grupos de usurios por perfil. Exemplo que influencia nas decises e que nem sempre so pensadas para os usurios tpico: tamanho das mos podem afetar no tamanho e posio dos botes; capacidades motoras podem afetar a adequao de certos dispositivos de entrada e sada; o uso da fora deve ser considerada em um equipamentos para crianas (tipo de usurio criana/adulto tempo de vida do equipamento); e nervosismo, questes culturais, outros.

Antes de continuar reforcemos o entendimento sobre Engenharia de Requisito e Elicitao de Requisito. Engenharia de Requisito: Macromodelo composto de uma srie de atividades para tratamento de requisitos. Elicitao de Requisito: Uma das atividades da Engenharia de Requisitos.

Elicitao de Requisitos Elicitar requisitos a tarefa de descobrir, identificar, deduzir, extrair, evocar ou obter dados que contribuam com uma anlise de qualidade (Blaschek, 2002). importante ter boa redao, declarao de viso e escopo do sistema. Usurios, clientes e especialistas de domnio so identificados e trabalham junto com os engenheiros de requisitos para descobrir, articular e entender a organizao como um todo. So consideradas atividades para entender o domnio da aplicao, os processos de negcio especficos, as necessidades que o software deve atender, os problemas e deficincias dos softwares atuais, os diferentes pontos de vista dos participantes do processo, bem como as oportunidades e restries existentes, os problemas a serem resolvidos, os servios e o desempenho requeridos, as restries de hardware, dentre outros. A atividade no se resume a perguntar s pessoas o que desejam. Tambm no uma simples transferncia de conhecimento. Existem vrias tcnicas de elicitao, sendo que a escolha depende do tempo e dos recursos disponveis alm do tipo de informao que necessita ser elicitada. As tcnicas de elicitao de requisitos podem ser classificadas em (Batista, 2003): tcnicas tradicionais: englobam tcnicas genricas, tais como o uso de questionrios e pesquisas, investigao de documentos e entrevistas; tcnicas de elicitao em grupo: exploram as dinmicas de grupo, tais como tcnicas de grupos focados focus groups, workshops RAD Rapid Application Development e JAD Joint Application Development; prototipao: tem sido usada quando existe incerteza sobre os requisitos ou quando se torna necessrio ter um retorno inicial dos usurios, podendo ser combinada com outras tcnicas; tcnicas dirigidas a modelos: fornece um modelo especfico para o tipo de informao a ser obtido e conduz o processo de elicitao englobando os mtodos baseados em objetivos e mtodos baseados em cenrios; tcnicas cognitivas: incluem tcnicas desenvolvidas originalmente para aquisio de conhecimento em sistemas baseados em conhecimento. Dentre elas, pode-se citar anlise de protocolo e classificao de cartes (card sorting). tcnicas contextuais: surgiram nos anos 90 como uma alternativa s tcnicas tradicionais e cognitivas e incluem o uso de tcnicas de etnografia, tais como observao dos participantes e anlise de conversao.

A escolha da tcnica 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 bsica para o entendimento do comportamento organizacional e social. Embora exista incompatibilidade entre estes formatos as abordagens podem ser complementares. As tcnicas mais prticas baseiam-se em entrevistas, brasinstorms, prototipao, JAD e mtodo JK. 1. Entrevistas: Dificilmente deixam de ser utilizadas, pois trata-se da forma mais natural de comunicao entre as pessoas. Mas embora paream simples elas exigem procedimentos mais especficos do que apenas perguntar. A tcnica 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 so 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 rgida e seqencial. semi estruturadas utiliza uma lista estruturada mas permite a ocorrncias de questes extra ou so anotadas observaes extra mencionadas pelo entrevista. no estruturadas parte de um ponto estabelecido (ou no) e anda de acordo com a motivao do entrevistado.

2. Brainstorm: bastante utilizada e conhecida, mas no envolve, necessariamente, o usurio. Ela serve para gerar idias a partir de discusses realizadas por um conjunto de especialistas onde todos colaboram com as idias de todos, com a liberdade que s a criatividade pode fornecer. Neste processo so feitas crticas e julgamentos. Esta tcnica pode ser aplicada no incio da fase do desenvolvimento quando pouco do projeto conhecido e so necessrias idias novas. Os resultados de uma sesso bem estabelecida contribuem com boas solues para todas as questes exploradas.

3. Prototipao: Este processo utilizado para detalhar requisitos de software definidos pelo cliente. Este tcnica pode ser utilizada para avaliao ou verificao dos possveis procedimentos de interao entre o homem e a mquina. O modelo permite ainda refinar os requisitos identificados na fase de concepo, sejam eles funcionais ou no. 4. Joint Application Design JAD: Desenvolvida pela IBM no fim dos anos 70 esta tcnica tem base na criao de sesses de trabalho estruturadas utilizando dinmica de grupo e recursos visuais. Participam analistas e usurios para, juntos, projetarem um sistema com a compreenso adequada dos requisitos bsicos e podendo chegar, inclusive, no desenvolvimento de leiaute de telas e relatrios. A idia manter a cooperao e o entendimento entre os participantes. O papel dos desenvolvedores ajudar os usurios a formular problemas e explor-los com o objetivo de indicar possveis solues. Os usurios se sentem parte integrante da equipe de desenvolvimento. O JAD baseado em quatro princpios bsicos: dinmica de grupo com tcnicas que possam aumentar a capacidade dos indivduos; uso de tcnicas audiovisuais para aumentar a comunicao e o entendimento; manuteno do processo organizado e racional; e utilizao de documentao-padro, que preenchida e assinada por todos os participantes. A tcnica 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 sesso de JAD desempenham seis diferentes papis: lder da sesso; representantes do usurio; especialista; analista; representantes dos sistemas de informao; e patrocinador executivo.

A tcnica ajuda a identificar os assuntos que podem necessitar de rastreamento e fornece uma perspectiva multifacetada dos requisitos. Sesses JAD permitem aos analistas coletar simultnea e eficientemente uma grande quantidade de requisitos do sistema junto a uma gama de usurios-chave. So teis por considerar necessidades especficas dos usurios. O JAD tambm pode ser usado em conjunto com outra tcnica de elicitao como, por exemplo, a prototipao. medida que os requisitos so obtidos nas sesses pode-se construir prottipos que demonstrem alguma funcionalidade destes requisitos.

5. Mtodo KJ (Kawakita Jiro) uma atividade que ajuda a realizar uma lista de requisitos por investigao contextual ou de afinidades onde a observao dos envolvidos ajuda a estabelecer e reunir prioridades para se chegar em um consenso de grupo. O mtodo KJ foi desenvolvido pelo japons Kawakita Jiro que buscava reduzir o tempo da realizao da tarefa de elicitao de requisitos. Para elaborar o processo devese 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 pblico-alvo; quais tarefas ele deve estar apto a realizar ao final do programa de formao; o que este pblico j sabe; em quanto tempo estas pessoas devem formar o conhecimento; e quais sos os recursos disponveis para realizar este programa. Uma equipe experiente consegue realizar duas rodadas por hora da dinmica. Isso significa que em at 3 horas seria possvel realizar a anlise. um processo de anlise de necessidades com consenso em tempo recorde. Veja um exemplo do processo em Iderios.com (Lopez, 2006) para a elaborao de um programa de formao com KJ-Method.

Anlise e negociao de requisitos onde os requisitos elicitados so compreendidos e detalhadamente analisados por todos os interessados no sistema (Blaschek, 2002). Esta atividade auxilia na descoberta de problemas nos requisitos levantados e na obteno de concordncia sobre as alteraes. Como resultado a satisfao de todos os envolvidos deve ser atingida. Se na etapa anterior houve uma elicitao dos requisitos mais importante, nesta fase necessrio estabelecer um conjunto acordado de requisitos completos, consistentes e sem ambigidades, 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 informao. Eles manipularo os requisitos de forma que possam agrup-los de acordo com regras estabelecidas (funcionalidade, por exemplo), faro exploraes e classificaes que estabelecero prioridades. Assim os requisitos so examinados em relao sua necessidade, completeza, consistncia, riscos, viabilidade tcnica, operacional e econmica, bem como em busca de omisses, ambigidades, sobreposies e conflitos. Problemas e conflitos encontrados nos requisitos so ressaltados. Todos os indivduos ( stakeholders) classificam os requisitos com problemas e negociam at chegarem a um acordo sobre as modificaes a serem feitas. Esta atividade pode ser direcionada por necessidades pr-estabelecidas, por requisitos especficos para os diferentes usurios, por restries de projeto e de implementao e pelo oramento e cronograma disponveis.

Documentao de Requisitos Requisitos compreendidos, analisados e aceitos. Agora s documentar. A proposta de integrao do processo associado ao projeto de interao ao UML ajuda a identificar o momento em que o projeto de interao deve ser realizado (Blaschek, 2002). a representao dos resultados obtidos at agora, em um documento oficial e formal que contm os requisitos do software com descries detalhadas sobre o que ele far, mas ainda sem descrever como fazer o software em termos de tecnologia ou linguagem de programao a ser adotada, por exemplo. Esse documento deve estar correto, sem ambigidades, completo, consistente, classificado por importncia e/ou estabilidade dos requisitos, verificvel, modificvel e rastrevel, alm de ser entendvel pelos usurios, organizado e conciso. No h um nome padro para esse documento, podendo ser adotado, dentre outros, Especificao de Requisitos de Software (ERS), Documento de Requisitos ou Especificao Funcional.

Este documento descreve: o escopo e os objetivos do software; os servios e as funes que o software deve fornecer; as informaes sobre o domnio de aplicao do software; as restries sob as quais o software deve operar; as propriedades gerais do software, tais como atributos de qualidade e desempenho; as definies de outros softwares com os quais deve interagir; e as restries ao processo de desenvolvimento adotado. Uma informaes importante neste documento indicar a fonte dos requisitos, seja uma pessoa, um grupo ou documento. Outras informaes importantes so os problemas que se pretende resolver, alm das razes e justificativas da escolha de cada soluo ou deciso tomada, as demais alternativas consideradas, os fatores avaliados e as argumentaes que guiaram cada deciso ou soluo. Estes dados adicionais enriquecem a viso do software. O documento pode ser descrito em linguagem natural, em notaes e linguagens semi-formais ou formais. Combinaes tambm so possveis. A linguagem natural facilita a comunicao, pois expressiva e flexvel, mas pobre para capturar as semnticas do modelo, possibilita ambigidades. Permite um fcil entendimento pelos usurios, mas a ausncia de semntica possibilita a livre interpretao. Uma notao semi-formal reflete a estrutura e utiliza semntica com alguma verificao de consistncia o caso da UML (Unified Modeling Language) com diagramas e relacionamentos. Os mtodos formais descrevem artefatos de software de forma difcil de compreenso e, por isso, requerem maior tempo de aprendizado, pois no so legveis para usurios no tcnicos.

No existe um limite claro entre a engenharia de requisitos e o incio da fase de projeto do software dando margem ao dilema o que versus como. Os requisitos so obtidos na engenharia de requisitos (o que) ao passo em que so organizados, agrupados e documentados na hierarquia proposta para o projeto de arquitetura (como), de forma a organizar uma estrutura de subsistemas para o projeto. Algumas diretrizes propostas ajudam a melhorar a estrutura e organizao do documento: definir uma estrutura padro para o documento, contendo, em geral, uma parte comum, mas permitindo algumas variantes e sees opcionais; explicar como cada classe de leitores deve usar o documento; incluir um sumrio de requisitos; incluir uma seo explicando por que o software necessrio e como ir contribuir para os objetivos gerais de negcio da organizao; definir termos especializados em um glossrio; organizar o leiaute do documento para facilitar a leitura; auxiliar os leitores a encontrar a informao, incluindo recursos tais como listas de contedo e ndices e organizando os requisitos em captulos, sees e sub-sees identificadas; e tornar o documento fcil de alterar.

Validao de Requisitos Depois de documentados os requisitos devem ser validados quanto consistncia e completude. Fase ideal para a correo 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 usurio, se foram solucionadas todas as demandas e se existem falhas. A validao se cumpre quando os requisitos e modelos documentados atendem s reais necessidades e requisitos dos usurios. A meta garantir que este documento possa ser aprovado antes de ser usado como base para o desenvolvimento do software.

A verificao ou validao executada por clientes, usurios, especialistas de domnio, engenheiros de requisitos, gerentes do projeto, projetistas do software e pelos gerentes de testes. Processos como o modelo CMM Capability Maturity Model e o padro ISO/IEC TR 15504 podem ajudar na verificao e a validao contribuindo inclusive com a garantia de qualidade do software. Vrias tcnicas complementares de verificao e validao dos requisitos tm sido propostas, tais como anlise dos requisitos, reviso tcnica formal, anlise de rastreabilidade, prototipao, validao, ou no, de modelos automtica, inspeo, testes de requisitos e planejamento inicial do teste do software. Apesar das atividades de anlise de requisitos e validao de requisitos serem abordadas em separado, elas tm muito em comum, pois envolvem julgar se as necessidades dos usurios esto descritas de forma apropriada e se esto sendo verificados os problemas nos requisitos. Ambas podem ser executadas em paralelo, mas existem diferenas importantes entre elas. A anlise de requisitos preocupa-se em investigar os requisitos elicitados junto aos usurios e ainda no discutidos com eles, que muitas vezes esto incompletos e expressos de forma no estruturada e informal. A validao de requisitos deve ter, idealmente, um conjunto completo e acordado de requisitos como ponto de partida. Na Engenharia de Requisitos, a validao leva a uma reviso e aprovao da documentao por todos os envolvidos no processo, que se torna um contrato de desenvolvimento de software. Mudanas de requisitos solicitadas depois que a documentao estiver aprovada podero ser consideradas. No entanto, o cliente deve estar ciente de que cada mudana posterior pode ser uma extenso do escopo do software e, por conseguinte, pode aumentar o custo e/ou alongar o prazo de entrega.

Gerncia de Requisitos Frequentemente usurios e especialistas propem mudanas nos requisitos, resultantes de fatores como a descoberta de erros, omisses, conflitos e inconsistncias nos requisitos, melhor entendimento por parte dos usurios de suas necessidades, entre outros. Isso pode originar novos requisitos, problemas tcnicos, de cronograma ou de custo, mudana nas prioridades do cliente devido a mudanas no ambiente de negcios, o aparecimento de novos competidores, mudanas econmicas, mudanas na equipe, mudanas no ambiente onde o software ser instalado e, ainda, mudanas organizacionais ou legais. Essas solicitaes de mudanas podem surgir durante o processo de engenharia de requisitos, ao longo do processo de software ou, ainda, aps a implantao do produto de software. Diante deste cenrio destaca-se a atividade de gerncia de requisitos. A gerncia de requisitos apia as demais atividades abordadas e se preocupa em gerenciar as mudanas nos requisitos j acordados. Outra atividade associada a manuteno de uma trilha de mudanas identificando o gerenciamento dos relacionamentos entre os requisitos e as dependncias entre o documento de requisitos e demais artefatos produzidos. Existe uma preocupao com os procedimentos, processos e padres a serem usados para gerenciar as mudanas. Ela deve permitir o registro das solicitaes de mudana e a identificao dos requisitos afetados pela mudana solicitada, alm de avaliar o impacto das mudanas, os riscos, os custos e benefcios, os recursos e alteraes no cronograma, obter a aprovao dos clientes e, ento, documentar, projetar e implementar a mudana. Se as mudanas no forem controladas, alteraes com baixa prioridade podem ser implementadas antes de outras de alta prioridade e modificaes com custo alto, que no so realmente necessrias, podem ser aprovadas. A rastreabilidade tambm importante, pois garante descries da vida de um requisito por todo o ciclo de vida de desenvolvimento do software.

(2) Projetos alternativos Projetistas de interao no costumam ser treinados para criar projetos alternativos. O resultado que poucas solues alternativas so geradas. Ter muitas idias e gerar opes diversas para poder ento extrair uma boa idia uma prtica que deveria ser mais comum dentro das equipes de desenvolvimento. Isto pode ser feito em diferentes etapas do processo de criao ou gerao de solues. Reunies de Brainstorms, por exemplo, contribuem para o levantamento de requisitos, mas tambm oferecem idias alternativas de interao no incio do projeto. Existem outras forma de manter esta prtica em outros pontos do desenvolvimento do projeto. Tcnicas emprestadas de outras reas podem ajudar, como por exemplo, os aspectos do design tradicional que ajudam e m situaes j estabelecidas de compreenso 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 apresentao, tais como esboos preliminares, diagramas, prottipos, entre outros. A combinao de tcnicas ser mais efetiva na comunicao. Outros dois aspectos importantes na comunicao do plano o cuidado no uso de jarges e notaes tcnicas e a qualidade da redao dos documentos. Escolher um design alternativo implica tomar decises acerca dos procedimentos de interao pensados e dos dispositivos para entrada e sada de dados, alm do formato da informao. Alm disso devem ser considerados o fcil acesso, a eficincia no uso, o retorno adequado, o tempo de resposta, a qualidade e quantidade de informao. Qualidade pode ser a chave para a escolha do melhor prottipo, mas isso depende da definio do critrio de qualidade que precisa ser estabelecido. Produzir projetos alternativos depende do pr-requisito sobre a compreenso das necessidades, dos usurios e das tecnologias disponveis para elaborar solues e determinar as melhores solues dentre as diversas alternativas. Os prottipos de projetos alternativos podem ser no funcionais ou funcionais, mais ou menos elaborados e devem ser desenvolvidos por meio de wireframes, mockups de telas e prottipos de papel para testes iniciais com o usurio.

(3) Verses interativas Embora prottipos no funcionais ofeream uma boa idia do comportamento dos procedimentos de interao, so as verses interativas que fornecero uma sensao mais realstica do processo. A escolha do prottipo depender do tempo e oramento destinado ao projeto. O importante que existam formas de comunicar os processos e condies para poder analis-los como se fossem o produto final. O prottipo de papel uma soluo de baixa fidelidade, mas barata e simples de ser realizada tambm nesta etapa. Ela ajuda a verificar as condies de interao do sistema com desenhos simples das telas e dos processos.

(4) Avaliao No processo de avaliao centrada no usurio dito que o usurio se torna o co-designer do projeto. Sua participao normalmente aponta alteraes de melhoria nos sistemas, mas este envolvimento pode acontecer ao longo de todo o desenvolvimento do projeto com participaes do usurio. Ele envolvido em processos de observao, conversas, entrevistas, mas o objetivo sempre testar o sistema e seus processos de interao e no o usurio. Falaremos mais sobre isso nos ltimos captulos onde veremos tcnicas e procedimentos adequados esta atividade. Projetos alternativos so utilizados nas primeiras avaliaes e tambm podem utilizar usurios. Independente do formato da avaliao a qualidade do prottipo direciona os objetivos da avaliao conforme abordagens de baixa, mdia e alta fidelidade (Reis, 2004).

MAS NO TEMOS TEMPO DE DOCUMENTAR! Em projetos em que o cronograma definido com data de entrega para ontem, qual quer atividade de projeto e documentao acaba sendo prejudicada. Os procedimentos mnimos para a elaborao de documentos exigem tempo, principalmente as atividades de entrevistas e ajustes. Mas pelo menos a regra de negcio precisa estar claramente estabelecida. Bom! A frmula da soluo rpida NO EXISTE! A entrevista e/ou outra abordagem de reconhecimento do processo do negcio e das condies de envolvimento dos usurios so de extrema necessidade. Se isso no puder ser feito por uma equipe alocada par este fim, utilize qualquer outro recurso para entender a atividade, o processo e seus usurios. A resoluo do problema poder no ser a ideal, mas os problemas decorrentes podero ser minimizados para o usurio e cliente do produto. Como fazer isso ento? Tente criar estratgias rpida de definio de processos de interao por meio de entrevistas rpidas com o cliente e, se possvel, com algum usurio representativo. A documentao pode acontecer de forma no estruturada durante as entrevistas. Uma dica fazer o maior nmero de questionamentos possvel para no errar na hora do desenvolvimento. DOCUMENTE O MXIMO QUE PUDER, mas OBJETIVE O MNIMO para viabilizar a CONSTRUO DE TELAS. Uma boa opo 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 construo de uma documentao. As telas podero apresentar o produto na forma de um prottipo no funcional antes da implementao e das decises tomadas por programadores

(preservadas as excees, programadores costumam tomar decises voltadas estrutura da programao e seus bancos de dados, desconsiderando usurios e processos de interao usveis). Prottipos s so possveis aps o levantamento de requisitos. Mas se o cenrio 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 crticas. Muitas ferramentas ajudam na criao de diagramas para estruturar uma seqncia lgica de atividades em diferentes nveis de abstrao (caneta e papel, MS-Visio, Axure, Morae, PowerMapper, Word, Open Office, etc). Detalhamentos podem ser gerados de acordo com o tempo disponvel. Quanto mais detalhado mais claro se torna o processo que dever ser desempenhado pelos diferentes atores do sistema.

Uma soluo descomplicada de documentao Pagani (2008) oferece uma forma de documentao rpida, prtica e de fcil entendimento pelo desenvolvedor e cliente. Elabore uma macro-arquitetura de informao do sistema ou website com um diagrama da estrutura de navegao, faa os wireframes das telas e os diagramas estruturais. Naturalmente isso no pode ser feito sem uma conversa para entendimento das necessidades, mas acelera e simplifica o processo de documentao. Saiba mais em http://blog.talitapagani.com.

Figura 10 Diagramas propostos por Pagani (2008) em modelo de documentao descomplicada

5. Modelagem do desempenho das tarefas A engenharia semitica oferece uma viso mais detalhada do processo de design de forma que o designer tenha uma variedade maior de vises do usurios na utilizao de algo. Ela difere do IHC pois abrange um enfoque maior da comunicao designersistema- usurio. Segundo Prates (2006) a modelagem de interao em engenharia semitica permite prever a interao entre usurio e sistema a partir do que seria uma conversa predefinida pelo designer. Esta conversa representa os possveis passos do usurios e as possveis respostas e processamentos do sistema. A modelagem da interao a especificao de todas as possveis conversas que os usurios podero travar com o sistema. Dentre deste contexto deve ser modelado: O contedo de uma conversa; e A forma como acontece esta conversa. A modelagem do desempenho da tarefa a traduo das interaes de um produto. Isto pode ser apresentado formalmente, com uso de mtodos tradicionais (TAG task-action grammars ou UAN user action notation) utilizando ou no dicionrio de termos ou pode ser feito informalmente. As tarefas devem ser consideradas sem a influncia de elementos de interface, mas devem levar em conta o comportamento do usurio e do sistema ao longo do processo de utilizao 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 prope a facilitar este processo.

Figura 11 - Exemplo de um projeto de interao na forma de mapa conceitual de sistema com relaes das tarefas associadas trs perfis de usurios desenvolvido em Visio.

Na engenharia semitica existem tcnicas que permite a modelagem do desempenho das tarefas realizadas pelos usurios. Uma delas o modelo de interao MoLIC proposto na PUC-Rio (BARBOSA; PAULA, 2003). Este processo muito prtico de ser utilizado em sistemas com funcionalidades limitadas. Pode ser utilizado em avaliaes preditiva (feitas por especialistas que observam, por meio da modelagem de interao, se o projeto adequado e vivel) ou para, somente modelar com clareza e detalhes as tarefas do usurio. O resultado obtido por esta modelagem grfico e podem ser obtidos com o uso software desenvolvido especificamente para este fim (SANGIORGI; BARBOSA, 2009 e SILVA, 2004). MoLIC linguagem para modelagem da interao com o usurio que permite construir diagramas que simulam uma conversa entre os usurios e o projetista do software. A linguagem baseada na engenharia semitica e utiliza diagramas para a construo destes dilogos. Para suportar o desenvolvimento destes projetos foi desenvolvido o MoLIC Designer, uma ferramenta que ajuda na construo destes diagramas. A pessoa que o utiliza precisa, apenas, ter o mnimo de conhecimento sobre a engenharia semitica. Assim como a linguagem MoLIC ajuda a pensar a interao a ferramenta ajuda a estruturar e organizar o projeto como um todo. O MoLIC ajuda a modelar os cenrios de interao baseado na engenharia semitica com recursos grficos similares ao UML. O funcionamento da linguagem MoLIC utiliza padres grficos de representao dos acontecimentos[1]. O projeto dos caminhos de interao (caminhos que o usurio pode percorrer: fluxo normal, caminhos alternativos, de exceo ou erro) consiste da definio da cena (cenrio de determinado assunto composto por cada passo da interao na qual so definidos os dilogos entre usurio e sistema) (Quadro 2 Exemplo de cena (Prates, 2006)Quadro 2), do tpico do dilogo (tema central) e do foco do dilogo (trecho de conversa sobre algum aspecto especfico do tpico). Quadro 2 Exemplo de cena (Prates, 2006) Os Termos U: e S: referem-se a usurio e sistema.
Tpico: marcar uma reunio Em um sistema de agenda, marcar reunio pode constituir uma cena contendo o seguinte dilogo: Foco: compromissos desta semana U: Preciso examinar a semana atual. S: Ei-la. Foco: compromissos da prxima semana U: No h horrio disponvel para marcar minha reunio de 3 horas. Deixe-me ver a prxima semana. S: Aqui est. Foco: horrios disponveis Foco: novo compromisso U: Tem horrio disponvel na 3 feira, a partir das 14h. U: Vou marcar um compromisso.

Foco: dados do novo compromisso

S: Que tipo de compromisso? Com quem e onde? U: Reunio com meu chefe. Ainda no sei onde ser.

Foco: verificao do novo compromisso

S: OK, marcado

A modelagem na prtica deve conter incio e fim (Figura 12 Erro! Fonte de referncia no encontrada.), mas a extenso do grfico depender da complexidade do dilogo. Este processo interno do dilogo o mais importante, pois depender de como o dilogo poder ser conduzido. So as transies que representam a mudana de rumo na conversa causada por uma fala do usurio (a partir de uma cena) ou por uma fala do preposto (a partir de um processamento). A transio, que pode acontecer a partir de uma cena ou a partir de um processo, representada por uma seta preta que indica a direo da transio e por um rtulo que pode ser (Figura 13): uma pr-condio: condies que devem ser satisfeitas para que o usurio ou preposto possa enunciar a fala correspondente. uma ou mais falas do usurio ou do preposto do designer . No caso do usurio, trata-se de enunciados do usurio que causam a transio. No caso do preposto, trata-se de falas que revelam resultados de algum processamento do sistema que causam a transio. uma ps-condio: condies que passam a ser verdadeiras durante a transio.

Figura 12 - Exemplo de modelagem MoLic com incio e fim

Figura 13 - Modelos de interao: transies (Prates, 2006) e definio de elementos do dilogo

Figura 14 - Detalhes do dilogo no MoLic (Modelagem da tarefa utilizando MoLic (Prates, 2006))

A fala de recuperao de breakdonw apontada na Figura 14serve para prevenir o erro. A preveno pode acontecer de trs formas: passivas, ativa ou apoiada (Figura 15).

Figura 15 - Preveno de erro (na ordem: passiva, ativa, apoiada) (Serg, 2008)

O tempo de resposta do processamento e, desta forma, da resposta ao usurio deve ser tratado conforme Figura 16 com uma instruo anexada ao dilogo de processamento. Outra condio so as formas como so tratados os fluxos de interao (Figura 17). Segundo Serg (2008) para cada meta ou fragmento de conversa na interao necessrio considerar a sequencia de atividades, os resultados possveis, os problemas e dificuldades e as alternativas. Por fim, para entender como a interao vira interface, acompanhe as sugestes de Serg na Figura 18.

Figura 16 Representao do tempo de resposta (Serg, 2008)

Figura 17 - Diferentes fluxos para o mesmo processo (Serg, 2008). Estes exemplo mostram acessos ubquos, onde mais de uma atividade encontrada em uma cena.

Figura 18 - Da interao para a interface

6. Consideraes emergenciais para o projeto de interao Tem-se por princpio que todo produto possui um objetivo de uso. Ao se adquirir o produto entende-se que ele atender sua funo. Isso leva a crer que o objeto deva ser eficaz, pois atender ao seu propsito. difcil que algum compre algo que no atenda ao seu objetivo. Mas se por algum motivo um produto mau projetado cair nas mos de um usurio, ele ainda tentar utiliz-lo. Mesmo havendo uma frustrao inicial poder haver, ainda, um voto de confiana e a continuidade de tentativas na esperana de obter sucesso. Mas se o usurio no obtiver xito haver frustrao, xingamento, abandono, crticas, etc. Mas o que ser que este projetista imaginava durante o desenvolvimento deste produto? Bom, pode no ser culpa do projetista, afinal maus resultados de projetos de interao podem ocorrer por corte, no previso oramentria ou falta de tempo destinado s avaliaes.

Considerando, portanto, que o projeto de interao leva em conta a manipulao de elementos por um determinado USURIO, este indivduo naturalmente visto como o elemento importante do projeto de interao. Ao considerar o usurio imagina-se que a interao projetada depender de suas capacidades e habilidades em compreender e manipular os elementos de interface. Pensar o usurio durante o desenvolvimento do projeto, ento, evitar o sacrifcio do mesmo e uma possvel degradao do produto e da marca.

SACRIFICAR O USURIO NO UMA OPO NO PROJETO DE INTERAO.

E no deveria ser tambm uma opo da empresa. Afinal desconsider-los pode gerar resultados catastrficos. Quando o usurio no pode ser utilizado durante o desenvolvimento do projeto esta preocupao deve ser redirecionada. Algumas solues de projeto podem ser tomadas por meio de parmetros de comparao entre bons e maus exemplos. BOM x RUIM Solues baseadas no mundo real podem caracterizar uma boa opo de projeto. Mas nem sempre a melhor sada. Exemplo disso quando o modelo coloca em risco a segurana do usurio ou do equipamento. A tecnologia de realidade virtual, por exemplo, oferece opes de simulao de atividades impossveis ou difceis de serem executadas na vida real. As atividades so projetadas para parecerem o mais real possvel, mas sem causar prejuzo ao usurio. Do que adiantaria, por exemplo, replicar as condies reais de uso de um laboratrio de qumica ou fsica se o sistema oferecesse ao usurio exatamente as mesmas condies de perigo do ambiente real. Alguns comportamentos precisam ser reinterpretados para fornecer a informao de perigo ao usurio. Falaremos mais sobre isso quando discutirmos metforas e modelos conceituais. Como descobrir se um projeto bom ou ruim? A diferena entre projeto de interao Bom e Ruim o resultado sobre ser fcil de aprender, ser eficaz, atender ao objetivo e ser agradvel. Estes parmetros podem ser compreendidos como um resumo da usabilidade, e isso pode ajudar a comparar o Bom e o Ruim, identificando pontos fracos e pontos fortes. O projeto RUIM normalmente identificado por pontos fracos que causam irritabilidade, confuso, incapacidade (pela ineficincia do sistema ou dificuldade de uso), desistncia, entre outros. MAS ISSO FCIL DE DESCOBRIR. DIFCIL : descobrir por que difcil de ser utilizado? descobrir como seria possvel melhor-lo? Os meios mais eficazes de descobrir isso permitindo que usurios reais utilizem o produto enquanto so observados.

7. Ciclo de vida do projeto de interao Modelos de ciclo de vida sugerem processos que representam conjuntos de atividades e suas relaes para o projeto, desenvolvimento e distribuio do produto. As muitas atividades envolvidas no processo do projeto de interao so similares e os modelos tradicionais de ciclo de vida da engenharia de software podem ser aplicados no projeto de interao (cascata, RAD, espiral, tec). A forma como as tarefas so tratadas pode diferenciar no resultado desses projetos. Mas percebe-se que modelos simplificados so os mais praticados na rea de IHC, embora projetos de grande escala necessitem de modelos de ciclo de vida mais elaborados. Na rea de IHC poucos modelos de ciclo de vida foram propostos, mas os que merecem destaque so: o modelo simplificado proposto por Preece et. Al (2005), o modelo estrela sugerido por Hartson e Hix em 1989 e o modelo da engenharia de usabilidade proposto por Mayhew em 1999. O CICLO DE VIDA SIMPLIFICADO do projeto de interao possibilita um nmero ilimitado de repetio do ciclo, desde que a ltima atividade sempre seja um teste. Este modelo foi proposto por Preece et. Al aps observaes sobre como a prtica do projeto de interao acontece na vida real. Ele possui o foco no usurios e determina e possibilita que um produto evolua da forma que for compreendida como melhor pela equipe, havendo uma nica limitao de repeties: o oramento. Perceba que este modelo contempla as 4 etapas bsicas do PIU: 1) Identificar necessidade e estabelecer requisitos, 2) Construir verses alternativas, 3) Projeto/re-projeto (prottipos) e avaliao. A sequncia das atividades nos ciclos iterativos (nas repeties) depende da dinmica estabelecida pela equipe e dos problemas encontrados nas avaliaes (Figura 19).

Figura 19 - Modelo de ciclo de vida Simples para projeto de interao

O CICLO DE VIDA ESTRELA uma proposta que no especifica um ordenamento das atividades, mas sua flexibilidade exige que uma avaliao sempre seja feita antes de iniciar uma nova atividade. Este modelo surgiu das observaes de Hartson e Hix que verificaram que dois processos eram utilizados por designers de interface como modelos de ciclo de vida. O ANALTICO com caracterstica de organizao, formalidade e com uma viso que partia do sistema para a viso do usurio e o SINTTICO caracterizado pela criatividade, livre pensamento e improviso com a viso que partia do usurio para a do sistema. Este modelo inclui a implementao e a anlise de tarefas. As outras atividades vo de encontro com as atividades bsicas dos projeto de interao: 1) necessidade e requisitos, 2) verses alternativas (projeto conceitual), 3) prottipos e avaliao (Figura 20).

Figura 20 - Modelo de ciclo de vida Estrela

O modelo de CICLO DE VIDA da engenharia de usabilidade envolve detalhes complexos sobre o desenvolvimento do produto, mas permite que pessoas com pouco conhecimento de usabilidade trilhem este caminho com mais facilidade. O modelo que apoiado na engenharia de software baseado em trs tarefas essenciais: 1) Anlise de requisitos, 2) Projeto/teste/desenvolvimento e 3) Instalao. Fica claro neste modelo a necessidade de identificao das metas de usabilidade na tarefa 1 (Figura 21).

Figura 21 - Modelo de ciclo de vida da Engenharia de Usabilidade

8. Atividades Crie um celular de tamanho pequeno (mximo de 3 x 3 centmetros) com opes de realizar ligaes e incluir nmeros na agenda do telefone. Realize as seguintes atividades: Qual modelo de ciclo de vida sua equipe usaria? Quais so as necessidades e requisitos e como foram realizadas estas atividades? Esboce a idia de um modelo interativo e pelo menos um projeto alternativo? Que tipo de verso interativa foi produzida? Como a equipe avaliaria o seu produto?

1. 2. 3. 4.

Do que trata o PIU, para que serve e como funciona? Qual a relao entre o PIU e a usabilidade? Quais so as 4 atividades do PIU? Identificar necessidades e requisitos uma das atividades do PIU. Esta j uma atividade tradicionalmente realizada no desenvolvimento de sistemas. Mas existe uma considerao que d a esta atividade um enfoque mais especfico e cuidadoso, e que nem sempre considerado pelos analistas tradicionais. Qual ?

5. 6.

Qual a frmula rpida para o levantamento de necessidades e definio de requisitos? Como isso deve ser feito? Na engenharia de requisitos so citados 3 nveis de abstrao dos requisitos. Quais so?

7. 8. 9.

Engenharia de requisitos um macromodelo de atividades. Destaque 5 destas atividades discutidas na apostila. Qual a diferena entre Engenharia de Requisitos e Elicitao de Requisitos? Cite algumas tcnicas de elicitao de requisitos foque naquelas que possuem aplicao mais objetiva.

10. Qual a diferena entre Elicitao de Requisito e Anlise de requisitos? 11. A documentao de requisitos, uma das atividades da engenharia de requisitos, pode ser entendida como Especificao de requisitos, Documento de Requisitos ou Especificao de Requisitos. Isto est correto? 12. A documentao de requisitos, uma das atividades da engenharia de requisitos, pode ser descrita, apenas, em um modelo formal de linguagem. Isto est correto? 13. Em que momento da engenharia de requisitos a documentao que detalha os requisitos se torna um objeto que poderia ser usado como contrato de desenvolvimento de softwares? 14. Para que servem wireframes ou mockups? 15. Como funcionam os prottipos de papel? 16. Qual a caracterstica que torna o modelo de ciclo de vida ESTRELA apropriado para projetos de interao? 17. Cite trs modelos de ciclo de vida sugeridos para uso em projetos de interao. 18. Desenvolva o modelo de tarefa para o seguinte cenrio: Seu Eustquio precisa de dinheiro e vai at o banco. Ele entra em sua conta e percebe que houve um crdito esperado h dias, mas resolve verificar o extrato da sua conta. Ele verifica que houve o dbito automtico de sua conta de luz de R$100,00. Verifica que h saldo suficiente e ento prossegue com a retirada do dinheiro. Ele digita o valor referente quantia desejada e confirma a operao com sua senha. Ele obtm uma confirmao impressa da transao e verifica o seu saldo mais uma vez. Ao final sai do sistema.