Research, Society and Development, v. 6, n. 1, p. 47-63, set.

2017

Tcnicas para requisitos funcionais de Interfaces Homem Computador com recursos em

elicitao
Techniques for functional requirements of Human Computer Interfaces with resources
in elicitation
Juliano Schimiguel
Universidade Cruzeiro do Sul, Brasil
E-mail: schimiguel@gmail.com
Leonardo de Fabris Lopes
Centro Universitrio Salesiano de So Paulo, Brasil
E-mail: profleolopes@gmail.com
Cecilia Sosa Arias Peixoto
Centro Universitrio Salesiano de So Paulo, Brasil
E-mail: cecilia.sosaarias@gmail.com
Carlos Adriano Martins
Universidade Cruzeiro do Sul, Brasil
E-mail: ead.adriano@gmail.com

Recebido: 26/06/2017 Aceito: 01/11/2017

Resumo
A Interface Homem Computador (IHC) parte fundamental nos critrios de aceitao de um
software, na determinao de seu tempo de vida e no interesse que o mesmo despertar em
seus usurios. Apesar de sua importncia, as fbricas de software, em geral, pouco se
aprofundam em anlises e investimentos na rea de IHC, tendo seu foco profissional em
regras de negcio e funcionalidades implementadas. O objetivo utilizar o uso de papel e
caneta com as tcnicas j conhecidas e reduzir o tempo de elaborao das ideias e elicitao
de requisitos de IHC. A metodologia adotada para o desenvolvimento deste trabalho foi a
reviso bibliogrfica e anlise a partir de um estudo de caso. O resultado obtido demonstra
que as tcnicas existentes na literatura so adequadas para realizar o correto levantamento dos
requisitos e que, quando combinadas da forma proposta, os requisitos podem ser avaliados
antes da fase de codificao, economizando tempo e recursos.
Palavras-chave: Interface humano computador, Anlise de requisitos, Anlise de usabilidade,
Designer, Prottipo.

47
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

Abstract
The Computer Human Interface (IHC) is a fundamental part of the acceptance criteria of a
software, determining its life time and the interest that it will arouse in its users. In spite of
their importance, the software factories generally do not go much further in analyzing and
investing in the IHC area, having their professional focus on business rules and functionalities
implemented. The goal is to use the use of paper and pen with the techniques already known
and reduce the time of elaboration of ideas and elicitation of IHC requirements. The
methodology adopted for the development of this work was the bibliographic review and
analysis based on a case study. The obtained results demonstrate that the existing techniques
in the literature are adequate to carry out the correct survey of the requirements and that, when
combined in the proposed way, the requirements can be evaluated before the coding phase,
saving time and resources.
Keywords: Human interface computer, Requirements analysis, Usability analysis, Designer,
Prototype.

1. Introduo

A Engenharia de Software (ES) tem como principal motivao especificao,

desenvolvimento e manuteno de sistemas. Atravs do uso de modelos abstratos e precisos, a
ES permite a um engenheiro modelar um sistema de informao, acompanhar todos os passos
do desenvolvimento de um software e produzi-lo de maneira econmica, com qualidade, de
modo que atenda aos requisitos do cliente (PRESSMAN, 2005). Uma das demandas mais
presentes hoje em dia consiste em desenvolver sistemas centrados nos usurios (GAMA et al,
2016), focando, principalmente, na usabilidade do sistema (CAETANO et al 2016; SANTOS
et al, 2017). O conceito da interface comumente abreviado na literatura como camada de
apresentao do sistema. Segundo Laurel (1990), uma interface uma superfcie de contato
que reflete as propriedades fsicas das partes que interagem, as funes a serem executadas e
o balano entre poder e controle. A Figura 1 apresenta os componentes da interface, o
software da interface, o software da aplicao, a interpretao do usurio e a ao.

48
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

Figura 1 Processo de interao Homem-Computador

Fonte: elaborado pelos autores

No processo apresentado na Figura 1, de extrema importncia que no existam

