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

Transcrição

1 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

2 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] 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].

3 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. 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; 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 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 Perfil da Equipe A equipe de elicitação de requisitos do projeto foi composta por: 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 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.

4 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 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 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) 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 . 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 Artefatos gerados 1 2 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). 5 6 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) 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).

5 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. SCREEN TITLE Low Fidelity Prototype Project Name 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; 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. Item Item Item Item 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; Button Save 1 Button Clear2 Button Cancel 3 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. 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 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).

6 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, [2] L. Constantine, L., Lockwood, Software for Use: A Practical Guide to Models and Methods of Usage-Centered Design. Addison-Wesley, Reading, [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, [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, [5] D.A. Norman, S.W. Draper, User-Centered Design. Hillsdale, N.J.: Lawrence Erlbaum, [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, [7] Y. Rogers, H. Sharp, J. Preece, Interaction Design - Beyond human-computer interaction Wiley, [8] I. Sommerville, e P. Sawyer,Requirements Engineering - A good practice guide - Wiley [9] K. Gerald e I. Somerville, Requirements Engineering: Processes and Techniques, Wiley, [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 , [11] H. Olsen, Visio - the interaction designer s nail gun (How to use Visio for rapid prototyping) [12] T. Kasse, Practical insight into CMMI, Artech House computing library, [13] I. Sommerville, Engenharia de Software, Pearson Addison Wesley, 2003