Elicitação de Requisitos e Design Participativo através de Protótipos de Baixa

Fidelidade – um Estudo de Caso

Carlos Rosemberg, Albert Schilling, Cristianne Bastos e Rodrigo Araripe

Instituto Atlântico

rosemberg@atlantico.com.br, albert@atlantico.com.br,
cris@atlantico.com.br, rodrigoararipe@atlantico.com.br

Resumo
Este trabalho relata a experiência do Atlântico com
prototipação em baixa fidelidade usada como base da
elicitação e validação de requisitos de software através
de uma abordagem de design participativo. Sua utilização
em um projeto real é detalhada, a fim de mostrar as
peculiaridades de aplicação e os resultados para o
projeto.
1. Introdução
A elicitação de requisitos é considerada uma das fases
mais complexas da Engenharia de Software. Para a
obtenção de bons resultados nesta fase faz-se necessário o
uso de técnicas específicas de elicitação, a fim de
minimizar as falhas na identificação e comunicação dos
requisitos e evitar divergências no entendimento da
solução a ser desenvolvida.
Uma das técnicas utilizadas é a prototipação, a qual
consiste na criação de artefatos visuais que representam
ou simulam aspectos de um sistema antes deste ser
efetivamente desenvolvido. Apesar de ser uma técnica
antiga e bem difundida, não existem regras rígidas quanto
ao momento e forma ideais de aplicação, o que pode vir a
gerar dúvidas e torná-la subutilizada.
Visando enriquecer o tema, o presente trabalho relata
os resultados obtidos através do uso de prototipação em
baixa fidelidade logo no início da fase de elicitação de
requisitos de um projeto em desenvolvimento no
Atlântico.
O estudo está subdividido em oito seções: na seção 2 é
feita uma breve descrição da instituição onde o
experimento foi realizado, enquanto as seções 3, 4 e 5
apresentam as técnicas e conceitos abordados no
experimento. A sexta seção relata o estudo de caso, e na
sétima seção são apresentados os principais resultados.
Por fim, a oitava seção descreve as considerações finais.
O Atlântico é uma instituição de pesquisa e
desenvolvimento localizada em Fortaleza, Ceará, fundada
em novembro de 2001 por iniciativa do Centro de
Pesquisa e Desenvolvimento em Telecomunicações
(CPqD).
Com uma equipe de aproximadamente 150
colaboradores atuando em 22 projetos, o Atlântico
desenvolve soluções em diversas áreas, posicionando-se
como fonte inovadora de conhecimento e de geração de
resultados tecnológicos de alto valor agregado para seus
clientes. Faz parte do escopo de atuação do Atlântico o
desenvolvimento de aplicações de software para sistemas
de suporte a negócios e operações, para engenharia,
inteligência de negócios, para serviços voltados à Internet
e diversos outros setores de telecomunicações, de energia
e do governo, abrangendo o mercado nacional e
internacional.
Em fevereiro de 2006, o Atlântico obteve a
certificação nível 3 de maturidade no modelo CMMi
versão 1.1, abrangendo todos os processos da área de
desenvolvimento.
3. Elicitação de Requisitos
A elicitação de requisitos é a fase, dentro do processo
de Engenharia de Requisitos, que possui o desafio de
entender os desejos e necessidades do cliente, dentre
outros itens (requisitos do domínio da aplicação e os
organizacionais, por exemplo). Segundo Kasse [12] a
elicitação vai além da coleta de requisitos, uma vez que
proativamente identifica requisitos adicionais não
explicitados pelos stakeholders.
A grande questão que envolve o processo de elicitação
de requisitos é a dificuldade de obtenção de uma visão
real do que deve ser o sistema. Sommerville [13] cita que
a elicitação de requisitos é um processo difícil por várias
razões, dentre elas:

2. Perfil do Atlântico
 1. Os stakeholders não sabem exatamente o que