rudos no dilogo entre usurio e sistema. Os rudos so tudo o que o sistema pode entender
de forma errada requisio do usurio, ou as informaes que o requerente no receba do
sistema por algum motivo. A literatura sobre o tema IHC cita a importncia do dilogo,
recomentando que ocorra de maneira clara e coesa. Para que isto seja possvel, diversos ciclos
de vida, tcnicas e mtodos so empregados a fim de auxiliar aos projetistas de interfaces
durante a especificao e o desenvolvimento.
Tem-se observado que os mtodos convencionais da ES, utilizados na rea de
Interfaces, no tm levado a resultados satisfatrios devido a que no fornecem guias
suficientes para os sistemas interativos. Este trabalho prope tornar mais gil o processo de
levantamento de requisitos de IHC, com foco no estudo de usabilidade, abrangendo tambm
os outros requisitos de software. Segundo Sommerville, (2011), um dos pressupostos geis
minimizar a documentao, pois se utiliza mais a comunicao informal do que reunies
formais com documentos escritos. Isto garante entregas mais rpidas e fase de
desenvolvimento menos onerosa. O objetivo deste trabalho utilizar o uso de papel e caneta
com as tcnicas j conhecidas com o escopo de reduzir o tempo de elaborao das ideias e
elicitao de requisitos de IHC pela equipe de designers e sua comunicao para o cliente.
Este artigo apresenta as tcnicas complementares de elicitao de requisitos
fundamentais para evitar os rudos, ambiguidades e inconsistncias na fase de definio do
sistema (seo 2). A seo 3 apresenta um estudo de caso onde foi utilizada a tcnica de
Snyder (2003) e a seo 4 apresenta a concluso do trabalho.

2. Tcnicas complementares de elicitao de requisitos

Nesta seo so apresentadas tcnicas complementares para elicitao de requisitos de

49
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

um sistema interativo.
A tcnica de Mgico de Oz (KELLEY, 1985), consiste em simular efeitos de
computador, utilizando raciocnio humano. Isto , uma pessoa faz o papel da mquina
devolvendo a resposta para o usurio.
A tcnica pode ser utilizada no lugar de algoritmos complexos ou na avaliao de
diversos modos de interao como, reconhecimento de voz, e outras diversas tarefas em que
seja dispendioso utilizar sistemas informatizados (BARBOSA e SILVA, 2010).
importante para a correta utilizao da tcnica, um estudo sobre o escopo da
encenao. Este estudo dever discutir quais so os cenrios suportados pelo sistema, quais
funcionalidades sero encenadas, e quais as sadas esperadas para os mais diversos cenrios.
O ser humano capaz de alm de encenar responder de forma assertiva a uma entrada
inesperada. Para que a representao seja o mais semelhante possvel ao resultado
computacional, que ir a substituir a cena em alguma fase do projeto, um roteiro deve ser
fornecido ao ator que representa o computador (BARBOSA E SILVA 2010). Desta forma a
tcnica de Magico de Oz permite descobrir durante a sua aplicao se o usurio concorda com
as cenas ou no, se existem problemas no dilogo e fundamentalmente elicitar os requisitos,
verificar a usabilidade e viabilidade de forma econmica.
Outra tcnica muito utilizada de Mockup consiste em representar graficamente as
telas do sistema (BARBOSA E SILVA, 2010), (NIELSEN, 1993). O objetivo dos Mocks
semelhante ao dos prottipos, isto , ser um objeto de comunicao e gerar feedback. O
escopo de criao de Mocks menor em relao a prottipos, j que nenhuma funcionalidade
implementada, apenas o layout das telas do sistema concebido. Desta forma o tempo
despendido para a criao de Mocks tende a ser menor do que o aplicado na elaborao de
prottipos.
Estas representaes podem ser criadas em nveis incrementais. A primeira verso,
classificada como de baixa fidelidade pode ser desenhada a mo livre em papel, a prxima
verso feita de forma rpida no computador com o auxlio de uma ferramenta, poder ser
classificada como de alta-fidelidade dependendo da semelhana com um software real, e por
ltimo, a verso sendo desenvolvida em linguagem de programao, contendo apenas os
componentes de GUI (Graphical User Interface) (SNYDER, 2003), (BARBOSA E SILVA,
2010), (NIELSEN, 1993). Entre as ferramentas de suporte criao de Mocks podemos citar
Balsamic (2014), uma ferramenta paga para desenvolvimento gil de interfaces com estilo
rascunho. Outra ferramenta, a Just Mind (JUSTMIND, 2014) com verso on line, tem
semelhana com um ambiente de desenvolvimento, o que pode dificultar, visto que todos os

50
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

componentes possuem muitas opes e atributos. A ferramenta oferece um editor de regras de

negcio, no qual possvel adicionar controle, como por exemplo, um boto tomar uma
deciso baseada no estado e valores selecionados nos componentes. possvel desta forma,
simular o funcionamento do sistema, a navegao entre telas mesmo que de maneira pr-
definida pode se criar um roteiro e apresentar o sistema dentro deste contexto semelhante
cena criada na utilizao da tcnica de Magico de Oz, porm de forma automatizada. Atravs
da apresentao dos Mocks, os usurios podem refletir sobre as funcionalidades do sistema
permitindo a elicitao dos requisitos.
A tcnica de quadro de histrias Snyder (2003) uma forma de elicitar e comunicar
requisitos funcionais e no funcionais com os stakeholders do projeto e os projetistas do
sistema. A documentao das propriedades e comportamento do sistema feita atravs do
registro de uma histria de uso do sistema. Ela pode envolver apenas uma funcionalidade ou
um conjunto de funcionalidades correlacionadas para atingir um objetivo dentro do software
que est sendo especificado. A representao grfica desta histria no tem a necessidade de
ser esteticamente perfeita ou possuir uma concepo artstica (SNYDER, 2003).
Uma forma eficaz de formular as histrias em quadrinhos a tcnica denominada por
Klemmer et al (2006) de representao em estrela. Os usurios so representados na histria
em uma forma que se assemelha em uma estrela (Figura 2).

Figura 2 Exemplo do uso da tcnica de representao em estrela

Fonte: elaborado pelos autores

Esta forma de representao de baixa fidelidade no necessita curva de aprendizado ou
habilidade para ser reproduzida. Desta forma, mudando o preenchimento do interior do
desenho do personagem, fcil reproduzir diferentes usurios (SNYDER, 2003).
Cada quadro da histria, a comear pelo quadro inicial, retrata um passo para
completar uma tarefa dentro do sistema. Cada etapa representada em seu prprio quadro, de

51
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

forma sequencial, semelhante forma como so diagramadas as histrias em quadrinhos.

Todos os passos chaves para se atingir um objetivo dentro do sistema sero retratados. A
tcnica sempre ilustra o caminho de sucesso da aplicao e tem o objetivo de elicitar os
requisitos e verificar se o sistema fcil de usar (SNYDER, 2003).
O primeiro quadro a ser retratado o gatilho para a tarefa especificada. Deve
responder a pergunta Porque o Sr. Estrela deseja realizar esta tarefa?. Assim, so colocados
no quadro, os demais usurios envolvidos, o sistema que ser acessado, o ambiente, e o que
motivou o acesso. Este um diferencial desta forma de documentao. Ela especifica de
forma rpida e simples o contexto, do usurio quando a ao foi realizada, o tipo de usurio,
suas motivaes e at mesmo o sentimento que ele tem em relao a aplicao (animao,
ansiedade, preocupao). Com este tipo de prottipo, possvel comunicar ideias ao cliente,
equipe e demais stakeholders do software (SNYDER, 2003).
Uma das tcnicas amplamente aconselhadas e utilizadas so os prottipos de papel
(NIELSEN, 1993), (SNYDER, 2003). Snyder (2003) prope uma forma de elicitao de
requisitos atravs da criao de prottipos em papel dispondo apenas de materiais de
escritrio como papis, canetas coloridas, tesouras, durex e cola. Segundo Snyder (2003), esta
tcnica diferente de desenho ou esboo de telas em papel, como as MockUps. O autor define
o prottipo como um conjunto de telas mais funcionalidades representadas por desenhos
mo livre. proposto que nas fases anteriores a codificao e documentao os stakeholders,
possam realizar uma reunio com o intudo de discutir e esboar o sistema realizando
desenhos a mo livre das telas que iro compor o sistema. A Figura 3 apresenta um usurio
testando um prottipo em papel.

Figura 3 Usurio utilizando um prottipo em papel fonte Site UseIt

Fonte: USEIT (2012)

Durante o teste, alguns pontos podem ser verificados. Por exemplo, se os componentes

52
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

utilizados na montagem da tela permitem atingir o objetivo proposto, se o comportamento