querem, ou não sabem articular as idéias a serem
passadas aos analistas;
2. Os stakeholders expressam os requisitos de
acordo com seus níveis de conhecimento do
domínio da aplicação, que os analistas podem
ainda não possuir;
3. Diferentes stakeholders possuem diferentes
requisitos que expressam de maneira diferente;
4. Os requisitos do sistema podem ser influenciados
por fatores políticos internos;
5. Devido à dinamicidade da economia e dos
negócios, a volatilidade dos requisitos pode ser
alta.
Desta forma, várias técnicas de elicitação são
utilizadas visando minimizar estes problemas, como
sugere Kasse [12]: Diálogos; Cenários; Demonstração de
tecnologias; Modelos; Simulações; Protótipos;
Brainstorming; Observação de sistemas existentes e
Extrações de documentos.
Este estudo mostra como uma dessas técnicas, no caso
a prototipação, ajudou a resolver ou minimizar alguns dos
problemas acima citados.
4. Prototipação
A literatura de IHC (Interação Humano Computador)
prevê diversas abordagens que propõem atividades a
serem implantadas com o fim de projetar sistemas para
atender aos objetivos do usuário, tais como:
• Engenharia de usabilidade, que propõe um processo
de projeto de Interfaces de Usuário objetivando a
facilidade de aprendizado e de uso, garantindo que
sejam agradáveis para as pessoas [1].
• Projeto centrado no usuário [4], no qual há a
mudança de foco em tecnologia para o foco em
usuários [5], onde o envolvimento dos usuários está
baseado em estudos sobre os mesmos, participação
durante o projeto e testes realizados.
• Projeto centrado no uso, que foca no trabalho que os
usuários tentam realizar e no que o sistema precisa
suprir, para ajudá-los a alcançar seus objetivos [2].
Apesar das diversas abordagens existentes para
projetar sistemas, todos possuem um ponto em comum: a
utilização de protótipos durante algum momento do
processo de desenvolvimento.
Um protótipo é uma representação limitada de um
design, a qual pode ser um esboço em papel de uma tela
ou conjunto de telas, uma “fotografia” eletrônica, uma
simulação em vídeo de uma tarefa, uma maquete
tridimensional, de papel ou cartolina, ou um simples
conjunto de telas vinculadas por hyperlinks [7].
Segundo Sommerville e Sawyer [8], um protótipo pode
ser usado como meio de comunicação entre os diversos
membros da equipe de desenvolvimento ou mesmo como
meio de testar idéias. A experiência permitiu concluir que
o sistema final será tanto melhor quanto mais iterativo for
o processo de desenvolvimento do protótipo [7].
Os protótipos podem ser desenvolvidos usando
tecnologias que em nada se assemelham com as do
sistema final [9] e elaborados recorrendo a diversas
técnicas e materiais. Conseqüentemente, apresentam
diversos custos [7].
4.1. Prototipação em Baixa Fidelidade
Protótipos podem ser gerados de acordo com as
seguintes categorias [3]: protótipos em baixa fidelidade
que focam na interação, em componentes de interface e na
estrutura geral do sistema; protótipos em alta fidelidade
que produzem uma imagem real do sistema; protótipos
executáveis que produzem o código em uma linguagem
de programação, focando em navegação, mas sem ainda
levar em consideração as regras de negócio.
Cada categoria serve para um propósito específico:
protótipos em baixa fidelidade são úteis para demonstrar
aos usuários quais atividades o sistema atende e as
possibilidades de navegação no sistema, assim como para
proporcionar uma visão geral do sistema. Protótipos em
alta fidelidade são úteis para demonstrar padrões e guias
de estilo. Protótipos executáveis são úteis para demonstrar
navegação e testar o uso da interface.
O foco deste trabalho está no uso dos protótipos de
baixa fidelidade para a elicitação de requisitos com o
cliente. Segundo Yvonne Rogers e suas colegas [7], eles
são úteis para a exploração e testes na fase inicial de
desenvolvimento do sistema. São protótipos simples,
baratos e de fácil produção e alteração, facilitando, deste
modo, a exploração e teste de idéias.
5. Design Participativo
O Design Participativo (ou Participatory Design) é
uma abordagem do projeto de interfaces onde os usuários
são ativamente envolvidos no processo de
desenvolvimento, tornando-se parceiros dos demais
membros da equipe de design [7].
Em abordagens mais tradicionais, o projeto é realizado
por uma equipe unidisciplinar, que geralmente possui uma
ótica limitada a um escopo definido. Já no projeto
participativo, o qual envolve uma equipe multidisciplinar,
onde questionamentos sob diferentes pontos de vista são
efetuados e competências de diferentes áreas se
complementam [6].
 Essa colaboração é um grande desafio, visto que o fato
de envolver usuários em decisões de design é algo
bastante complexo [7]. Para que isso ocorra de forma
efetiva, é importante o uso de técnicas que permitam a
comunicação efetiva entre os participantes, fazendo com
que seus conhecimentos e experiências sejam realmente
aproveitados. No caso, a prototipação é a técnica mais
adequada a essa situação, dada sua característica de
comunicação visual.
6. Estudo de Caso
Esta seção faz o detalhamento do estudo de caso
analisado. O projeto encontra-se ainda em andamento e as
informações a seguir são relativas somente à fase de
elicitação de requisitos.
6.1. Descrição do projeto
O projeto em questão é um sistema de workflow de
pequeno porte, porém com alta complexidade, e que está
sendo desenvolvido para uma empresa multinacional do
ramo de tecnologia. O usuário final do sistema pertence a
uma unidade de negócio estrangeira, que contratou a
unidade brasileira de pesquisa e desenvolvimento para
prover a solução. A unidade brasileira é o cliente direto
do Atlântico.
6.2. Desafios
• O cliente direto (instalado no Brasil) não era o
cliente final (matriz no exterior), o que gerava uma
maior complexidade na comunicação e nos
processos de coleta de informações e aprovações
de artefatos;
• O modelo de processo de negócio estava sendo
definido junto com os requisitos do sistema, o que
gerava um alto nível de retrabalho;
• Devido a fatores de negócio, o prazo de entrega de
uma versão inicial era muito curto, o que levou à
necessidade de adoção de métodos mais ágeis.
• O sistema deveria substituir um conjunto de
planilhas, cujo conteúdo a equipe de
desenvolvimento não tinha acesso devido ao alto
grau de segredo industrial. Isso foi um
complicador para o entendimento do sistema, uma
vez que os insumos não usavam dados reais.
6.3. Perfil da Equipe
A equipe de elicitação de requisitos do projeto foi
composta por:
• Representante do cliente final, localizado na
unidade de negócio estrangeira e responsável por
fornecer requisitos do sistema e aprovar artefatos.
Também estava definindo o processo interno que
iria ser automatizado pelo sistema. Será também
um dos usuários finais do sistema.
• Líder de requisitos do cliente direto, localizado na
unidade brasileira e responsável por todos os
contatos com o representante do cliente final
(discussões, coletas, aprovações, etc.);
• Especialista do cliente direto, responsável por
assessorar o líder de requisitos em questões
técnicas e de negócio;
• Analistas de Requisitos, responsáveis pela
elicitação de requisitos do lado do Atlântico,
criação dos principais artefatos (documentação
dos requisitos, casos de uso, etc.) e por manter
contato com o líder de requisitos do cliente direto;
• Designer de interação, responsável pelo estudo da
experiência do usuário, prototipação, definição do
padrão de interação do sistema e sua interface
gráfica.
6.4. Técnicas utilizadas
A seguir é descrito o que foi utilizado, em termos de
técnicas e ferramentas, para a elicitação dos requisitos do
projeto.
Análise da experiência do usuário
Para este estudo foi utilizado o MEX (Modelo
Genérico de Experiência do Usuário) [10]. Durante o
processo, foram especificadas diretrizes que geraram
requisitos de natureza funcional e não funcional.
Workshop de requisitos
Reunião presencial com o cliente direto (o cliente final
não participou), com o objetivo de detalhar os requisitos
do núcleo do sistema. O desenvolvimento dos protótipos
de baixa fidelidade teve início durante as sessões do
workshop.
Prototipação em baixa fidelidade
Técnica de projeto de telas que, neste caso, foi
executada em conjunto entre o designer de interação, os
analistas de requisitos e líder de requisitos do cliente
direto, com a finalidade de ilustrar o conteúdo discutido
no workshop.
 Criação de Cenários de uso