sistmico da funcionalidade est claro a todos os participantes, se existem problemas de
layout na forma como os componentes foram organizados na tela e se algum requisito
funcional no foi levantado. As informaes provenientes da reunio entre os participantes
servem para a especificao dos requisitos do sistema (SNYDER, 2003).
Um debate respeito das alternativas de design pode ser fomentado, os programadores
podero induzir a escolha de solues tecnolgicas que lhes tragam alguma vantagem durante
fase de desenvolvimento, seja motivado pela facilidade de implementao que um framework
pode oferecer ou outra razo dependendo das caractersticas do projeto. A opinio dos
usurios tem um peso maior de deciso do que a opinio dos analistas (chamado de
desenvolvimento centrado no usurio pela ISO 13407 (International Organization for
Standardization). (SNYDER, 2003).
Com a devida maturidade, que pode ser adquirida pela repetio constante da prtica,
os participantes podero desenvolver um alto nvel de abstrao, sendo capazes, at mesmo,
de prever problemas que s poderiam ser observados por uma equipe de teste aps alguma
entrega do software. Segundo Netto (2010), em geral, 30% das funcionalidades atendem a
70% dos usurios. Esta proporo tambm mencionada nos processos de desenvolvimento
geis, de forma que encontrar as funcionalidades que representam estes 30% podem garantir o
sucesso de um projeto (SNYDER, 2003).
Um fator positivo desta tcnica que ela no gera nenhuma curva de aprendizado
sistmico e no utiliza nenhum recurso computacional. Portanto, qualquer cliente, possuindo
domnio em informtica ou no, est apto a participar da atividade. Esta prtica ajuda os
participantes a exercitarem a criatividade, e pode at mesmo servir como um momento de
descontrao (SNYDER, 2003).
Um ponto negativo desta abordagem que ela necessita de uma parceria slida entre
equipe de desenvolvimento e cliente. Pelo fato de que no papel teoricamente tudo possvel,
a experincia da equipe, especialmente dos especialistas em tecnologia da informao (TI)
exigida para direcionar o debate para requisitos que sejam aceitveis de acordo com a
tecnologia atual. A maturidade do cliente tambm fundamental para que possa abstrair as
representaes e consiga imaginar em algum nvel o produto real, transmitindo sua viso aos
demais membros.
Em casos onde este cenrio no for possvel ferramentas como JustMind (JUSTMIND,
2014) ou prottipos incompletos segundo as prticas de Nielsen (1993) podem ser teis.

53
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

3. A tcnica prottipos de papel

No cenrio de desenvolvimento de projetos de software, um grande avano a

aplicao de prticas de desenvolvimento gil para reduzir os custos de desenvolvimento e
entregar solues em menor tempo. Qualquer investimento gasto no levantamento de
requisitos, embora extremamente necessrio no projeto como um todo, pode ser visto como
um risco. Se o requisito for, por algum motivo, alterado o investimento em levantar este
requisito perdido. A tcnica proposta por Snyder (2003) foi escolhida tendo em
considerao um projeto com pouco investimento. Apresenta-se promissora por ser simples e
econmica. A base desta tcnica a comunicao atravs de papel. A escrita e a representao
por desenhos faz parte do cognitivo humano. O hbito de fazer anotaes pessoais comum
entre as pessoas, em especial entre os projetistas. Desta forma, a mente humana j est
condicionada a aprender e abstrair desenhos simples e anotaes manuscritas. No mundo
corporativo e em comunicaes formais, os trabalhos impressos so uma preferncia. Mesmo
assim, comum o papel ainda estar presente.
Segundo um estudo apresentado por Snyder (2003), ao entrarem em contato com uma
tela ou mesmo com uma Mock de computador impressa em papel, comum as pessoas darem
representao o valor de documentos, de forma a no se sentirem a vontade em rascunh-la
a mo ou alterar o seu contedo. Do ponto de vista de apresentao de conceitos de softwares,
isso ruim, uma vez que a equipe de desenvolvimento precisa constantemente do feedback do
cliente.
Algumas ferramentas de Mocks, como o Balsamic (2014), procuram assemelharem-se
a desenhos manuscritos justamente com a inteno, de quebrar este paradigma entre objeto
apresentado e um documento em sua verso final. Porm a criao das Mocks, utilizando
ferramentas informatizadas, ainda requer conhecimento na ferramenta selecionada. Neste
aspecto, o uso de papel economiza recursos do projeto.
Outro fator relevante da escolha da tcnica que o cliente no necessita ter
conhecimento tcnico para manipular as ferramentas utilizadas no desenvolvimento do
prottipo. Neste ponto, a utilizao de papel se demonstra um ganho. Para representar o
conceito de uma tela, no necessria uma habilidade artstica especifica. Da mesma forma
que na criao de histrias em quadros, com um pouco de tempo e material de escritrio, as
Mocks de tela podem ser produzidas sem maiores dificuldades pela equipe, apenas mantendo
o foco na comunicao e abstraindo o conceito de perfeio. Conforme Nielsen (1993),
prottipos so feitos para serem incompletos, logo para expressar uma ideia, uma folha com

54
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

alguns desenhos de tela so mais do que suficientes.

4. Metodologia

Para o presente estudo foram realizadas atividades de levantamento e especificao de

requisitos de IHC conforme apresentado na Figura 4.

Figura 4 resumo das atividades de levantamento de requisitos de IHC

Fonte: elaborado pelos autores

A primeira atividade a reunio com o cliente. Independentemente do ciclo de vida

adotado para o projeto, os designers tm por objetivo obter um modelo metal do sistema, uma
viso do negcio e da demanda do cliente. A atividade de classificao de usurios
destacada por diversos autores como Nielsen (1993), Shneiderman (1998), Shneiderman e
Plasaint (2010) e Netto (2010), entre outros, como de extrema importncia. necessrio
conhecer o ambiente onde o sistema ser aplicado, o perfil do usurio, seus conhecimentos e
sua rotina de trabalho. Posteriormente os designers desenvolvem o modelo de interao do
usurio (modelo mental).
Aps as trs atividades iniciais, uma boa tcnica para validar os requisitos, antes
mesmo da criao de documentos, a aplicao da tcnica de Quadros de Histria em Papel.
Atravs do desenho da histria durante a reunio, de forma gil, os integrantes discutem os
principais pontos do sistema, e as funcionalidades. importante ressaltar que os quadros

55
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

devero conter os pontos de incio, pessoas e ambiente envolvidos na funcionalidade

retratada.
Para a atividade de Checklist que valida a completude da especificao, foram
selecionadas as seguintes informaes:

x Quais so os passos descritivos para se alcanas esta regra de negcio?

x Que domnio est envolvido?
o O que o usurio ou sistema tem que fazer?
o Entradas e sadas do sistema
Levantamento de listas de domnios e valores pr-definidos.
Quais entradas sero controladas?
Quais restries sero aplicadas as entradas?
Quais campos em formulrios sero obrigatrios?
o Quais so os artefatos envolvidos?
o Quais artefatos esto envolvidos? Ex: mouse, teclado, tela sensvel ao toque, sensor
de movimentos, pranchas de desenho em alta resoluo, outros.
o Suporte especfico a hardware
Em uma tela sensvel ao toque, os usurios tm dedos maiores do que o
comum? Ex: Motoristas de caminho, eletricistas. Ser necessrio utilizar
apenas controles de tela grandes? Os usurios so idosos?
x Freqncia de entrada dos dados
o O sistema ter entrada de dados, ocasionais ou constantes?
o O que prioridade a agilidade de entrada dos dados ou clareza de informao?
o Alguma entrada de dados precisa ser automatizada?
x Qual a resoluo para qual o sistema projetado?
x Qual o principal objetivo da funcionalidade?
o Caso de sucesso
o Caso de falhas
x Como mensurar o sucesso da funcionalidade?
o Caso de testes que contemplem os valores esperados, limite e inesperados da
funcionalidade.
o Especificao dos critrios de testes.
o Tempo limite para o usurio completar a tarefa.

56
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

Aps estudar o usurio, entender suas demandas e documentar os requisitos de forma

gil, atravs da histria em quadros, um prottipo em papel desenvolvido para que o cliente
valide a especificao que est sendo descrita.
Para ganhar mais agilidade, neste primeiro prottipo nenhuma linha de cdigo ser
desenvolvida. Seguindo a proposta de Snyder (2003), a equipe de desenvolvedores elabora
uma apresentao baseada na sequncia de telas representadas em papel. Qualquer artifcio
que permita criar a sequncia de telas, consumindo a menor quantidade de recursos, vlida.
Como por exemplo, impresses de capturas de telas podero ser recortadas para extrair
componentes de tela, eliminando tempo de desenho, etc. Durante a preparao da
apresentao do prottipo as regras de preparao de cena e definio de limites atendidos
pelo prottipo descritas na tcnica de Mgico de Oz podem ser observadas. Quando a
apresentao estiver pronta algum usurio do sistema ser convidado a avaliar o prottipo.
Durante esta fase, alguns membros executores do projeto estaro presentes desempenhando
alguns papis especficos (papel de observador, papel de computador e papel de facilitador).
O observador analisa de forma silenciosa, todas as interaes do usurio procurando
falhas ou ponto de melhorias. O membro designado como computador tem o objetivo de guiar
o usurio durante a apresentao, explicando as funcionalidades que esto sendo apresentadas,
e descrevendo o que for relevante. E o facilitador que tem a responsabilidade de explicar os
limites da cena ao usurio.
tambm responsabilidade do facilitador incentivar a liberdade do usurio de forma
que ele se sinta dono de seu produto. O facilitador deve convidar o usurio a realizar
desenhos, rabiscos e anotaes diretamente no prottipo. Como o projeto no est em um
formado sistmico, o usurio tem o conhecimento suficiente para alter-lo. Este um dos
maiores objetivos da cena, recolher este feedback. A reunio inclui materiais comuns como
como folhas em branco e canetas para o usurio.
O feedback produzido registrado pelos observadores. Tambm participa desta
apresentao, o responsvel pelo papel de computador, operando as fichas e recortes,
simulando o que acontecer no sistema real. No final desta atividade os requisitos iniciais
utilizados para construir a apresentao devero ser ajustados segundo os feedbacks.
O material, da apresentao, pode ser considerado como documentao. Os requisitos
foram levantados, validados e aprovados pelo cliente.
O uso de apresentaes envolvendo prottipos em papel uma boa oportunidade para
a aplicao da tcnica proposta por Nielsen (1993), da criao de Designs Paralelos. A equipe
pode ser dividida em grupos desafiados a montar mais de uma apresentao, oferecendo

57
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

diversas opes ao cliente, por exemplo, verses para diversas plataformas como Mvel, Web
ou Desktop ou cada grupo pode ser responsvel por atender as necessidades de uma
classificao de usurios do sistema, como por exemplo, deficientes auditivos, deficientes
visuais, usurios extremos e usurios comuns.
Desta forma, o escopo do projeto pode ser radicalmente alterado antes da escrita da
primeira linha de cdigo, adequando-se a expectativas e necessidades do cliente, j que no
contexto atual de software, os sistemas possuem integraes complexas e uma constante
necessidade de serem desenvolvidos em um prazo menor de tempo.

5. Resultados

As tcnicas e o processo levantados neste trabalho foram utilizados, em um projeto de

inovao para transporte pblico desenvolvido pela Interactive Mobile @dvertising (Im@).
Maiores detalhes sobre o projeto sero omitidos por questes de segurana e
confidencialidade, porm os aspectos envolvendo a utilizao das prticas sero
demonstrados ao longo desta seo.
O projeto surgiu discutindo alternativas legais para a fiscalizao do transporte pblico
na cidade de Campinas no Estado de So Paulo. Surgiu a ideia de se aproveitar os sensores
dos dispositivos mveis, como Global Positioning System (GPS), triangulao da rede e
acelermetros do celular dos passageiros na fiscalizao. Atravs do sistema, o usurio seria
capaz de saber a trajetria de uma determinada linha de nibus, tempo de chagada at o ponto
onde o usurio se encontra e outras funcionalidades.
Como o projeto uma iniciativa de inovao da empresa, e no uma demanda
solicitada por um cliente, a equipe no teve acesso a um usurio final para levantamento de
requisitos. A equipe ento discutiu sobre quem seriam os usurios do sistema e tentou
classific-los, de acordo com suas principais caractersticas de uso do sistema. Alguns perfis
foram especificados: Estudantes Pessoas que utilizam o transporte pblico a lazer Pessoas
que utilizam transporte pblico a trabalho Idosos.
Um possvel perfil de uso do sistema foi imaginado para cada uma destas
classificaes. Porm era necessrio conhecer ao menos um usurio de cada perfil e entender
como era a diviso de uso do sistema entre as classificaes para entender qual perfil o
usurrio principal da aplicao. Devido s limitaes de recurso do projeto, no foi possvel
realizar entrevista ou estudos de observao destes usurios. Ento foi adotada a tcnica de
aplicao de formulrios. A escolha desta tcnica foi embasada na grande quantidade de

58
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

feedbacks que pode ser obtido.

O formulrio foi elaborado com perguntas que descreviam o usurio como, por
exemplo: idade, sexo, se utiliza o transporte pblico, se possui acesso a pacote de dados, tipo
de sistema operacional do aparelho mvel entre outras. O padro para resposta adotado foi o
tipo de pergunta com resposta fechada para facilitar na transformao das respostas em dados
estatsticos.
Outras perguntas foram formuladas com o objetivo colher feedbacks e avaliar
usabilidade, como funcionalidades que o sistema deveria ter. Este questionrio teve o padro
de respostas aberta. Os formulrios foram enviados via e-mail para todos os funcionrios da
empresa. Hoje a Im@ conta com cerca de 700 funcionrios no total, no qual foi obtida um
total de 100 respostas, sendo 4 de funcionrios que no utilizam transporte pblico e,
portanto, foram descartadas. A anlise dos resultados demonstrou que a maioria dos usurios
possua um dispositivo mvel com sistema operacional Android. Portanto, foi decidido
desenvolver de o sistema para esta plataforma. Foi possvel perceber tambm que boa parte
dos usurios, 60%, possua um plano de dados ativo e tinham o costume de utilizar o aparelho
durante o uso de transporte pblico. Desta forma ficou definido que as contribuies dos
usurios poderiam ocorrer de duas formas, em tempo real, atravs de internet mvel ou
ficariam retidas no aparelho at o momento que uma rede WIFI estivesse disponvel.
Com a contribuio dos entrevistados nas perguntas de resposta aberta foi possvel
visualizar as funcionalidades que este sistema deveria conter. A equipe ento descreveu as
histrias de uso, envolvendo as funcionalidades levantadas na forma de quadro de histrias
em papel. A Figura 5 demonstra a ilustrao de uma destas histrias.
Logo aps as ilustraes, uma apresentao utilizando a tcnica de prottipos em
papel foi montada e apresentada equipe da Im@, uma vez que os designers no possuam
acesso a usurios finais. Esta cena precisou de apenas 3 horas para ser montada. Durante a
simulao, algumas melhorias puderam ser feitas, como, por exemplo, surgiu a necessidade
de o sistema criar uma nota (de 1 a 10) para todas as linhas de nibus e exibir qual a melhor
com base nas informaes histricas da linha de lotao, naquele horrio, tempo mdio de
deslocamento entre os pontos, e dados como reclamaes. Com base nestas informaes, o
usurio poderia escolher melhor seu trajeto utilizando linhas com as melhores notas. A Figura
6 apresenta a tela original rascunhada durante a apresentao das notas para as linhas de
nibus.

59
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

Figura 5 Histria do embarque dirio utilizando transporte.

Fonte: elaborado pelos autores

Figura 6 levantamento do requisito de nota das linhas

Fonte: elaborado pelos autores

Uma nova apresentao, ainda em papel foi criada contemplando todas as alteraes
propostas na primeira demonstrao. A partir dos resultados desta apresentao as histrias
em quadros foram convertidas em histrias uso. A Figura 7 demonstra a histria de alarme
com a adio da nota atribuda linha levantada nos testes com prottipos em papel.
Aps a documentao do sistema uma nova apresentao foi desenvolvida, porm de
forma computacional pois seria exibia a um possvel cliente. Esta apresentao foi montada
em uma ferramenta de gerao de Mocks de baixa fidelidade, e levou 16 horas para ser
desenvolvida. Este resultado interessante, uma vez que foi gerado praticamente a mesma
apresentao, com incluso de algumas novas funcionalidades e pequenas melhorias, porm
em uma plataforma diferente. Desta forma, foi verificado que, utilizando a plataforma
computacional, foi necessrio mais do que o dobro de tempo para criar a apresentao. Isto

60
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

corroborou a praticidade e economia da tcnica de papel.

A Figura 7 demonstra dos prottipos at chegar em sua fase de codificao.

Figura 7 Tela de embarque em diferentes fases do projeto.

Fonte: elaborado pelos autores

Desta forma, os requisitos de negcio e usabilidade foram especificados e o projeto

pode seguir para a fase de codificao. Da conversa inicial e entendimento de uma
oportunidade at o momento dos requisitos documentados e validados, foram gastas 3
semanas de trabalho, um tempo relativamente curto para a elicitao de requisitos, com
poucos recursos econmicos investidos nesta fase.

6. Consideraes finais

Esta pesquisa pode constatar que a literatura possui as tcnicas necessrias para
levantamento e modelagem de requisitos para IHC e que, nem sempre, estas so combinadas
de forma a potencializar os resultados no que diz respeito agilidade e qualidade.
Este trabalho props uma forma de combinar algumas tcnicas de validao dos
requisitos funcionais e de IHC antes da fase de codificao. Atravs de um estudo de caso,
demonstrou-se que a validao dos requisitos pode ser feita de maneira simples, econmica,
gil e eficazmente sem o uso de ferramentas computacionais, alcanando, assim, o objetivo
inicial deste trabalho. Alias, foi comprovado que o uso de uma ferramenta de gerao de
prottipos consumiu mais do que o dobro de tempo para criar a apresentao para o usurio
que a tcnica de papel.
Com as tcnicas utilizadas neste trabalho, a fase de apresentao dos requisitos, que

61
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

pode ser um ponto sensvel em qualquer projeto de software contornada de maneira

satisfatria. Isto devido a que o usurio pode sim reconhecer novas demandas causando
alteraes de escopo sem isso ser dispendioso para o projeto. Esta situao no impacta de
forma significativa o projeto, uma vez que pouco recurso foi despendido no levantamento e
documentao dos requisitos.

Referncias

BALSAMIC. Balsamic Mockups. Disponvel em:

<http://balsamiq.com/products/mockups/>. Acesso em: 01 mai 2014.

BARBOSA, S. SILVA, B. Interao humano-computador. Rio de Janeiro: Campos, 2010.

JUSTMIND. Disponvel em: <http://www.justinmind.com>. Acesso em: 01 mai 2014.

CAETANO, M. L. S. Clareza, atualizao, acesso s informaes e esttica em sites de

Organizaes No Governamentais. Research, Society and Development, v. 2, n. 1, p. 80-
92, set. 2016.

GAMA, M. X. B. A Liderana na Era da Informao e do Conhecimento nas empresas.

Research, Society and Development, v. 3, n. 1, p. 02-18, nov. 2016

KELLEY, J. F. A natural language program developed with the OZ Paradigm:

implications for supercomputing systems. First International Conference on Supercomputing
Systems, New York: ACM, pp. 238-248. 1985.

LAUREL, B. The art of human-computer interface design. Boston: Addison-Wesley-

Logman.1990.

MANIFESTO. Disponvel em: <http://manifestoagil.com.br/principios.html>. Acesso em: 01

mai 2014.

NIELSEN, J. Usability engineering. New York: Academic Press, 1993.

NETTO, A. A. de O. IHC e a engenharia pedaggica. Florianpolis: Visual Books Ltda,

62
 Research, Society and Development, v. 6, n. 1, p. 47-63, set. 2017

2010.

PRESSMAN, R. Software enginnering: a pratitioner's approach. 6 ed.: Mc Graw Hill, 2005.

SANTOS, C. A. et al. Um modelo de sistema de informao gerencial: vantagem competitiva

no processo da logstica reversa do leo de cozinha. Research, Society and Development, v.
4, n. 1, p. 62-88, jan. 2017

SHNEIDERMAN, B. Designing the user interface: strategies for effective human computer
interaction. MA: Addison-Wesley-Logman. 1998.

SHNEIDERMAN, B. PLAISANT, C. Designing the user interface: strategies for effective

human-computer interaction. MA: Addison Wesley Publishing Company Incorporated, 2010.

SOMMERVILLE, I. Engenharia de software. 9 ed. So Paulo: Pearson Prentice Hall. 2011.

SNYDER, C. Paper prototyping: the fast and easy way to design and refine user interfaces.
San Francisco: Morgan Kaufmann. 2003.

USEIT. Disponvel em:<http://www.useit.com>. Acesso em: 20 mai 2012.

63