Os cenários de uso foram escritos paralelamente ao
desenvolvimento dos protótipos, com o objetivo de
descrever os detalhes da interação e procedimentos
internos do sistema, sendo, portanto, insumos diretos para
a posterior elaboração dos casos de uso. Para cada
protótipo de tela desenvolvido foi criado um cenário de
uso correspondente.
6.5. Ferramentas
Os protótipos foram elaborados utilizando o software
Microsoft Visio, juntamente com um conjunto de
componentes visuais para prototipação de aplicações web
(caixas de texto, botões, barras de rolagem, caixas de
seleção, rótulos, etc) desenvolvidos por Henrik Olsen [11]
e disponibilizados gratuitamente em seu blog.
6.6. Infraestrutura
Durante o workshop realizado nas dependências do
cliente, foi utilizado um projetor ligado ao notebook
utilizado pelo designer, de modo que todos pudessem
acompanhar e participar da elaboração das telas à medida
que as discussões aconteciam. Eventualmente, o projetor
era acoplado em notebooks de outros membros da equipe
quando se fazia necessário visualizar outros insumos
(Figura 1).
FIGURA 1: Esquematização do ambiente do
workshop
1. Projeção das telas em prototipação
2. Projetor
3. Cliente (Líder de requisitos)
4. Cliente (especialista no domínio da aplicação)
5. Designer de interação (Atlântico)
6. Analista de requisitos (Atlântico)
6.5. Processo
Divisão de tarefas e dinâmica do processo
Durante o workshop, enquanto o designer elaborava as
telas em tempo real no Microsoft Visio, o analista de
requisitos fazia os principais questionamentos, tomava
notas à parte e montava o cenário de uso da tela em
questão. O líder de requisitos e o especialista do cliente
direto discutiam entre si algumas questões, tomavam
notas e forneciam insumos (documentos, informações
verbais, etc). As discussões englobavam questões que
variavam desde regras de negócio e funcionalidades
centrais do sistema a pontos ligados à usabilidade e
disposição de elementos na tela.
Prototipação feita pelos analistas e clientes
O trabalho de elicitação continuou a acontecer mesmo
após o workshop realizado. Neste momento, os meios de
comunicação utilizados no processo foram telefone e
email. Desta forma, os próprios analistas de requisitos
passaram a não mais depender do designer e a utilizar eles
próprios o Microsoft Visio para atualizar os protótipos
durante as discussões com o líder de requisitos do cliente
direto. A partir de certo momento, tanto o líder de
requisitos do cliente direto quanto o representante do
cliente final passaram também a modificar esses
protótipos (no formato Visio) para esclarecer dúvidas dos
analistas e fazer sugestões e solicitações. Ou seja,
praticamente todos os membros da equipe, incluindo o
representante do cliente final, alteraram os protótipos.
6.7. Artefatos gerados
Os principais artefatos gerados na fase de prototipação
foram arquivos do Visio (.vsd), como mostrado na Figura
2, e os cenários de uso correspondentes (já abordados no
item 6.4).
A fim de se obter maior produtividade, alguns
princípios foram adotados para a confecção dos
protótipos:
1. Elaborar o protótipo de forma mais simples
possível, despriorizando o acabamento visual;
2. Prototipar apenas os elementos do fluxo em
discussão. Navegação global, cabeçalhos, rodapés,
etc, foram deixados para um protótipo específico
para esse fim. Isso ajudou a manter o foco apenas
na funcionalidade propriamente dita e eliminou
um custo a mais na manutenção dos arquivos (por
exemplo, caso um elemento global do cabeçalho
ou rodapé mudasse, seria necessário alterar vários
arquivos).
 3. Criar um arquivo Visio para cada passo do fluxo
(equivalente a um caso de uso) visando manter os
arquivos menores e mais fáceis de navegar, além
de permitir o trabalho em paralelo da equipe.
FIGURA 2: Exemplo de protótipo
7. Resultados obtidos
Ao ser comparada com outras abordagens comuns no
mercado, a utilização de protótipos de baixa fidelidade na
elicitação de requisitos trouxe vários benefícios ao
projeto:
1. Potencialização de idéias: O uso de artefatos
visuais estimulou uma melhora substancial na
geração, comunicação e absorção de idéias entre o
cliente e a equipe. Existia pouca dissonância entre
o entendimento de cada um;
2. Antecipação de problemas: Houve antecipação
de detalhes e problemas que só seriam percebidos
em fases vindouras, quando seria bem mais
custoso executar uma mudança;
3. Maior agilidade no processo: Em outras
abordagens, protótipos de alta fidelidade eram
usados para validar casos de uso, sendo
construídos a partir destes. Além de ser um
protótipo mais caro, necessitaria passar por um
ciclo de aprovação interno (analista - designer de
interação). Com protótipos de baixa fidelidade na
elicitação de requisitos, as telas já saíram do
processo semi-aprovadas, uma vez que toda a
equipe (cliente, analistas, designer) participou de
sua elaboração;
4. Melhor integração IHC-Requisitos: A
participação do designer de interação na elicitação
de requisitos gerou uma grande sinergia entre as
disciplinas de Interação Homem Computador e
Análise de Requisitos, impactando positivamente
na qualidade da solução e na produtividade da
equipe.
5. Envolvimento da equipe: O nível de
envolvimento do cliente e demais membros da
equipe na elaboração dos protótipos (design
participativo) gerou um alto sentimento de
propriedade e comprometimento com a solução
que estava sendo planejada;
6. Resultados concretos já no início do processo:
O cliente dispôs de uma representação visual que
materializava a solução logo no início do
processo. Este fato aumentou sua confiança no
projeto e ajudou no gerenciamento de
expectativas.
7. Independência dos Analistas de Requisitos:
Essa abordagem possibilitou uma menor
dependência da equipe em relação ao designer
para elaboração de protótipos, uma vez que não
era necessária fidelidade visual e o software
utilizado era bem conhecido e de fácil utilização,
voltado, inclusive, para quem não é designer. No
entanto, o designer sempre se fez necessário nos
momentos de soluções mais complexas e
definições iniciais de padrões de interação com o
usuário.
8. Considerações Finais
O estudo de caso realizado mostrou, através dos
resultados acima, o quanto a prototipação em baixa
fidelidade auxilia a elicitação de requisitos de forma
simples e eficaz, gerando otimização de recursos e
aumentando a satisfação do cliente.
No entanto, para que isso ocorra, é necessário trazer a
prototipação para o início do processo, no momento
inicial de coleta de informações e geração de idéias, e não
apenas aplicá-la após a construção dos casos de uso
(como acontece na maior parte dos casos).
 Também foi visto como essa técnica viabiliza o
envolvimento da equipe e do cliente em um processo de
design participativo, onde a criatividade das pessoas é
desafiada e o usuário final contribui mais ativamente para
a criação de uma solução efetiva, que não apenas atenda
às suas necessidades, mas proporcione uma experiência
de uso de maior qualidade.

9. Referências

[1] B. Maria Cecília, R., Heloisa Vieira da. Design e Avaliação

de Interfaces Humano-Computador, NIED – Núcleo de
Informática Aplicada à Educação, UNICAMP – Universidade
Estadual de Campinas, 2003.
[2] L. Constantine, L., Lockwood, Software for Use: A Practical
Guide to Models and Methods of Usage-Centered Design.
Addison-Wesley, Reading, 1999.
[3] A. Coyette, S. Faulkner, M. Kolp, Q. Limbourg, J.
Vanderdonckt, Sket-chiXML: Towards a Multi-Agent Design
Tool for Sketching User Interfaces Based on UsiXML, Proc. of
3rd Int. Workshop on Task Models and Diagrams for user
interface design TAMO-DIA’2004, ACM Press, New York,
2004.
[4] N. Clare-Marie, J. B. Karat, e K. John, Introduction and
Overview: A Guide to the Reader. In Designing Personalized
User Experiences in eCommerce, Publishers, 2004.
[5] D.A. Norman, S.W. Draper, User-Centered Design.
Hillsdale, N.J.: Lawrence Erlbaum, 1986.
[6] E. Furtado, F. Carvalho, A. Schilling, F. Fava, K. Sousa,
Projeto de Interfaces de Usuário para a Televisão Digital
Brasileira In: Simpósio Brasileiro de Computação Gráfica e
Processamento de Imagens, Natal, 2005.
[7] Y. Rogers, H. Sharp, J. Preece, Interaction Design - Beyond
human-computer interaction Wiley , 2002.
[8] I. Sommerville, e P. Sawyer,Requirements Engineering - A
good practice guide - Wiley 1997.
[9] K. Gerald e I. Somerville, Requirements Engineering:
Processes and Techniques, Wiley, 1998.
[10] C. Rosemberg, MEX - Um Modelo Genérico para o
Estudo das Experiências dos Usuários com Produtos
Interativos. Science of Computing, v. 1, p. 21-28, 2007.
[11] H. Olsen, Visio - the interaction designer’s nail gun
(How to use Visio for rapid prototyping)
http://www.guuui.com/issues/02_03_02.php.
[12] T. Kasse, Practical insight into CMMI, Artech House
computing library, 2004.
[13] I. Sommerville, Engenharia de Software, Pearson
Addison Wesley, 2003